📅 Original date posted:2016-12-11
📝 Original message:What's most likely to happen is miners will max out the blocks they
mine simply to try and get as many transaction fees as possible like
they are doing right now(there will be a backlog of transactions at
any block size). Having the block size double every year would likely
cause major problems and this proposal allows over a 7x increase it
seems.
The main problem with this proposal I think is that users effectively
have no way to stop the miners from increasing block size
continuously.
On Sun, Dec 11, 2016 at 1:55 PM, t. khan via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> On Sun, Dec 11, 2016 at 12:11 PM, s7r <s7r at sky-ip.org> wrote:
>>
>>
>> This is an incentive, if few miners agree to create a large conglomerate
>> that will ultimately control the network.
>>
>> You miss something obvious that makes this attack actually free of cost.
>> Nothing will "cost them more in transaction fees". A miner can create
>> thousands of transactions paying to himself, and not broadcast them to
>> the network, but hold them and include them in the blocks he mines. The
>> fees are collected by him because transactions are included in a block
>> that he mined and the left amount is in another wallet of the same
>> person. Repeat this continuously to fill blocks.
>
>
> No, that wasn't overlooked. Miners could indeed stuff their own blocks for
> free, but they can't stuff blocks mined by others for free.
>
> In the hypothetical scenario where there is a single mining pool which mines
> most (if not all) of the blocks, we would have much larger problems than
> their ability to raise the max block size gradually. Even if they were able
> to fill 100% of the blocks for an entire year, the max block size for that
> 2016 block period would be 7.25MB (not accounting for SegWit). After the
> whole year they would have made no extra profit vs doing nothing. And as
> soon as they stopped this scheme, block size would spring back to it's
> natural level.
>
> The good news is, this scenario has never happened and even when we've come
> remotely close (when ASICs first shipped), the situation was temporary. The
> odds of this happening in the future and persisting long enough to have any
> major effect with Block75 are very close to zero.
>
>>
>> Topology and bandwidth speed / hash rate of the network cannot be
>> controlled - if we make assumptions about these it might have terrible
>> consequences.
>>
>> Even if we take in consideration that bandwidth will only grow and disk
>> space will only cost less (which is not something we can safely assume,
>> by the way) the hard limit max. block size cannot grow to unlimited
>> value (even if the growth happens over time). There is also a validation
>> cost in time for each block, for the health of the network any node
>> should be able to download _and_ validate a block, before next block
>> gets mined.
>>
>> You said in another post that a permanent solution is preferred, rather
>> than kicking the can down the road. I fully agree, as well as many
>> others reading this list, but the permanent solution doesn't necessarily
>> have to be increasing the max block size dynamically.
>
>
> Increasing *and* decreasing max block size dynamically. Block75 is
> self-correcting, whereas any solution with hardcoded limits can't correct
> without human intervention and would rely on our ability to predict the
> future (which as you pointed out, we can't do). Therefore, any solution
> that's not dynamic cannot be permanent.
>
> Additionally, the frequent and gradual changes in max block size would allow
> us to see any consequences well in advance (years probably).
>
>>
>> If you think about it the other way around, dynamically growing the max
>> block size is also kicking the can down the road ... just without having
>> to touch it and get dust on the boot ;)
>
>
> Not having to touch it again = permanent solution. ;)
>
> It would be helpful if some others would run the numbers on how Block75
> would adjust the block size over time:
>
> new max block size = 1000kb + (average block size over last 2016 blocks -
> 750kb)
>
> -t.k.
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
James Hilliard [ARCHIVE] /
npub10r…kgk2d
2023-06-07 17:54:49
in reply to nevent1q…wz5t
Author Public Key
npub10r9d6edmnrljk59wsf06zqp494l3qtjpa3w245hy6t5euqxlzw2qdkgk2dPublished at
2023-06-07 17:54:49Event JSON
{
"id": "8112169647c7c70f20d3fa479163f09712ebc28eb8aa64e4a5236c93d6b18472",
"pubkey": "78cadd65bb98ff2b50ae825fa100352d7f102e41ec5caad2e4d2e99e00df1394",
"created_at": 1686160489,
"kind": 1,
"tags": [
[
"e",
"93f229f84c7a0d580081719bdeab8a0791a31bea972b61b4a96af898141b5a6b",
"",
"root"
],
[
"e",
"17a3edc13d348a1ed8652e23183452898a6dac4fd2bbd921d86250a82ecce765",
"",
"reply"
],
[
"p",
"ff03c864f82439d99b0101ef56c551a14c6165a2948f11edcca90650193bbac4"
]
],
"content": "📅 Original date posted:2016-12-11\n📝 Original message:What's most likely to happen is miners will max out the blocks they\nmine simply to try and get as many transaction fees as possible like\nthey are doing right now(there will be a backlog of transactions at\nany block size). Having the block size double every year would likely\ncause major problems and this proposal allows over a 7x increase it\nseems.\n\nThe main problem with this proposal I think is that users effectively\nhave no way to stop the miners from increasing block size\ncontinuously.\n\nOn Sun, Dec 11, 2016 at 1:55 PM, t. khan via bitcoin-dev\n\u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e On Sun, Dec 11, 2016 at 12:11 PM, s7r \u003cs7r at sky-ip.org\u003e wrote:\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e This is an incentive, if few miners agree to create a large conglomerate\n\u003e\u003e that will ultimately control the network.\n\u003e\u003e\n\u003e\u003e You miss something obvious that makes this attack actually free of cost.\n\u003e\u003e Nothing will \"cost them more in transaction fees\". A miner can create\n\u003e\u003e thousands of transactions paying to himself, and not broadcast them to\n\u003e\u003e the network, but hold them and include them in the blocks he mines. The\n\u003e\u003e fees are collected by him because transactions are included in a block\n\u003e\u003e that he mined and the left amount is in another wallet of the same\n\u003e\u003e person. Repeat this continuously to fill blocks.\n\u003e\n\u003e\n\u003e No, that wasn't overlooked. Miners could indeed stuff their own blocks for\n\u003e free, but they can't stuff blocks mined by others for free.\n\u003e\n\u003e In the hypothetical scenario where there is a single mining pool which mines\n\u003e most (if not all) of the blocks, we would have much larger problems than\n\u003e their ability to raise the max block size gradually. Even if they were able\n\u003e to fill 100% of the blocks for an entire year, the max block size for that\n\u003e 2016 block period would be 7.25MB (not accounting for SegWit). After the\n\u003e whole year they would have made no extra profit vs doing nothing. And as\n\u003e soon as they stopped this scheme, block size would spring back to it's\n\u003e natural level.\n\u003e\n\u003e The good news is, this scenario has never happened and even when we've come\n\u003e remotely close (when ASICs first shipped), the situation was temporary. The\n\u003e odds of this happening in the future and persisting long enough to have any\n\u003e major effect with Block75 are very close to zero.\n\u003e\n\u003e\u003e\n\u003e\u003e Topology and bandwidth speed / hash rate of the network cannot be\n\u003e\u003e controlled - if we make assumptions about these it might have terrible\n\u003e\u003e consequences.\n\u003e\u003e\n\u003e\u003e Even if we take in consideration that bandwidth will only grow and disk\n\u003e\u003e space will only cost less (which is not something we can safely assume,\n\u003e\u003e by the way) the hard limit max. block size cannot grow to unlimited\n\u003e\u003e value (even if the growth happens over time). There is also a validation\n\u003e\u003e cost in time for each block, for the health of the network any node\n\u003e\u003e should be able to download _and_ validate a block, before next block\n\u003e\u003e gets mined.\n\u003e\u003e\n\u003e\u003e You said in another post that a permanent solution is preferred, rather\n\u003e\u003e than kicking the can down the road. I fully agree, as well as many\n\u003e\u003e others reading this list, but the permanent solution doesn't necessarily\n\u003e\u003e have to be increasing the max block size dynamically.\n\u003e\n\u003e\n\u003e Increasing *and* decreasing max block size dynamically. Block75 is\n\u003e self-correcting, whereas any solution with hardcoded limits can't correct\n\u003e without human intervention and would rely on our ability to predict the\n\u003e future (which as you pointed out, we can't do). Therefore, any solution\n\u003e that's not dynamic cannot be permanent.\n\u003e\n\u003e Additionally, the frequent and gradual changes in max block size would allow\n\u003e us to see any consequences well in advance (years probably).\n\u003e\n\u003e\u003e\n\u003e\u003e If you think about it the other way around, dynamically growing the max\n\u003e\u003e block size is also kicking the can down the road ... just without having\n\u003e\u003e to touch it and get dust on the boot ;)\n\u003e\n\u003e\n\u003e Not having to touch it again = permanent solution. ;)\n\u003e\n\u003e It would be helpful if some others would run the numbers on how Block75\n\u003e would adjust the block size over time:\n\u003e\n\u003e new max block size = 1000kb + (average block size over last 2016 blocks -\n\u003e 750kb)\n\u003e\n\u003e -t.k.\n\u003e\n\u003e\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\u003e",
"sig": "34534476649b9dda762c537cbcad2aec72a2c71c86206857ff090e3beee85f93d7b9abcef5ebaf0faacfd286223c47bd9e6314694a242e8f20fd95ce0274699b"
}