Matt Corallo [ARCHIVE] on Nostr: 📅 Original date posted:2015-05-06 📝 Original message:On 05/06/15 23:33, Tier ...
📅 Original date posted:2015-05-06
📝 Original message:On 05/06/15 23:33, Tier Nolan wrote:
> On Thu, May 7, 2015 at 12:12 AM, Matt Corallo <bitcoin-list at bluematt.me
> <mailto:bitcoin-list at bluematt.me>> wrote:
>
> The point of the hard block size limit is exactly because giving miners
> free rule to do anything they like with their blocks would allow them to
> do any number of crazy attacks. The incentives for miners to pick block
> sizes are no where near compatible with what allows the network to
> continue to run in a decentralized manner.
>
>
> Miners can always reduce the block size (if they coordinate).
> Increasing the maximum block size doesn't necessarily cause an
> increase. A majority of miners can soft-fork to set the limit lower
> than the hard limit.
Sure, of course.
> Setting the hard-fork limit higher means that a soft fork can be used to
> adjust the limit in the future.
>
> The reference client would accept blocks above the soft limit for wallet
> purposes, but not build on them. Blocks above the hard limit would be
> rejected completely.
Yes, but this does NOT make an actual policy. Note that the vast
majority of miners already apply their own patches to Bitcoin Core, so
applying one more is not all that hard. When blocks start to become
limited (ie there is any fee left on the table by transactions not
included in a block) there becomes incentive for miners to change that
behavior pretty quick. Not just that, the vast majority of the hashpower
is behind very large miners, who have little to no decentralization
pressure. This results in very incompatible incentives, mainly that the
incentive would be for the large miners to interconnect in a private
network and generate only maximum-size blocks, creating a strong
centralization pressure in the network.
Published at
2023-06-07 15:33:02Event JSON
{
"id": "9b837473a54f7db32d64a977e85d1d0c07983daa818fef57ae990235087682ec",
"pubkey": "cd753aa8fbc112e14ffe9fe09d3630f0eff76ca68e376e004b8e77b687adddba",
"created_at": 1686151982,
"kind": 1,
"tags": [
[
"e",
"0def597b074aa190bf159e12f9433ea74d157ee52321b38d195ba644ad5c177f",
"",
"root"
],
[
"e",
"c375464bf200928221cc3f032605bbc967081ae33c6c14d975525e809a40c142",
"",
"reply"
],
[
"p",
"46986f86b97cc97829a031b03209644d134b939d0163375467f0b1363e0d875e"
]
],
"content": "📅 Original date posted:2015-05-06\n📝 Original message:On 05/06/15 23:33, Tier Nolan wrote:\n\u003e On Thu, May 7, 2015 at 12:12 AM, Matt Corallo \u003cbitcoin-list at bluematt.me\n\u003e \u003cmailto:bitcoin-list at bluematt.me\u003e\u003e wrote:\n\u003e \n\u003e The point of the hard block size limit is exactly because giving miners\n\u003e free rule to do anything they like with their blocks would allow them to\n\u003e do any number of crazy attacks. The incentives for miners to pick block\n\u003e sizes are no where near compatible with what allows the network to\n\u003e continue to run in a decentralized manner.\n\u003e \n\u003e \n\u003e Miners can always reduce the block size (if they coordinate). \n\u003e Increasing the maximum block size doesn't necessarily cause an\n\u003e increase. A majority of miners can soft-fork to set the limit lower\n\u003e than the hard limit.\n\nSure, of course.\n\n\u003e Setting the hard-fork limit higher means that a soft fork can be used to\n\u003e adjust the limit in the future. \n\u003e \n\u003e The reference client would accept blocks above the soft limit for wallet\n\u003e purposes, but not build on them. Blocks above the hard limit would be\n\u003e rejected completely.\n\nYes, but this does NOT make an actual policy. Note that the vast\nmajority of miners already apply their own patches to Bitcoin Core, so\napplying one more is not all that hard. When blocks start to become\nlimited (ie there is any fee left on the table by transactions not\nincluded in a block) there becomes incentive for miners to change that\nbehavior pretty quick. Not just that, the vast majority of the hashpower\nis behind very large miners, who have little to no decentralization\npressure. This results in very incompatible incentives, mainly that the\nincentive would be for the large miners to interconnect in a private\nnetwork and generate only maximum-size blocks, creating a strong\ncentralization pressure in the network.",
"sig": "b6e62349429e9294cd4c45e063ce5f47e069db69b0e44ea4c90e860612b2cc2670313a492a0ee96261412453c0dcb805683dc8272e8b0abac15005fab567bcd9"
}