📅 Original date posted:2015-06-26
📝 Original message: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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150626/03a1d7e6/attachment.html>;
Tier Nolan [ARCHIVE] /
npub1g6…sl5wd
2023-06-07 15:39:52
in reply to nevent1q…78xm
Author Public Key
npub1g6vxlp4e0nyhs2dqxxcryztyf5f5hyuaq93nw4r87zcnv0sdsa0qqsl5wdPublished at
2023-06-07 15:39:52Event JSON
{
"id": "348cded7c6f1820621949dfcd4afb066fa3d0aa36bdd6392ffe54dbaf0977739",
"pubkey": "46986f86b97cc97829a031b03209644d134b939d0163375467f0b1363e0d875e",
"created_at": 1686152392,
"kind": 1,
"tags": [
[
"e",
"1936c15d372dc9e8a0eaf645dcff207375e90675dbebfadcf82370abc654737d",
"",
"root"
],
[
"e",
"f2e426c69efd89788f8f9f2787854bf3678599d439de1575d4e27ea790e06c63",
"",
"reply"
],
[
"p",
"ee0fa66772f633411e4432e251cfb15b1c0fe8cd8befd8b0d86eb302402a8b4a"
]
],
"content": "📅 Original date posted:2015-06-26\n📝 Original message:On Thu, Jun 25, 2015 at 3:07 PM, Adam Back \u003cadam at cypherspace.org\u003e wrote:\n\n\u003e The hard-cap serves the purpose of a safety limit in case our\n\u003e understanding about the economics, incentives or game-theory is wrong\n\u003e worst case.\n\u003e\n\nTrue.\n\nBIP 100 and 101 could be combined. Would that increase consensus?\n\n- Miner vote threshold reached\n- Wait notice period or until earliest start time\n- Block size default target set to 1 MB\n- Soft limit set to 1MB\n- Hard limit set to 8MB + double every 2 years\n- Miner vote to decide soft limit (lowest size ignoring bottom 20% but 1MB\nminimum)\n\nBlock size updates could be aligned with the difficulty setting and based\non the last 2016 blocks.\n\nMiners could leave the 1MB limit in place initially. The vote is to get\nthe option to increase the block size.\n\nLegacy clients would remain in the network until \u003e80% of miners vote to\nraise the limit and a miner produces a \u003e1MB block.\n\nIf the growth rate over-estimates hardware improvements, the devs could add\na limit into the core client. If they give notice and enough users update,\nthen miners would have to accept it.\n\nThe block size becomes min(miner's vote, core devs). Even if 4 years\nnotice is given, blocks would only be 4X optimal.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150626/03a1d7e6/attachment.html\u003e",
"sig": "95b14e5f564f0ef4d1701177ee0194687d2faaa2910a12d0b0f54c69a2f7f761ef0b8dea7ade379fe566ac89252881e0b1c736f8392d4eb78e94a663ebd48bdb"
}