{"type":"rich","version":"1.0","author_name":"npub164fseem24m3rdpqrkq9jkx5n4d6r4wg0cthw8669gag3xszngfrsvfec7x","author_url":"https://nostr.ae/npub164fseem24m3rdpqrkq9jkx5n4d6r4wg0cthw8669gag3xszngfrsvfec7x","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-08-17\n📝 Original message:The \"only bigblock\" patch you want is actually available here :\nhttps://github.com/bitcoinxt/bitcoinxt/tree/only-bigblocks\n\nLe lun. 17 août 2015 à 15:16, Tier Nolan via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e a écrit :\n\n\u003e One of the comments made by the mining pools is that they won't run XT\n\u003e because it is \"experimental\".\n\u003e\n\u003e Has there been any consideration to making available a version of XT with\n\u003e only the blocksize changes?\n\u003e\n\u003e The least \"experimental\" version would be one that makes the absolute\n\u003e minimum changes to core.\n\u003e\n\u003e The MAX_BLOCK_SIZE parameter could be overwritten whenever the longest tip\n\u003e changes.  This saves creating a new function.\n\u003e\n\u003e Without the consensus measuring code, the patch would be even easier.\n\u003e Satoshi's proposal was just a block height comparison (a year in advance).\n\u003e\n\u003e The state storing code is also another complication.  If the standard\n\u003e \"counting\" upgrade system was used, then no state would need to be stored\n\u003e in the database.\n\u003e\n\u003e On Wed, Jul 1, 2015 at 11:49 PM, odinn \u003codinn.cyberguerrilla at riseup.net\u003e\n\u003e wrote:\n\u003e\n\u003e\u003e -----BEGIN PGP SIGNED MESSAGE-----\n\u003e\u003e Hash: SHA1\n\u003e\u003e\n\u003e\u003e (My replies below)\n\u003e\u003e\n\u003e\u003e On 06/26/2015 06:47 AM, Tier Nolan wrote:\n\u003e\u003e \u003e On Thu, Jun 25, 2015 at 3:07 PM, Adam Back \u003cadam at cypherspace.org\n\u003e\u003e \u003e \u003cmailto:adam at cypherspace.org\u003e\u003e wrote:\n\u003e\u003e \u003e\n\u003e\u003e \u003e The hard-cap serves the purpose of a safety limit in case our\n\u003e\u003e \u003e understanding about the economics, incentives or game-theory is\n\u003e\u003e \u003e wrong worst case.\n\u003e\u003e \u003e\n\u003e\u003e \u003e\n\u003e\u003e \u003e True.\n\u003e\u003e\n\u003e\u003e Yep.\n\u003e\u003e\n\u003e\u003e \u003e\n\u003e\u003e \u003e BIP 100 and 101 could be combined.  Would that increase consensus?\n\u003e\u003e\n\u003e\u003e Possibly ~ In my past message(s), I've suggested that Jeff's BIP 100\n\u003e\u003e is a better alternative to Gavin's proposal(s), but that I didn't\n\u003e\u003e think that this should be taken to mean that I am saying one thing is\n\u003e\u003e \"superior\" to Gavin's work, rather, I emphasized that Gavin work with\n\u003e\u003e Jeff and Adam.\n\u003e\u003e\n\u003e\u003e At least, at this stage the things are in a BIP process.\n\u003e\u003e\n\u003e\u003e If the BIP 100 and BIP 101 would be combined, what would that look\n\u003e\u003e like on paper?\n\u003e\u003e\n\u003e\u003e \u003e\n\u003e\u003e \u003e - Miner vote threshold reached - Wait notice period or until\n\u003e\u003e \u003e earliest start time - Block size default target set to 1 MB - Soft\n\u003e\u003e \u003e limit set to 1MB - Hard limit set to 8MB + double every 2 years -\n\u003e\u003e \u003e Miner vote to decide soft limit (lowest size ignoring bottom 20%\n\u003e\u003e \u003e but 1MB minimum)\n\u003e\u003e \u003e\n\u003e\u003e \u003e Block size updates could be aligned with the difficulty setting\n\u003e\u003e \u003e and based on the last 2016 blocks.\n\u003e\u003e \u003e\n\u003e\u003e \u003e Miners could leave the 1MB limit in place initially.  The vote is\n\u003e\u003e \u003e to get the option to increase the block size.\n\u003e\u003e \u003e\n\u003e\u003e \u003e Legacy clients would remain in the network until \u003e80% of miners\n\u003e\u003e \u003e vote to raise the limit and a miner produces a \u003e1MB block.\n\u003e\u003e \u003e\n\u003e\u003e \u003e If the growth rate over-estimates hardware improvements, the devs\n\u003e\u003e \u003e could add a limit into the core client.  If they give notice and\n\u003e\u003e \u003e enough users update, then miners would have to accept it.\n\u003e\u003e \u003e\n\u003e\u003e \u003e The block size becomes min(miner's vote, core devs).  Even if 4\n\u003e\u003e \u003e years notice is given, blocks would only be 4X optimal.\n\u003e\u003e \u003e\n\u003e\u003e \u003e\n\u003e\u003e \u003e _______________________________________________ bitcoin-dev mailing\n\u003e\u003e \u003e list bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e \u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e \u003e\n\u003e\u003e\n\u003e\u003e - --\n\u003e\u003e http://abis.io ~\n\u003e\u003e \"a protocol concept to enable decentralization\n\u003e\u003e and expansion of a giving economy, and a new social good\"\n\u003e\u003e https://keybase.io/odinn\n\u003e\u003e -----BEGIN PGP SIGNATURE-----\n\u003e\u003e Version: GnuPG v1\n\u003e\u003e\n\u003e\u003e iQEcBAEBAgAGBQJVlG5oAAoJEGxwq/inSG8C0r4H/0eklB9GxgHdl4LK7UoLeYYb\n\u003e\u003e hlCiIJZ1+sRhTRIHrBtZO+nb2Uy3jLdqO9eOL4z9OXk3TCRBFwSdWrwsZXbzy3tC\n\u003e\u003e 5TmYlHvLSpfjiUxpP9JcO5E2VwFvB80pKkjPuUhwFVngh0HHsTA1IinUt52ZW1QP\n\u003e\u003e wTdgKFHw3QL9zcfEXljVa3Ih9ssqrl5Eoab8vE2yr3p3QHR7caRLY1gFyKKIRxVH\n\u003e\u003e YQangx6D33JcxyAcDNhYqavyt02lHxscqyZo6I4XUvE/aZVmSVTlm2zg7xdR7aCZ\n\u003e\u003e 0PlDwzpMD6Zk2QO/5qPPPos/5VETT0ompFK62go/hY2uB4cm+yZw3FFxR+Kknog=\n\u003e\u003e =rtTH\n\u003e\u003e -----END PGP SIGNATURE-----\n\u003e\u003e\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150817/307a7369/attachment.html\u003e"}