📅 Original date posted:2016-12-10
📝 Original message:Miners individually have an incentive to include every transaction they can
when they mine a block, but they also sometimes have an incentive to
collectively cooperate to reduce throughput to make more money as a group.
Under schemes where limits can be adjusted both possibilities must be taken
into account.
On Sat, Dec 10, 2016 at 4:40 PM, James Hilliard via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Miners in general are naturally incentivized to always mine max size
> blocks to maximize transaction fees simply because there is very
> little marginal cost to including extra transactions(there will always
> be a transaction backlog of some sort available to mine since demand
> for block space is effectively unbounded as fees approach 0 and they
> can even mine their own transactions without any fees). This proposal
> would almost certainly cause runaway block size growth and encourage
> much more miner centralization.
>
> On Sat, Dec 10, 2016 at 6:26 PM, t. khan via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > Miners 'gaming' the Block75 system -
> > There is no financial incentive for miners to attempt to game the Block75
> > system. Even if it were attempted and assuming the goal was to create
> bigger
> > blocks, the maximum possible increase would be 25% over the previous
> block
> > size. And, that size would only last for two weeks before readjusting
> down.
> > It would cost them more in transaction fees to stuff the network than
> they
> > could ever make up. To game the system, they'd have to game it forever
> with
> > no possibility of profit.
> >
> > Blocks would get too big -
> > Eventually, blocks would get too big, but only if bandwidth stopped
> > increasing and the cost of disk space stopped decreasing. Otherwise, the
> > incremental adjustments made by Block75 (especially in combination with
> > SegWit) wouldn't break anyone's connection or result in significantly
> more
> > orphaned blocks.
> >
> > The frequent and small adjustments made by Block75 have the added
> benefit of
> > being more easily adapted to, both psychologically and technologically,
> with
> > regards to miners/node operators.
> >
> > -t.k
> >
> > On Sat, Dec 10, 2016 at 5:44 AM, s7r via bitcoin-dev
> > <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >>
> >> t. khan via bitcoin-dev wrote:
> >> > BIP Proposal - Managing Bitcoin’s block size the same way we do
> >> > difficulty (aka Block75)
> >> >
> >> > The every two-week adjustment of difficulty has proven to be a
> >> > reasonably effective and predictable way of managing how quickly
> blocks
> >> > are mined. Bitcoin needs a reasonably effective and predictable way of
> >> > managing the maximum block size.
> >> >
> >> > It’s clear at this point that human beings should not be involved in
> the
> >> > determination of max block size, just as they’re not involved in
> >> > deciding the difficulty.
> >> >
> >> > Instead of setting an arbitrary max block size (1MB, 2MB, 8MB, etc.)
> or
> >> > passing the decision to miners/pool operators, the max block size
> should
> >> > be adjusted every two weeks (2016 blocks) using a system similar to
> how
> >> > difficulty is calculated.
> >> >
> >> > Put another way: let’s stop thinking about what the max block size
> >> > should be and start thinking about how full we want the average block
> to
> >> > be regardless of size. Over the last year, we’ve had averages of 75%
> or
> >> > higher, so aiming for 75% full seems reasonable, hence naming this
> >> > concept ‘Block75’.
> >> >
> >> > The target capacity over 2016 blocks would be 75%. If the last 2016
> >> > blocks are more than 75% full, add the difference to the max block
> size.
> >> > Like this:
> >> >
> >> > MAX_BLOCK_BASE_SIZE = 1000000
> >> > TARGET_CAPACITY = 750000
> >> > AVERAGE_OVER_CAP = average block size of last 2016 blocks minus
> >> > TARGET_CAPACITY
> >> >
> >> > To check if a block is valid, ≤ (MAX_BLOCK_BASE_SIZE +
> AVERAGE_OVER_CAP)
> >> >
> >> > For example, if the last 2016 blocks are 85% full (average block is
> 850
> >> > KB), add 10% to the max block size. The new max block size would be
> >> > 1,100 KB until the next 2016 blocks are mined, then reset and
> >> > recalculate. The 1,000,000 byte limit that exists currently would
> >> > remain, but would effectively be the minimum max block size.
> >> >
> >> > Another two weeks goes by, the last 2016 blocks are again 85% full,
> but
> >> > now that means they average 935 KB out of the 1,100 KB max block size.
> >> > This is 93.5% of the 1,000,000 byte limit, so 18.5% would be added to
> >> > that to make the new max block size of 1,185 KB.
> >> >
> >> > Another two weeks passes. This time, the average block is 1,050 KB.
> The
> >> > new max block size is calculated to 1,300 KB (as blocks were 105%
> full,
> >> > minus the 75% capacity target, so 30% added to max block size).
> >> >
> >> > Repeat every 2016 blocks, forever.
> >> >
> >> > If Block75 had been applied at the difficulty adjustment on November
> >> > 18th, the max block size would have been 1,080KB, as the average block
> >> > during that period was 83% full, so 8% is added to the 1,000KB limit.
> >> > The current size, after the December 2nd adjustment would be 1,150K.
> >> >
> >> > Block75 would allow the max block size to grow (or shrink) in response
> >> > to transaction volume, and does so predictably, reasonably quickly,
> and
> >> > in a method that prevents wild swings in block size or transaction
> fees.
> >> > It attempts to keep blocks at 75% total capacity over each two week
> >> > period, the same way difficulty tries to keep blocks mined every ten
> >> > minutes. It also keeps blocks as small as possible.
> >> >
> >> > Thoughts?
> >> >
> >> > -t.k.
> >> >
> >>
> >> I like the idea. It is good wrt growing the max. block size
> >> automatically without human action, but the main problem (or question)
> >> is not how to grow this number, it is what number can the network
> >> handle, considering both miners and users. While disk space requirements
> >> might not be a big problem, block propagation time is. The time required
> >> for a block to propagate in the network (or at least to all the miners)
> >> is directly dependent of its size. If blocks take too much time to
> >> propagate in the network, the orphan rate will increase in unpredictable
> >> ways. For example if the internet speed in China is worse than in
> >> Europe, and miners in China have more than 50% of the hashing power,
> >> blocks mined by European miners might get orphaned.
> >>
> >> The system as described can also be gamed, by filling the network with
> >> transactions. Miners have the monetary interest to include as many
> >> transactions as possible in a block in order to collect the fees.
> >> Regardless how you think about it, there has to be a maximum block size
> >> that the network will allow as a consensus rule. Increasing it
> >> dynamically based on transaction volume will reach a point where the
> >> number got big enough that it broke things. Bitcoin, because its
> >> fundamental design, can scale by using offchain solutions.
> >>
> >>
> >> _______________________________________________
> >> bitcoin-dev mailing list
> >> bitcoin-dev at lists.linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >>
> >
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161210/d2b72e8b/attachment-0001.html>;
Bram Cohen [ARCHIVE] /
npub1ld…t8ur6
2023-06-07 17:54:48
in reply to nevent1q…zfam
Author Public Key
npub1ldcq03p2qe58u0xnlwa35wchjuhz49y6ueu5ghmtjetez9xstnvsmt8ur6Published at
2023-06-07 17:54:48Event JSON
{
"id": "691ab55a1ba35373a5a63554744dfca797083364becad3cc60c39bd5da88e449",
"pubkey": "fb7007c42a06687e3cd3fbbb1a3b17972e2a949ae679445f6b96579114d05cd9",
"created_at": 1686160488,
"kind": 1,
"tags": [
[
"e",
"93f229f84c7a0d580081719bdeab8a0791a31bea972b61b4a96af898141b5a6b",
"",
"root"
],
[
"e",
"48bedcdd79b64926c962f43d821d0d670cf9b3924c619d89f8b8ab56036b43d2",
"",
"reply"
],
[
"p",
"78cadd65bb98ff2b50ae825fa100352d7f102e41ec5caad2e4d2e99e00df1394"
]
],
"content": "📅 Original date posted:2016-12-10\n📝 Original message:Miners individually have an incentive to include every transaction they can\nwhen they mine a block, but they also sometimes have an incentive to\ncollectively cooperate to reduce throughput to make more money as a group.\nUnder schemes where limits can be adjusted both possibilities must be taken\ninto account.\n\nOn Sat, Dec 10, 2016 at 4:40 PM, James Hilliard via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Miners in general are naturally incentivized to always mine max size\n\u003e blocks to maximize transaction fees simply because there is very\n\u003e little marginal cost to including extra transactions(there will always\n\u003e be a transaction backlog of some sort available to mine since demand\n\u003e for block space is effectively unbounded as fees approach 0 and they\n\u003e can even mine their own transactions without any fees). This proposal\n\u003e would almost certainly cause runaway block size growth and encourage\n\u003e much more miner centralization.\n\u003e\n\u003e On Sat, Dec 10, 2016 at 6:26 PM, t. khan via bitcoin-dev\n\u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \u003e Miners 'gaming' the Block75 system -\n\u003e \u003e There is no financial incentive for miners to attempt to game the Block75\n\u003e \u003e system. Even if it were attempted and assuming the goal was to create\n\u003e bigger\n\u003e \u003e blocks, the maximum possible increase would be 25% over the previous\n\u003e block\n\u003e \u003e size. And, that size would only last for two weeks before readjusting\n\u003e down.\n\u003e \u003e It would cost them more in transaction fees to stuff the network than\n\u003e they\n\u003e \u003e could ever make up. To game the system, they'd have to game it forever\n\u003e with\n\u003e \u003e no possibility of profit.\n\u003e \u003e\n\u003e \u003e Blocks would get too big -\n\u003e \u003e Eventually, blocks would get too big, but only if bandwidth stopped\n\u003e \u003e increasing and the cost of disk space stopped decreasing. Otherwise, the\n\u003e \u003e incremental adjustments made by Block75 (especially in combination with\n\u003e \u003e SegWit) wouldn't break anyone's connection or result in significantly\n\u003e more\n\u003e \u003e orphaned blocks.\n\u003e \u003e\n\u003e \u003e The frequent and small adjustments made by Block75 have the added\n\u003e benefit of\n\u003e \u003e being more easily adapted to, both psychologically and technologically,\n\u003e with\n\u003e \u003e regards to miners/node operators.\n\u003e \u003e\n\u003e \u003e -t.k\n\u003e \u003e\n\u003e \u003e On Sat, Dec 10, 2016 at 5:44 AM, s7r via bitcoin-dev\n\u003e \u003e \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e \u003e\u003e\n\u003e \u003e\u003e t. khan via bitcoin-dev wrote:\n\u003e \u003e\u003e \u003e BIP Proposal - Managing Bitcoin’s block size the same way we do\n\u003e \u003e\u003e \u003e difficulty (aka Block75)\n\u003e \u003e\u003e \u003e\n\u003e \u003e\u003e \u003e The every two-week adjustment of difficulty has proven to be a\n\u003e \u003e\u003e \u003e reasonably effective and predictable way of managing how quickly\n\u003e blocks\n\u003e \u003e\u003e \u003e are mined. Bitcoin needs a reasonably effective and predictable way of\n\u003e \u003e\u003e \u003e managing the maximum block size.\n\u003e \u003e\u003e \u003e\n\u003e \u003e\u003e \u003e It’s clear at this point that human beings should not be involved in\n\u003e the\n\u003e \u003e\u003e \u003e determination of max block size, just as they’re not involved in\n\u003e \u003e\u003e \u003e deciding the difficulty.\n\u003e \u003e\u003e \u003e\n\u003e \u003e\u003e \u003e Instead of setting an arbitrary max block size (1MB, 2MB, 8MB, etc.)\n\u003e or\n\u003e \u003e\u003e \u003e passing the decision to miners/pool operators, the max block size\n\u003e should\n\u003e \u003e\u003e \u003e be adjusted every two weeks (2016 blocks) using a system similar to\n\u003e how\n\u003e \u003e\u003e \u003e difficulty is calculated.\n\u003e \u003e\u003e \u003e\n\u003e \u003e\u003e \u003e Put another way: let’s stop thinking about what the max block size\n\u003e \u003e\u003e \u003e should be and start thinking about how full we want the average block\n\u003e to\n\u003e \u003e\u003e \u003e be regardless of size. Over the last year, we’ve had averages of 75%\n\u003e or\n\u003e \u003e\u003e \u003e higher, so aiming for 75% full seems reasonable, hence naming this\n\u003e \u003e\u003e \u003e concept ‘Block75’.\n\u003e \u003e\u003e \u003e\n\u003e \u003e\u003e \u003e The target capacity over 2016 blocks would be 75%. If the last 2016\n\u003e \u003e\u003e \u003e blocks are more than 75% full, add the difference to the max block\n\u003e size.\n\u003e \u003e\u003e \u003e Like this:\n\u003e \u003e\u003e \u003e\n\u003e \u003e\u003e \u003e MAX_BLOCK_BASE_SIZE = 1000000\n\u003e \u003e\u003e \u003e TARGET_CAPACITY = 750000\n\u003e \u003e\u003e \u003e AVERAGE_OVER_CAP = average block size of last 2016 blocks minus\n\u003e \u003e\u003e \u003e TARGET_CAPACITY\n\u003e \u003e\u003e \u003e\n\u003e \u003e\u003e \u003e To check if a block is valid, ≤ (MAX_BLOCK_BASE_SIZE +\n\u003e AVERAGE_OVER_CAP)\n\u003e \u003e\u003e \u003e\n\u003e \u003e\u003e \u003e For example, if the last 2016 blocks are 85% full (average block is\n\u003e 850\n\u003e \u003e\u003e \u003e KB), add 10% to the max block size. The new max block size would be\n\u003e \u003e\u003e \u003e 1,100 KB until the next 2016 blocks are mined, then reset and\n\u003e \u003e\u003e \u003e recalculate. The 1,000,000 byte limit that exists currently would\n\u003e \u003e\u003e \u003e remain, but would effectively be the minimum max block size.\n\u003e \u003e\u003e \u003e\n\u003e \u003e\u003e \u003e Another two weeks goes by, the last 2016 blocks are again 85% full,\n\u003e but\n\u003e \u003e\u003e \u003e now that means they average 935 KB out of the 1,100 KB max block size.\n\u003e \u003e\u003e \u003e This is 93.5% of the 1,000,000 byte limit, so 18.5% would be added to\n\u003e \u003e\u003e \u003e that to make the new max block size of 1,185 KB.\n\u003e \u003e\u003e \u003e\n\u003e \u003e\u003e \u003e Another two weeks passes. This time, the average block is 1,050 KB.\n\u003e The\n\u003e \u003e\u003e \u003e new max block size is calculated to 1,300 KB (as blocks were 105%\n\u003e full,\n\u003e \u003e\u003e \u003e minus the 75% capacity target, so 30% added to max block size).\n\u003e \u003e\u003e \u003e\n\u003e \u003e\u003e \u003e Repeat every 2016 blocks, forever.\n\u003e \u003e\u003e \u003e\n\u003e \u003e\u003e \u003e If Block75 had been applied at the difficulty adjustment on November\n\u003e \u003e\u003e \u003e 18th, the max block size would have been 1,080KB, as the average block\n\u003e \u003e\u003e \u003e during that period was 83% full, so 8% is added to the 1,000KB limit.\n\u003e \u003e\u003e \u003e The current size, after the December 2nd adjustment would be 1,150K.\n\u003e \u003e\u003e \u003e\n\u003e \u003e\u003e \u003e Block75 would allow the max block size to grow (or shrink) in response\n\u003e \u003e\u003e \u003e to transaction volume, and does so predictably, reasonably quickly,\n\u003e and\n\u003e \u003e\u003e \u003e in a method that prevents wild swings in block size or transaction\n\u003e fees.\n\u003e \u003e\u003e \u003e It attempts to keep blocks at 75% total capacity over each two week\n\u003e \u003e\u003e \u003e period, the same way difficulty tries to keep blocks mined every ten\n\u003e \u003e\u003e \u003e minutes. It also keeps blocks as small as possible.\n\u003e \u003e\u003e \u003e\n\u003e \u003e\u003e \u003e Thoughts?\n\u003e \u003e\u003e \u003e\n\u003e \u003e\u003e \u003e -t.k.\n\u003e \u003e\u003e \u003e\n\u003e \u003e\u003e\n\u003e \u003e\u003e I like the idea. It is good wrt growing the max. block size\n\u003e \u003e\u003e automatically without human action, but the main problem (or question)\n\u003e \u003e\u003e is not how to grow this number, it is what number can the network\n\u003e \u003e\u003e handle, considering both miners and users. While disk space requirements\n\u003e \u003e\u003e might not be a big problem, block propagation time is. The time required\n\u003e \u003e\u003e for a block to propagate in the network (or at least to all the miners)\n\u003e \u003e\u003e is directly dependent of its size. If blocks take too much time to\n\u003e \u003e\u003e propagate in the network, the orphan rate will increase in unpredictable\n\u003e \u003e\u003e ways. For example if the internet speed in China is worse than in\n\u003e \u003e\u003e Europe, and miners in China have more than 50% of the hashing power,\n\u003e \u003e\u003e blocks mined by European miners might get orphaned.\n\u003e \u003e\u003e\n\u003e \u003e\u003e The system as described can also be gamed, by filling the network with\n\u003e \u003e\u003e transactions. Miners have the monetary interest to include as many\n\u003e \u003e\u003e transactions as possible in a block in order to collect the fees.\n\u003e \u003e\u003e Regardless how you think about it, there has to be a maximum block size\n\u003e \u003e\u003e that the network will allow as a consensus rule. Increasing it\n\u003e \u003e\u003e dynamically based on transaction volume will reach a point where the\n\u003e \u003e\u003e number got big enough that it broke things. Bitcoin, because its\n\u003e \u003e\u003e fundamental design, can scale by using offchain solutions.\n\u003e \u003e\u003e\n\u003e \u003e\u003e\n\u003e \u003e\u003e _______________________________________________\n\u003e \u003e\u003e bitcoin-dev mailing list\n\u003e \u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e \u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e \u003e\u003e\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e _______________________________________________\n\u003e \u003e bitcoin-dev mailing list\n\u003e \u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e \u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e \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\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161210/d2b72e8b/attachment-0001.html\u003e",
"sig": "1615ac7784a84f24873f1cab4883ea324a7bd01bc9bd2cbaa7a3b6facb36fb26f97299e082fc3210a5e39d328853366a582ccbcc26faf254be2849028727a36f"
}