📅 Original date posted:2015-06-25
📝 Original message:Note Jeff's proposal and Greg Maxwell's flexcap proposals also have a
growth limiter as a hard-cap and a mechanism for influencing a dynamic
cap within that envelope.
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.
More comments to follow.
Adam
On 25 June 2015 at 15:50, Gareth Williams <gacrux at gmail.com> wrote:
> On 24 June 2015 1:49:51 PM AEST, Jeff Garzik <jgarzik at gmail.com> wrote:
>>Miners can collude today to lower the block size limit.
>
> Of course they can. What, then, is the need for BIP100's hard-limit voting mechanism?
>
> You only need consensus rules to enforce block size limits if you're enforcing them _against_ miners. Which may be a perfectly valid thing to do (if your threat model includes, for example, the possibility that large miners deliberately create large blocks to gain an advantage over small miners.) But BIP100 doesn't address that anyway.
>
> Wouldn't it be safer for consensus to get behind Gavin's simpler 8MB->8GB hard-limit growth curve*, and then encourage miners to enforce a soft limit below that, agreed through a voting mechanism? The later can be implemented at any time without consensus changes -- nobody can prevent miners from coordinating the max block size they'll build on anyway.
>
> * but with a safer "supermajority" than 75% please :)
> --
> Sent from my Android device with K-9 Mail. Please excuse my brevity.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Adam Back [ARCHIVE] /
npub1ac…lswfj
2023-06-07 15:39:52
in reply to nevent1q…57d0
Author Public Key
npub1ac86vemj7ce5z8jyxt39rna3tvwql6xd30ha3vxcd6esysp23d9qrlswfjPublished at
2023-06-07 15:39:52Event JSON
{
"id": "f2e426c69efd89788f8f9f2787854bf3678599d439de1575d4e27ea790e06c63",
"pubkey": "ee0fa66772f633411e4432e251cfb15b1c0fe8cd8befd8b0d86eb302402a8b4a",
"created_at": 1686152392,
"kind": 1,
"tags": [
[
"e",
"1936c15d372dc9e8a0eaf645dcff207375e90675dbebfadcf82370abc654737d",
"",
"root"
],
[
"e",
"5ddff433740770cdd33a2c5524582323bc4549fab2e7079abd61e9939fee6291",
"",
"reply"
],
[
"p",
"959a9c23e3a17ee9df362d7f12c50fbdefd93d94208519d2110bc65e3e9ed411"
]
],
"content": "📅 Original date posted:2015-06-25\n📝 Original message:Note Jeff's proposal and Greg Maxwell's flexcap proposals also have a\ngrowth limiter as a hard-cap and a mechanism for influencing a dynamic\ncap within that envelope.\n\nThe hard-cap serves the purpose of a safety limit in case our\nunderstanding about the economics, incentives or game-theory is wrong\nworst case.\n\nMore comments to follow.\n\nAdam\n\n\nOn 25 June 2015 at 15:50, Gareth Williams \u003cgacrux at gmail.com\u003e wrote:\n\u003e On 24 June 2015 1:49:51 PM AEST, Jeff Garzik \u003cjgarzik at gmail.com\u003e wrote:\n\u003e\u003eMiners can collude today to lower the block size limit.\n\u003e\n\u003e Of course they can. What, then, is the need for BIP100's hard-limit voting mechanism?\n\u003e\n\u003e You only need consensus rules to enforce block size limits if you're enforcing them _against_ miners. Which may be a perfectly valid thing to do (if your threat model includes, for example, the possibility that large miners deliberately create large blocks to gain an advantage over small miners.) But BIP100 doesn't address that anyway.\n\u003e\n\u003e Wouldn't it be safer for consensus to get behind Gavin's simpler 8MB-\u003e8GB hard-limit growth curve*, and then encourage miners to enforce a soft limit below that, agreed through a voting mechanism? The later can be implemented at any time without consensus changes -- nobody can prevent miners from coordinating the max block size they'll build on anyway.\n\u003e\n\u003e * but with a safer \"supermajority\" than 75% please :)\n\u003e --\n\u003e Sent from my Android device with K-9 Mail. Please excuse my brevity.\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",
"sig": "31947df81dd2c9c0b2333da09ae4ec0809ee103e2394578f43f5b1884dec7f1c41b4fb3c5557dc9e1e1ad2002f459d867b60ca94a72bacd1bb42d1382c314de9"
}