📅 Original date posted:2015-06-25
📝 Original message: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.
Gareth Williams [ARCHIVE] /
npub1jk…373ck
2023-06-07 15:39:51
in reply to nevent1q…gpsv
Author Public Key
npub1jkdfcglr59lwnhek94l393g0hhhaj0v5yzz3n5s3p0r9u0576sgs7373ckPublished at
2023-06-07 15:39:51Event JSON
{
"id": "5ddff433740770cdd33a2c5524582323bc4549fab2e7079abd61e9939fee6291",
"pubkey": "959a9c23e3a17ee9df362d7f12c50fbdefd93d94208519d2110bc65e3e9ed411",
"created_at": 1686152391,
"kind": 1,
"tags": [
[
"e",
"1936c15d372dc9e8a0eaf645dcff207375e90675dbebfadcf82370abc654737d",
"",
"root"
],
[
"e",
"4416c4c3f3dd0672618d2f339af190bc5ff452fe29d80ce89bc863e2ba3f62e7",
"",
"reply"
],
[
"p",
"421e1241aa8e9b5cefc15c0afd6585b27498be477646dabe4a63839879206cea"
]
],
"content": "📅 Original date posted:2015-06-25\n📝 Original message:On 24 June 2015 1:49:51 PM AEST, Jeff Garzik \u003cjgarzik at gmail.com\u003e wrote:\n\u003eMiners can collude today to lower the block size limit.\n\nOf course they can. What, then, is the need for BIP100's hard-limit voting mechanism?\n\nYou 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\nWouldn'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\n* but with a safer \"supermajority\" than 75% please :)\n-- \nSent from my Android device with K-9 Mail. Please excuse my brevity.",
"sig": "6acf7d9f95f63ea25185cf4116f83bb11fe9feef0d3d7e9155d34317f55b5b50942b71e58c4fce21f55b61ea63dba06714d5d2bf472b1a6021c96e5f8470aa3f"
}