📅 Original date posted:2015-06-26 📝 Original message:Make the default soft vote ...

Will [ARCHIVE] /

npub1xe4…rjrx

2023-06-07 15:39:52

in reply to nevent1q…zm8x

📅 Original date posted:2015-06-26
📝 Original message:Make the default soft vote = to previous max block size * 1.09 every 12k (or whatever mirrors the hard cap growth rate) and don't allow voting to lower the soft limit and I think you have something.

You need a default that grows because most miners are lazy and will do squirrelly things like hard code 8000000 as their vote permanently.

Make the lazy miners' default choice grow at the hard cap growth rate and you should be ok if you want voting.

> On Jun 26, 2015, at 9:47 AM, Tier Nolan <tier.nolan at gmail.com> wrote:
>
>> On Thu, Jun 25, 2015 at 3:07 PM, Adam Back <adam at cypherspace.org> wrote:
>> The hard-cap serves the purpose of a safety limit in case our
>> understanding about the economics, incentives or game-theory is wrong
>> worst case.
>
> True.
>
> BIP 100 and 101 could be combined. Would that increase consensus?
>
> - Miner vote threshold reached
> - Wait notice period or until earliest start time
> - Block size default target set to 1 MB
> - Soft limit set to 1MB
> - Hard limit set to 8MB + double every 2 years
> - Miner vote to decide soft limit (lowest size ignoring bottom 20% but 1MB minimum)
>
> Block size updates could be aligned with the difficulty setting and based on the last 2016 blocks.
>
> Miners could leave the 1MB limit in place initially. The vote is to get the option to increase the block size.
>
> Legacy clients would remain in the network until >80% of miners vote to raise the limit and a miner produces a >1MB block.
>
> If the growth rate over-estimates hardware improvements, the devs could add a limit into the core client. If they give notice and enough users update, then miners would have to accept it.
>
> The block size becomes min(miner's vote, core devs). Even if 4 years notice is given, blocks would only be 4X optimal.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150626/14ba600c/attachment.html>;

Author Public Key

npub1xe4sg9zgsm90v8ge3r0h29jmwjuudcldxfwczaazuph5y5020jvqpzrjrx

Show more details

Published at

2023-06-07 15:39:52

Kind type

1 Short Text Note

Event JSON

{ "id": "79cbd75af8a6ecaa69f1131a8f3078d651461a3a71cc2a545b530f949a5609c5", "pubkey": "366b04144886caf61d1988df75165b74b9c6e3ed325d8177a2e06f4251ea7c98", "created_at": 1686152392, "kind": 1, "tags": [ [ "e", "1936c15d372dc9e8a0eaf645dcff207375e90675dbebfadcf82370abc654737d", "", "root" ], [ "e", "348cded7c6f1820621949dfcd4afb066fa3d0aa36bdd6392ffe54dbaf0977739", "", "reply" ], [ "p", "46986f86b97cc97829a031b03209644d134b939d0163375467f0b1363e0d875e" ] ], "content": "📅 Original date posted:2015-06-26\n📝 Original message:Make the default soft vote = to previous max block size * 1.09 every 12k (or whatever mirrors the hard cap growth rate) and don't allow voting to lower the soft limit and I think you have something.\n\nYou need a default that grows because most miners are lazy and will do squirrelly things like hard code 8000000 as their vote permanently. \n\nMake the lazy miners' default choice grow at the hard cap growth rate and you should be ok if you want voting.\n\n\u003e On Jun 26, 2015, at 9:47 AM, Tier Nolan \u003ctier.nolan at gmail.com\u003e wrote:\n\u003e \n\u003e\u003e On Thu, Jun 25, 2015 at 3:07 PM, Adam Back \u003cadam at cypherspace.org\u003e wrote:\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 wrong\n\u003e\u003e worst case.\n\u003e \n\u003e True.\n\u003e \n\u003e BIP 100 and 101 could be combined. Would that increase consensus?\n\u003e \n\u003e - Miner vote threshold reached\n\u003e - Wait notice period or until earliest start time\n\u003e - Block size default target set to 1 MB\n\u003e - Soft limit set to 1MB\n\u003e - Hard limit set to 8MB + double every 2 years\n\u003e - Miner vote to decide soft limit (lowest size ignoring bottom 20% but 1MB minimum)\n\u003e \n\u003e Block size updates could be aligned with the difficulty setting and based on the last 2016 blocks.\n\u003e \n\u003e Miners could leave the 1MB limit in place initially. The vote is to get the option to increase the block size.\n\u003e \n\u003e Legacy clients would remain in the network until \u003e80% of miners vote to raise the limit and a miner produces a \u003e1MB block.\n\u003e \n\u003e If the growth rate over-estimates hardware improvements, the devs could add a limit into the core client. If they give notice and enough users update, then miners would have to accept it.\n\u003e \n\u003e The block size becomes min(miner's vote, core devs). Even if 4 years notice is given, blocks would only be 4X optimal.\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-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150626/14ba600c/attachment.html\u003e", "sig": "7d980a78b631bc4dd09de270b559ffdb33d9e0f26375a8293712fceccadaab7e40241c9c8d4f663337facb8d88573e37ccd46c532444c852f96b62500bdbb1d8" }