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