* [bitcoin-dev] Consensus based block size retargeting algorithm (draft)
@ 2015-08-21 22:22 Btc Drak
2015-08-21 23:17 ` Paul Sztorc
2015-08-22 0:06 ` Ahmed Zsales
0 siblings, 2 replies; 26+ messages in thread
From: Btc Drak @ 2015-08-21 22:22 UTC (permalink / raw)
To: Bitcoin Dev
I wanted to offer a potential way to adjust the block size limit in a
democratic way without making it easy to game. This is meant only as a
starting point for a general idea. Thresholds and exact figures and
the details of the algorithm are up for debate, and possibly some
formula based determination.
The living document is currently a gist available at
https://gist.github.com/btcdrak/1c3a323100a912b605b5
<pre>
BIP: XX
Title: Consensus based block size retargeting algorithm
Author: BtcDrak <btcdrak@gmail•com>
Status: Draft
Type: Standards Track
Created: 2015-08-21
</pre>
==Abstract==
A method of altering the maximum allowed block size of the Bitcoin
protocol using a consensus based approach.
==Motivation==
There is a perception that Bitcoin cannot easily respond to raising
the blocksize limit if popularity was to suddenly increase due to a
mass adoption curve, because co-ordinating a hard fork takes
considerable time, and being unable to respond in a timely manner
would irreparably harm the credibility of bitcoin.
Additionally, predetermined block size increases are problematic
because they attempt to predict the future, and if too large could
have unintended consequences like damaging the possibility for a fee
market to develop as block subsidy decreases substantially over the
next 9 years; introducing or exacerbating mining attack vectors; or
somehow affect the network in unknown or unpredicted ways. Since fixed
changes are hard to deploy, the damage could be extensive.
Dynamic block size adjustments also suffer from the potential to be
gamed by the larger hash power.
==Rationale==
By introducing a cost to increase the block size ensures the mining
community will collude to increase it only when there is a clear
necessity, and reduce it when it is unnecessary. Rogue miners cannot
force their wishes so easily because not only will they have to pay
extra a difficulty target, then can be downvoted at no cost by the
objecting hash power.
==Specification==
The initial "base block size limit" shall be 1MB.
Miners can vote for a block size increase by signalling the proposed
percentage increase of the "base block size limit" in the coinbase
field. For the vote to be considered valid the block they mine must
meets a difficulty target which is proportionally larger than the
standard difficulty target based on the percentage increase they voted
for. If a miner does not vote, or the vote is invalid, it shall be
counted as a vote for no change.
Miners may vote the size down by signalling in the coinbase field
without paying a difficulty penalty.
Every 2016 blocks, the maximum allowed block size will be recalculated
by the average of all votes in the last 2016 blocks, i.e. sum each
vote from each block and divide by 2016 then multiply by the base
block size limit. This will redefine the base block size limit for the
next 2016 blocks.
Blocks that are larger than the calculated base block size limit are
invalid and MUST be rejected.
The maximum change up or down each retargeting period shall be limited
to 10% of the base block size limit.
The maximum block size may not increase above 8MB.
Votes shall be cast by adding the following human readable multiplier
to the coinbase string “/BXn.nnn/” where valid votes would exist
between the ranges “/BX0.900/” (10% decrease) and “/BX1.100/” (10%
increase). “/BX1.000/” would be a vote for no change. Invalid votes
will be counted as a vote for no change: “/BX1.000/”.
==Acknowledgements==
This proposal is based on ideas and concepts derived from the writings
of Meni Rosenfeld and Gregory Maxwell.
==Copyright==
This work is placed in the public domain.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft)
2015-08-21 22:22 [bitcoin-dev] Consensus based block size retargeting algorithm (draft) Btc Drak
@ 2015-08-21 23:17 ` Paul Sztorc
2015-08-22 0:06 ` Ahmed Zsales
1 sibling, 0 replies; 26+ messages in thread
From: Paul Sztorc @ 2015-08-21 23:17 UTC (permalink / raw)
To: Btc Drak, Bitcoin Dev
You said:
> There is a perception that Bitcoin cannot easily respond to raising
the blocksize limit if popularity was to suddenly increase
From this, my understanding is that you are operating on the principle
that "the optimum blocksize" is related to "popularity/use of Bitcoin".
It seems that others on this list instead feel that "the optimum
blocksize" is a function of "technical limitations (namely bandwidth)".
Do you acknowledge this as an irreconcilable difference in approach?
Also, I'm not sure, but your principle would seem to imply that
"outsourcing the decision to Miners" is superfluous. You are concerned
(according to you) with "not reacting to 'popularity' quickly enough",
and you are only against "predetermined increases" and "hashpower
influences" (according to you), so why not measure "popularity" directly
(by using "transaction volume" or "fees paid") and use that number to
set the blocksize?
--
However, thank you very much for actually stating a principle. Unless
one knows what a person's principle is, one *can't even check if* what
they are saying makes any sense (according to *them*), so my completely
sincere congratulations on an intelligible email.
On 8/21/2015 6:22 PM, Btc Drak via bitcoin-dev wrote:
> I wanted to offer a potential way to adjust the block size limit in a
> democratic way without making it easy to game. This is meant only as a
> starting point for a general idea. Thresholds and exact figures and
> the details of the algorithm are up for debate, and possibly some
> formula based determination.
>
> The living document is currently a gist available at
> https://gist.github.com/btcdrak/1c3a323100a912b605b5
>
>
> <pre>
> BIP: XX
> Title: Consensus based block size retargeting algorithm
> Author: BtcDrak <btcdrak@gmail•com>
> Status: Draft
> Type: Standards Track
> Created: 2015-08-21
> </pre>
>
> ==Abstract==
>
> A method of altering the maximum allowed block size of the Bitcoin
> protocol using a consensus based approach.
>
> ==Motivation==
>
> There is a perception that Bitcoin cannot easily respond to raising
> the blocksize limit if popularity was to suddenly increase due to a
> mass adoption curve, because co-ordinating a hard fork takes
> considerable time, and being unable to respond in a timely manner
> would irreparably harm the credibility of bitcoin.
>
> Additionally, predetermined block size increases are problematic
> because they attempt to predict the future, and if too large could
> have unintended consequences like damaging the possibility for a fee
> market to develop as block subsidy decreases substantially over the
> next 9 years; introducing or exacerbating mining attack vectors; or
> somehow affect the network in unknown or unpredicted ways. Since fixed
> changes are hard to deploy, the damage could be extensive.
>
> Dynamic block size adjustments also suffer from the potential to be
> gamed by the larger hash power.
>
>
> ==Rationale==
>
> By introducing a cost to increase the block size ensures the mining
> community will collude to increase it only when there is a clear
> necessity, and reduce it when it is unnecessary. Rogue miners cannot
> force their wishes so easily because not only will they have to pay
> extra a difficulty target, then can be downvoted at no cost by the
> objecting hash power.
>
>
> ==Specification==
>
> The initial "base block size limit" shall be 1MB.
>
> Miners can vote for a block size increase by signalling the proposed
> percentage increase of the "base block size limit" in the coinbase
> field. For the vote to be considered valid the block they mine must
> meets a difficulty target which is proportionally larger than the
> standard difficulty target based on the percentage increase they voted
> for. If a miner does not vote, or the vote is invalid, it shall be
> counted as a vote for no change.
>
> Miners may vote the size down by signalling in the coinbase field
> without paying a difficulty penalty.
>
> Every 2016 blocks, the maximum allowed block size will be recalculated
> by the average of all votes in the last 2016 blocks, i.e. sum each
> vote from each block and divide by 2016 then multiply by the base
> block size limit. This will redefine the base block size limit for the
> next 2016 blocks.
>
> Blocks that are larger than the calculated base block size limit are
> invalid and MUST be rejected.
>
> The maximum change up or down each retargeting period shall be limited
> to 10% of the base block size limit.
>
> The maximum block size may not increase above 8MB.
>
> Votes shall be cast by adding the following human readable multiplier
> to the coinbase string “/BXn.nnn/” where valid votes would exist
> between the ranges “/BX0.900/” (10% decrease) and “/BX1.100/” (10%
> increase). “/BX1.000/” would be a vote for no change. Invalid votes
> will be counted as a vote for no change: “/BX1.000/”.
>
>
> ==Acknowledgements==
>
> This proposal is based on ideas and concepts derived from the writings
> of Meni Rosenfeld and Gregory Maxwell.
>
>
> ==Copyright==
>
> This work is placed in the public domain.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft)
2015-08-21 22:22 [bitcoin-dev] Consensus based block size retargeting algorithm (draft) Btc Drak
2015-08-21 23:17 ` Paul Sztorc
@ 2015-08-22 0:06 ` Ahmed Zsales
2015-08-28 20:28 ` Btc Drak
1 sibling, 1 reply; 26+ messages in thread
From: Ahmed Zsales @ 2015-08-22 0:06 UTC (permalink / raw)
To: Btc Drak; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 5515 bytes --]
Interesting.
Unless I misunderstand the proposal, you would have to factor a way to deal
with miner cartel behavior. A few emails every week and the larger miners
could collude to set prices.
With that figured, then your voting proposal could be triggered by a moving
day block average which takes into account capacity for any given period,
plus a level of headroom for unexpected spikes. The issue with this is
forward planning is more important, especially when the moving average is
longer than a week.
Credit card providers and retailers use a number of factors to plan for
capacity on a regional basis. From previous years figures, long-term
weather forecasts, annual calendar events, one off events, etc. A global
currency can't use many of these tools for forward planning.
E.g. religious holidays are among the biggest events for transactions; if
we take Christmas, your proposal could work out a capacity during a quiet
period in November leading to a downward adjustment which then sees
transactions getting maxed out during the two weeks before Christmas eve.
You could then have an upward adjustment, but people stop spending on
Christmas day.
These are human factors that need to be considered.
On Fri, Aug 21, 2015 at 11:22 PM, Btc Drak via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> I wanted to offer a potential way to adjust the block size limit in a
> democratic way without making it easy to game. This is meant only as a
> starting point for a general idea. Thresholds and exact figures and
> the details of the algorithm are up for debate, and possibly some
> formula based determination.
>
> The living document is currently a gist available at
> https://gist.github.com/btcdrak/1c3a323100a912b605b5
>
>
> <pre>
> BIP: XX
> Title: Consensus based block size retargeting algorithm
> Author: BtcDrak <btcdrak@gmail•com>
> Status: Draft
> Type: Standards Track
> Created: 2015-08-21
> </pre>
>
> ==Abstract==
>
> A method of altering the maximum allowed block size of the Bitcoin
> protocol using a consensus based approach.
>
> ==Motivation==
>
> There is a perception that Bitcoin cannot easily respond to raising
> the blocksize limit if popularity was to suddenly increase due to a
> mass adoption curve, because co-ordinating a hard fork takes
> considerable time, and being unable to respond in a timely manner
> would irreparably harm the credibility of bitcoin.
>
> Additionally, predetermined block size increases are problematic
> because they attempt to predict the future, and if too large could
> have unintended consequences like damaging the possibility for a fee
> market to develop as block subsidy decreases substantially over the
> next 9 years; introducing or exacerbating mining attack vectors; or
> somehow affect the network in unknown or unpredicted ways. Since fixed
> changes are hard to deploy, the damage could be extensive.
>
> Dynamic block size adjustments also suffer from the potential to be
> gamed by the larger hash power.
>
>
> ==Rationale==
>
> By introducing a cost to increase the block size ensures the mining
> community will collude to increase it only when there is a clear
> necessity, and reduce it when it is unnecessary. Rogue miners cannot
> force their wishes so easily because not only will they have to pay
> extra a difficulty target, then can be downvoted at no cost by the
> objecting hash power.
>
>
> ==Specification==
>
> The initial "base block size limit" shall be 1MB.
>
> Miners can vote for a block size increase by signalling the proposed
> percentage increase of the "base block size limit" in the coinbase
> field. For the vote to be considered valid the block they mine must
> meets a difficulty target which is proportionally larger than the
> standard difficulty target based on the percentage increase they voted
> for. If a miner does not vote, or the vote is invalid, it shall be
> counted as a vote for no change.
>
> Miners may vote the size down by signalling in the coinbase field
> without paying a difficulty penalty.
>
> Every 2016 blocks, the maximum allowed block size will be recalculated
> by the average of all votes in the last 2016 blocks, i.e. sum each
> vote from each block and divide by 2016 then multiply by the base
> block size limit. This will redefine the base block size limit for the
> next 2016 blocks.
>
> Blocks that are larger than the calculated base block size limit are
> invalid and MUST be rejected.
>
> The maximum change up or down each retargeting period shall be limited
> to 10% of the base block size limit.
>
> The maximum block size may not increase above 8MB.
>
> Votes shall be cast by adding the following human readable multiplier
> to the coinbase string “/BXn.nnn/” where valid votes would exist
> between the ranges “/BX0.900/” (10% decrease) and “/BX1.100/” (10%
> increase). “/BX1.000/” would be a vote for no change. Invalid votes
> will be counted as a vote for no change: “/BX1.000/”.
>
>
> ==Acknowledgements==
>
> This proposal is based on ideas and concepts derived from the writings
> of Meni Rosenfeld and Gregory Maxwell.
>
>
> ==Copyright==
>
> This work is placed in the public domain.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 6516 bytes --]
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft)
2015-08-22 0:06 ` Ahmed Zsales
@ 2015-08-28 20:28 ` Btc Drak
2015-08-28 21:15 ` Matt Whitlock
2015-08-29 9:38 ` jl2012
0 siblings, 2 replies; 26+ messages in thread
From: Btc Drak @ 2015-08-28 20:28 UTC (permalink / raw)
To: Ahmed Zsales; +Cc: Bitcoin Dev
I have received a lot of feedback on the original gist[1], reddit[2],
ML and IRC and have reworked the text somewhat.
I also request the BIP maintainer for a BIP number assignment
[1] https://gist.github.com/btcdrak/1c3a323100a912b605b5
[2] https://www.reddit.com/r/Bitcoin/comments/3ibia0/bipxx_consensus_based_block_size_retargeting/
Pull request: https://github.com/bitcoin/bips/pull/187
<pre>
BIP: XX
Title: Consensus based block size retargeting algorithm
Author: BtcDrak <btcdrak@gmail•com>
Status: Draft
Type: Standards Track
Created: 2015-08-21
</pre>
==Abstract==
A method of altering the maximum allowed block size of the Bitcoin protocol
using a consensus based approach.
==Motivation==
There is a belief that Bitcoin cannot easily respond to raising the
blocksize limit if popularity was to suddenly increase due to a mass adoption
curve, because co-ordinating a hard fork takes considerable time, and being
unable to respond in a timely manner would irreparably harm the credibility of
bitcoin.
Additionally, predetermined block size increases are problematic because they
attempt to predict the future, and if too large could have unintended
consequences like damaging the possibility for a fee market to develop
as block subsidy decreases substantially over the next 9 years; introducing
or exacerbating mining attack vectors; or somehow affect the network in unknown
or unpredicted ways. Since fixed changes are hard to deploy, the damage could be
extensive.
Dynamic block size adjustments also suffer from the potential to be gamed by the
larger hash power.
Free voting as suggested by BIP100 allows miners to sell their votes out of band
at no risk, and enable the sponsor the ability to manipulate the blocksize.
It also provides a cost free method or the larger pools to vote in ways to
manipulate the blocksize such to disadvantage or attack smaller pools.
==Rationale==
By introducing a cost to increase the block size ensures the mining community
will collude to increase it only when there is a clear necessity, and reduce it
when it is unnecessary. Larger miners cannot force their wishes so easily
because not only will they have to pay extra a difficulty target, then can be
downvoted at no cost by the objecting hash power.
Using difficulty as a penalty is better than a fixed cost in bitcoins because it
is less predictable.
==Specification==
The initial block size limit shall be 1MB.
Each time a miner creates a block, they may vote to increase or decrease the
blocksize by a maximum of 10% of the current block size limit. These votes will
be used to recalculate the new block size limit every 2016 blocks.
Votes are cast using the block's coinbase field.
The first 4 bytes of the coinbase field shall be repurposed for voting as an
unsigned long integer which will be the block size in bytes.
If a miner votes for an increase, the block hash must meet a difficulty target
which is proportionally larger than the standard difficulty target based on the
percentage increase they voted for.
Votes proposing decreasing the block size limit do not need to meet a higher
difficulty target.
Miners can vote for no change by voting for the current block size.
For blocks to be valid the blockhash must meet the required difficulty target
for the vote otherwise the block is invalid and will be rejected.
Every 2016 blocks, the block size limit will be recalculated by the median of
all votes in the last 2016 blocks. This will redefine the block size limit for
the next 2016 blocks.
Blocks that are larger than the calculated base block size limit are invalid and
will be rejected.
The base block size limit may not reduce below 1MB.
==Acknowledgements==
This proposal is based on ideas and concepts derived from the writings of
Meni Rosenfeld and Gregory Maxwell.
==Copyright==
This work is placed in the public domain.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft)
2015-08-28 20:28 ` Btc Drak
@ 2015-08-28 21:15 ` Matt Whitlock
2015-08-28 22:24 ` Gavin
2015-08-28 23:36 ` Btc Drak
2015-08-29 9:38 ` jl2012
1 sibling, 2 replies; 26+ messages in thread
From: Matt Whitlock @ 2015-08-28 21:15 UTC (permalink / raw)
To: bitcoin-dev, Btc Drak
This is the best proposal I've seen yet. Allow me to summarize:
• It addresses the problem, in Jeff Garzik's BIP 100, of miners selling their block-size votes.
• It addresses the problem, in Gavin Andresen's BIP 101, of blindly trying to predict future market needs versus future technological capacities.
• It avoids a large step discontinuity in the block-size limit by starting with a 1-MB limit.
• It throttles changes to ±10% every 2016 blocks.
• It imposes a tangible cost (higher difficulty) on miners who vote to raise the block-size limit.
• It avoids incentivizing miners to vote to lower the block-size limit.
However, this proposal currently fails to answer a very important question:
• What is the mechanism for activation of the new consensus rule? It is when a certain percentage of the blocks mined in a 2016-block retargeting period contain valid block-size votes?
https://github.com/btcdrak/bips/blob/bip-cbbsra/bip-cbbrsa.mediawiki
On Friday, 28 August 2015, at 9:28 pm, Btc Drak via bitcoin-dev wrote:
> Pull request: https://github.com/bitcoin/bips/pull/187
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft)
2015-08-28 21:15 ` Matt Whitlock
@ 2015-08-28 22:24 ` Gavin
2015-08-28 23:35 ` Chris Pacia
2015-08-28 23:38 ` Btc Drak
2015-08-28 23:36 ` Btc Drak
1 sibling, 2 replies; 26+ messages in thread
From: Gavin @ 2015-08-28 22:24 UTC (permalink / raw)
To: Matt Whitlock; +Cc: bitcoin-dev
With this proposal, how much would it cost a miner to include an 'extra' 500-byte transaction if the average block size is 900K and it costs the miner 20BTC in electricity/capital/etc to mine a block?
If my understanding of the proposal is correct, it is:
500/900000 * 20 = 0.11111 BTC
... Or $2.50 at today's exchange rate.
That seems excessive.
--
Gavin Andresen
> On Aug 28, 2015, at 5:15 PM, Matt Whitlock via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> wrote:
>
> This is the best proposal I've seen yet. Allow me to summarize:
>
> • It addresses the problem, in Jeff Garzik's BIP 100, of miners selling their block-size votes.
> • It addresses the problem, in Gavin Andresen's BIP 101, of blindly trying to predict future market needs versus future technological capacities.
> • It avoids a large step discontinuity in the block-size limit by starting with a 1-MB limit.
> • It throttles changes to ±10% every 2016 blocks.
> • It imposes a tangible cost (higher difficulty) on miners who vote to raise the block-size limit.
> • It avoids incentivizing miners to vote to lower the block-size limit.
>
> However, this proposal currently fails to answer a very important question:
>
> • What is the mechanism for activation of the new consensus rule? It is when a certain percentage of the blocks mined in a 2016-block retargeting period contain valid block-size votes?
>
>
> https://github.com/btcdrak/bips/blob/bip-cbbsra/bip-cbbrsa.mediawiki
>
>
>> On Friday, 28 August 2015, at 9:28 pm, Btc Drak via bitcoin-dev wrote:
>> Pull request: https://github.com/bitcoin/bips/pull/187
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft)
2015-08-28 22:24 ` Gavin
@ 2015-08-28 23:35 ` Chris Pacia
2015-08-28 23:38 ` Mark Friedenbach
2015-08-28 23:46 ` Btc Drak
2015-08-28 23:38 ` Btc Drak
1 sibling, 2 replies; 26+ messages in thread
From: Chris Pacia @ 2015-08-28 23:35 UTC (permalink / raw)
To: Gavin; +Cc: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 2644 bytes --]
When discussing this with Matt Whitlock earlier we basically concluded the
block size will never increase under this proposal do to a collective
action problem. If a miner votes for an increase and nobody else does, the
blocksize will not increase yet he will still have to pay the difficulty
penalty.
It may be in everyone's collective interest to raise the block size but not
their individual interest.
On Aug 28, 2015 6:24 PM, "Gavin via bitcoin-dev" <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> With this proposal, how much would it cost a miner to include an 'extra'
> 500-byte transaction if the average block size is 900K and it costs the
> miner 20BTC in electricity/capital/etc to mine a block?
>
> If my understanding of the proposal is correct, it is:
>
> 500/900000 * 20 = 0.11111 BTC
>
> ... Or $2.50 at today's exchange rate.
>
> That seems excessive.
>
> --
> Gavin Andresen
>
>
> > On Aug 28, 2015, at 5:15 PM, Matt Whitlock via bitcoin-dev <
> bitcoin-dev@lists•linuxfoundation.org> wrote:
> >
> > This is the best proposal I've seen yet. Allow me to summarize:
> >
> > • It addresses the problem, in Jeff Garzik's BIP 100, of miners selling
> their block-size votes.
> > • It addresses the problem, in Gavin Andresen's BIP 101, of blindly
> trying to predict future market needs versus future technological
> capacities.
> > • It avoids a large step discontinuity in the block-size limit by
> starting with a 1-MB limit.
> > • It throttles changes to ±10% every 2016 blocks.
> > • It imposes a tangible cost (higher difficulty) on miners who vote to
> raise the block-size limit.
> > • It avoids incentivizing miners to vote to lower the block-size limit.
> >
> > However, this proposal currently fails to answer a very important
> question:
> >
> > • What is the mechanism for activation of the new consensus rule? It is
> when a certain percentage of the blocks mined in a 2016-block retargeting
> period contain valid block-size votes?
> >
> >
> > https://github.com/btcdrak/bips/blob/bip-cbbsra/bip-cbbrsa.mediawiki
> >
> >
> >> On Friday, 28 August 2015, at 9:28 pm, Btc Drak via bitcoin-dev wrote:
> >> Pull request: https://github.com/bitcoin/bips/pull/187
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists•linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 3683 bytes --]
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft)
2015-08-28 21:15 ` Matt Whitlock
2015-08-28 22:24 ` Gavin
@ 2015-08-28 23:36 ` Btc Drak
2015-08-28 23:44 ` Jorge Timón
1 sibling, 1 reply; 26+ messages in thread
From: Btc Drak @ 2015-08-28 23:36 UTC (permalink / raw)
To: Matt Whitlock; +Cc: Bitcoin Dev
On Fri, Aug 28, 2015 at 10:15 PM, Matt Whitlock <bip@mattwhitlock•name> wrote:
> However, this proposal currently fails to answer a very important question:
>
> • What is the mechanism for activation of the new consensus rule? It is when a certain percentage of the blocks mined in a 2016-block retargeting period contain valid block-size votes?
I chose not to address hard fork methodology at this stage because I
wanted to focus on the main algorithm. There are a number of options
open to us for deployment including a simple fixed activation (which I
think is feasible because there is a a lot of awareness and the
industry shows they are willing to rally around a single proposal). If
there are any strong preferences, I can add a deployment section
although I think it's less interesting until we forge a clear way
forward with what blocksize proposal to use.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft)
2015-08-28 23:35 ` Chris Pacia
@ 2015-08-28 23:38 ` Mark Friedenbach
2015-08-28 23:42 ` Matt Whitlock
` (2 more replies)
2015-08-28 23:46 ` Btc Drak
1 sibling, 3 replies; 26+ messages in thread
From: Mark Friedenbach @ 2015-08-28 23:38 UTC (permalink / raw)
To: Chris Pacia; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 3129 bytes --]
It is in their individual interests when the larger block that is allowed
for them grants them more fees.
On Aug 28, 2015 4:35 PM, "Chris Pacia via bitcoin-dev" <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> When discussing this with Matt Whitlock earlier we basically concluded the
> block size will never increase under this proposal do to a collective
> action problem. If a miner votes for an increase and nobody else does, the
> blocksize will not increase yet he will still have to pay the difficulty
> penalty.
>
> It may be in everyone's collective interest to raise the block size but
> not their individual interest.
> On Aug 28, 2015 6:24 PM, "Gavin via bitcoin-dev" <
> bitcoin-dev@lists•linuxfoundation.org> wrote:
>
>> With this proposal, how much would it cost a miner to include an 'extra'
>> 500-byte transaction if the average block size is 900K and it costs the
>> miner 20BTC in electricity/capital/etc to mine a block?
>>
>> If my understanding of the proposal is correct, it is:
>>
>> 500/900000 * 20 = 0.11111 BTC
>>
>> ... Or $2.50 at today's exchange rate.
>>
>> That seems excessive.
>>
>> --
>> Gavin Andresen
>>
>>
>> > On Aug 28, 2015, at 5:15 PM, Matt Whitlock via bitcoin-dev <
>> bitcoin-dev@lists•linuxfoundation.org> wrote:
>> >
>> > This is the best proposal I've seen yet. Allow me to summarize:
>> >
>> > • It addresses the problem, in Jeff Garzik's BIP 100, of miners selling
>> their block-size votes.
>> > • It addresses the problem, in Gavin Andresen's BIP 101, of blindly
>> trying to predict future market needs versus future technological
>> capacities.
>> > • It avoids a large step discontinuity in the block-size limit by
>> starting with a 1-MB limit.
>> > • It throttles changes to ±10% every 2016 blocks.
>> > • It imposes a tangible cost (higher difficulty) on miners who vote to
>> raise the block-size limit.
>> > • It avoids incentivizing miners to vote to lower the block-size limit.
>> >
>> > However, this proposal currently fails to answer a very important
>> question:
>> >
>> > • What is the mechanism for activation of the new consensus rule? It is
>> when a certain percentage of the blocks mined in a 2016-block retargeting
>> period contain valid block-size votes?
>> >
>> >
>> > https://github.com/btcdrak/bips/blob/bip-cbbsra/bip-cbbrsa.mediawiki
>> >
>> >
>> >> On Friday, 28 August 2015, at 9:28 pm, Btc Drak via bitcoin-dev wrote:
>> >> Pull request: https://github.com/bitcoin/bips/pull/187
>> > _______________________________________________
>> > bitcoin-dev mailing list
>> > bitcoin-dev@lists•linuxfoundation.org
>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
[-- Attachment #2: Type: text/html, Size: 4589 bytes --]
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft)
2015-08-28 22:24 ` Gavin
2015-08-28 23:35 ` Chris Pacia
@ 2015-08-28 23:38 ` Btc Drak
1 sibling, 0 replies; 26+ messages in thread
From: Btc Drak @ 2015-08-28 23:38 UTC (permalink / raw)
To: Gavin; +Cc: bitcoin-dev
On Fri, Aug 28, 2015 at 11:24 PM, Gavin <gavinandresen@gmail•com> wrote:
> With this proposal, how much would it cost a miner to include an 'extra' 500-byte transaction if the average block size is 900K and it costs the miner 20BTC in electricity/capital/etc to mine a block?
>
> If my understanding of the proposal is correct, it is:
>
> 500/900000 * 20 = 0.11111 BTC
Typo, 0.01111
> ... Or $2.50 at today's exchange rate.
>
> That seems excessive.
I am not sure how it is relevant to this proposal because miners are
not paying to include an extra transaction. The BIP details how miners
can vote for a larger block size limit during a window of 2016 blocks.
The block size limit does not increase during this phase. The block
size limit is adjusted at the end of the sample window and the new
size is valid until the next retargetting.
If this wasn't clear, please let me know if I need to clarify any
specifics in the wording of the proposal.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft)
2015-08-28 23:38 ` Mark Friedenbach
@ 2015-08-28 23:42 ` Matt Whitlock
2015-08-28 23:42 ` Chris Pacia
2015-08-29 0:00 ` Jorge Timón
2 siblings, 0 replies; 26+ messages in thread
From: Matt Whitlock @ 2015-08-28 23:42 UTC (permalink / raw)
To: bitcoin-dev, Mark Friedenbach, Chris Pacia
But that's not what this proposal does. They have to pay the difficulty penalty merely for a *chance* at later being able to mine larger blocks.
Maybe this could be fixed by allowing miners to produce a larger-than-limit block *immediately* by paying a difficulty penalty. Then we can simply take the 80th-percentile block size in each 2016-block period as the nominal block-size limit in the next period.
On Friday, 28 August 2015, at 4:38 pm, Mark Friedenbach via bitcoin-dev wrote:
> It is in their individual interests when the larger block that is allowed
> for them grants them more fees.
>
> On Aug 28, 2015 4:35 PM, "Chris Pacia via bitcoin-dev" <
> bitcoin-dev@lists•linuxfoundation.org> wrote:
>
> > When discussing this with Matt Whitlock earlier we basically concluded the
> > block size will never increase under this proposal do to a collective
> > action problem. If a miner votes for an increase and nobody else does, the
> > blocksize will not increase yet he will still have to pay the difficulty
> > penalty.
> >
> > It may be in everyone's collective interest to raise the block size but
> > not their individual interest.
> > On Aug 28, 2015 6:24 PM, "Gavin via bitcoin-dev" <
> > bitcoin-dev@lists•linuxfoundation.org> wrote:
> >
> >> With this proposal, how much would it cost a miner to include an 'extra'
> >> 500-byte transaction if the average block size is 900K and it costs the
> >> miner 20BTC in electricity/capital/etc to mine a block?
> >>
> >> If my understanding of the proposal is correct, it is:
> >>
> >> 500/900000 * 20 = 0.11111 BTC
> >>
> >> ... Or $2.50 at today's exchange rate.
> >>
> >> That seems excessive.
> >>
> >> --
> >> Gavin Andresen
> >>
> >>
> >> > On Aug 28, 2015, at 5:15 PM, Matt Whitlock via bitcoin-dev <
> >> bitcoin-dev@lists•linuxfoundation.org> wrote:
> >> >
> >> > This is the best proposal I've seen yet. Allow me to summarize:
> >> >
> >> > • It addresses the problem, in Jeff Garzik's BIP 100, of miners selling
> >> their block-size votes.
> >> > • It addresses the problem, in Gavin Andresen's BIP 101, of blindly
> >> trying to predict future market needs versus future technological
> >> capacities.
> >> > • It avoids a large step discontinuity in the block-size limit by
> >> starting with a 1-MB limit.
> >> > • It throttles changes to ±10% every 2016 blocks.
> >> > • It imposes a tangible cost (higher difficulty) on miners who vote to
> >> raise the block-size limit.
> >> > • It avoids incentivizing miners to vote to lower the block-size limit.
> >> >
> >> > However, this proposal currently fails to answer a very important
> >> question:
> >> >
> >> > • What is the mechanism for activation of the new consensus rule? It is
> >> when a certain percentage of the blocks mined in a 2016-block retargeting
> >> period contain valid block-size votes?
> >> >
> >> >
> >> > https://github.com/btcdrak/bips/blob/bip-cbbsra/bip-cbbrsa.mediawiki
> >> >
> >> >
> >> >> On Friday, 28 August 2015, at 9:28 pm, Btc Drak via bitcoin-dev wrote:
> >> >> Pull request: https://github.com/bitcoin/bips/pull/187
> >> > _______________________________________________
> >> > bitcoin-dev mailing list
> >> > bitcoin-dev@lists•linuxfoundation.org
> >> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >> _______________________________________________
> >> bitcoin-dev mailing list
> >> bitcoin-dev@lists•linuxfoundation.org
> >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >>
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists•linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> >
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft)
2015-08-28 23:38 ` Mark Friedenbach
2015-08-28 23:42 ` Matt Whitlock
@ 2015-08-28 23:42 ` Chris Pacia
2015-08-29 0:00 ` Jorge Timón
2 siblings, 0 replies; 26+ messages in thread
From: Chris Pacia @ 2015-08-28 23:42 UTC (permalink / raw)
To: Mark Friedenbach; +Cc: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 3561 bytes --]
On Aug 28, 2015 7:38 PM, "Mark Friedenbach" <mark@friedenbach•org> wrote:
>
> It is in their individual interests when the larger block that is allowed
for them grants them more fees.
And pay a difficulty penalty and lose full blocks because of it? Even if
fees are somehow high enough to compensate for the lost reward, it still
requires miners to collectively decide to raise the block size for it to
make sense individually. An individual vote will not raise the limit, but
it will cost the miner money.
>
> On Aug 28, 2015 4:35 PM, "Chris Pacia via bitcoin-dev" <
bitcoin-dev@lists•linuxfoundation.org> wrote:
>>
>> When discussing this with Matt Whitlock earlier we basically concluded
the block size will never increase under this proposal do to a collective
action problem. If a miner votes for an increase and nobody else does, the
blocksize will not increase yet he will still have to pay the difficulty
penalty.
>>
>> It may be in everyone's collective interest to raise the block size but
not their individual interest.
>>
>> On Aug 28, 2015 6:24 PM, "Gavin via bitcoin-dev" <
bitcoin-dev@lists•linuxfoundation.org> wrote:
>>>
>>> With this proposal, how much would it cost a miner to include an
'extra' 500-byte transaction if the average block size is 900K and it costs
the miner 20BTC in electricity/capital/etc to mine a block?
>>>
>>> If my understanding of the proposal is correct, it is:
>>>
>>> 500/900000 * 20 = 0.11111 BTC
>>>
>>> ... Or $2.50 at today's exchange rate.
>>>
>>> That seems excessive.
>>>
>>> --
>>> Gavin Andresen
>>>
>>>
>>> > On Aug 28, 2015, at 5:15 PM, Matt Whitlock via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
>>> >
>>> > This is the best proposal I've seen yet. Allow me to summarize:
>>> >
>>> > • It addresses the problem, in Jeff Garzik's BIP 100, of miners
selling their block-size votes.
>>> > • It addresses the problem, in Gavin Andresen's BIP 101, of blindly
trying to predict future market needs versus future technological
capacities.
>>> > • It avoids a large step discontinuity in the block-size limit by
starting with a 1-MB limit.
>>> > • It throttles changes to ±10% every 2016 blocks.
>>> > • It imposes a tangible cost (higher difficulty) on miners who vote
to raise the block-size limit.
>>> > • It avoids incentivizing miners to vote to lower the block-size
limit.
>>> >
>>> > However, this proposal currently fails to answer a very important
question:
>>> >
>>> > • What is the mechanism for activation of the new consensus rule? It
is when a certain percentage of the blocks mined in a 2016-block
retargeting period contain valid block-size votes?
>>> >
>>> >
>>> > https://github.com/btcdrak/bips/blob/bip-cbbsra/bip-cbbrsa.mediawiki
>>> >
>>> >
>>> >> On Friday, 28 August 2015, at 9:28 pm, Btc Drak via bitcoin-dev
wrote:
>>> >> Pull request: https://github.com/bitcoin/bips/pull/187
>>> > _______________________________________________
>>> > bitcoin-dev mailing list
>>> > bitcoin-dev@lists•linuxfoundation.org
>>> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists•linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists•linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
[-- Attachment #2: Type: text/html, Size: 5246 bytes --]
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft)
2015-08-28 23:36 ` Btc Drak
@ 2015-08-28 23:44 ` Jorge Timón
0 siblings, 0 replies; 26+ messages in thread
From: Jorge Timón @ 2015-08-28 23:44 UTC (permalink / raw)
To: Btc Drak; +Cc: Bitcoin Dev
On Sat, Aug 29, 2015 at 1:36 AM, Btc Drak via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> On Fri, Aug 28, 2015 at 10:15 PM, Matt Whitlock <bip@mattwhitlock•name> wrote:
>> However, this proposal currently fails to answer a very important question:
>>
>> • What is the mechanism for activation of the new consensus rule? It is when a certain percentage of the blocks mined in a 2016-block retargeting period contain valid block-size votes?
>
> I chose not to address hard fork methodology at this stage because I
> wanted to focus on the main algorithm. There are a number of options
> open to us for deployment including a simple fixed activation (which I
> think is feasible because there is a a lot of awareness and the
> industry shows they are willing to rally around a single proposal). If
> there are any strong preferences, I can add a deployment section
> although I think it's less interesting until we forge a clear way
> forward with what blocksize proposal to use.
Can we please not discuss an ideal deployment mechanism in 4+
different proposals and discuss the same deployment mechanism (for all
proposals) in BIP99's thread instead?
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft)
2015-08-28 23:35 ` Chris Pacia
2015-08-28 23:38 ` Mark Friedenbach
@ 2015-08-28 23:46 ` Btc Drak
2015-08-29 9:15 ` Elliot Olds
1 sibling, 1 reply; 26+ messages in thread
From: Btc Drak @ 2015-08-28 23:46 UTC (permalink / raw)
To: Chris Pacia; +Cc: Bitcoin Dev
On Sat, Aug 29, 2015 at 12:35 AM, Chris Pacia via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> When discussing this with Matt Whitlock earlier we basically concluded the
> block size will never increase under this proposal do to a collective action
> problem. If a miner votes for an increase and nobody else does, the
> blocksize will not increase yet he will still have to pay the difficulty
> penalty.
>
> It may be in everyone's collective interest to raise the block size but not
> their individual interest.
It is clear from recent events that miners are willing to collaborate
together for the greater good of their industry. Miners have also
publicly shown support for raising the blocksize collaboratively.
Obviously, as transaction volume grows they want to collect as many
transaction fees as possible so if there isnt enough space in blocks,
they're going to vote for increases because it's in their collective
financial interests. The proposal specifically encourages
collaboration and hinders antisocial behaviour, and it specifically
encourages the blocksize to be raised according to demand without
neutering the fee market.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft)
2015-08-28 23:38 ` Mark Friedenbach
2015-08-28 23:42 ` Matt Whitlock
2015-08-28 23:42 ` Chris Pacia
@ 2015-08-29 0:00 ` Jorge Timón
2015-08-29 0:29 ` Mark Friedenbach
2 siblings, 1 reply; 26+ messages in thread
From: Jorge Timón @ 2015-08-29 0:00 UTC (permalink / raw)
To: Mark Friedenbach, Jeff Garzik; +Cc: Bitcoin Dev
On Sat, Aug 29, 2015 at 1:38 AM, Mark Friedenbach via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> It is in their individual interests when the larger block that is allowed
> for them grants them more fees.
I realize now that this is not what Greg Maxwell proposed (aka
flexcap): this is just miner's voting on block size but paying with
higher difficulty when they vote for bigger blocks.
As I said several times in other places, miners should not decide on
the consensus rule to limit mining centralization.
People keep talking about miners voting on the block size or
"softforking the size down if we went too far". But what if the
hashing majority is perfectly fine with the mining centralization at
that point in time?
Then a softfork won't be useful and we're talking about an "anti-miner
fork" (see https://github.com/bitcoin/bips/pull/181/files#diff-e331b8631759a4ed6a4cfb4d10f473caR158
and https://github.com/bitcoin/bips/pull/181/files#diff-e331b8631759a4ed6a4cfb4d10f473caR175
).
I believe miner's voting on the rule to limit mining centralization is
a terrible idea.
It sounds as bad as letting pharma companies write the regulations on
new drugs safety, letting big food chains deciding on minimum food
controls or car manufacturers deciding on indirect taxes for fuel.
That's why I dislike both this proposal and BIP100.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft)
2015-08-29 0:00 ` Jorge Timón
@ 2015-08-29 0:29 ` Mark Friedenbach
2015-08-29 10:15 ` Btc Drak
0 siblings, 1 reply; 26+ messages in thread
From: Mark Friedenbach @ 2015-08-29 0:29 UTC (permalink / raw)
To: Jorge Timón; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 2022 bytes --]
Ah, then my mistake. It seemed so similar to an idea that was proposed
before on this mailing list:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008033.html
that my mind just filled in the gaps. I concur -- having miners -- or any
group -- vote on block size is not an intrinsically good thing. The the
original proposal due to Greg Maxwell et al was not a mechanism for
"voting" but rather a feedback control that made the maximum block size
that which generated the most fees.
On Fri, Aug 28, 2015 at 5:00 PM, Jorge Timón <jtimon@jtimon•cc> wrote:
> On Sat, Aug 29, 2015 at 1:38 AM, Mark Friedenbach via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation.org> wrote:
> > It is in their individual interests when the larger block that is allowed
> > for them grants them more fees.
>
> I realize now that this is not what Greg Maxwell proposed (aka
> flexcap): this is just miner's voting on block size but paying with
> higher difficulty when they vote for bigger blocks.
> As I said several times in other places, miners should not decide on
> the consensus rule to limit mining centralization.
> People keep talking about miners voting on the block size or
> "softforking the size down if we went too far". But what if the
> hashing majority is perfectly fine with the mining centralization at
> that point in time?
> Then a softfork won't be useful and we're talking about an "anti-miner
> fork" (see
> https://github.com/bitcoin/bips/pull/181/files#diff-e331b8631759a4ed6a4cfb4d10f473caR158
> and
> https://github.com/bitcoin/bips/pull/181/files#diff-e331b8631759a4ed6a4cfb4d10f473caR175
> ).
>
> I believe miner's voting on the rule to limit mining centralization is
> a terrible idea.
> It sounds as bad as letting pharma companies write the regulations on
> new drugs safety, letting big food chains deciding on minimum food
> controls or car manufacturers deciding on indirect taxes for fuel.
> That's why I dislike both this proposal and BIP100.
>
[-- Attachment #2: Type: text/html, Size: 2877 bytes --]
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft)
2015-08-28 23:46 ` Btc Drak
@ 2015-08-29 9:15 ` Elliot Olds
0 siblings, 0 replies; 26+ messages in thread
From: Elliot Olds @ 2015-08-29 9:15 UTC (permalink / raw)
To: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 1517 bytes --]
On Fri, Aug 28, 2015 at 4:46 PM, Btc Drak via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> On Sat, Aug 29, 2015 at 12:35 AM, Chris Pacia via bitcoin-dev
> > It may be in everyone's collective interest to raise the block size but
> not
> > their individual interest.
>
> It is clear from recent events that miners are willing to collaborate
> together for the greater good of their industry. Miners have also
> publicly shown support for raising the blocksize collaboratively.
>
When have miners shown a willingness to make sacrifices for miners as a
whole when they've been in a "public good"[1] situation? Miners
collaborating to release statements to the public about which BIPs they
support is very different from miners incurring costs only to themselves in
order to help the entire group. They might do so, but it isn't clear.
I agree with Jorge and Mark that allowing miners to vote on the block size
is not ideal. Miners interests are somewhat aligned with those of the
broader community, but not perfectly aligned. The block size level that
maximizes miner revenue is not necessarily desirable overall. More miner
revenue is only good if the marginal extra security that it buys is worth
the extra cost. In addition to the cost of higher user fees, there's
another hidden cost. In Bitcoin's early stages trying to maximize revenue
too soon can slow growth and result in less revenue when it's more needed
(when block rewards are much lower).
[1] https://en.wikipedia.org/wiki/Public_good
[-- Attachment #2: Type: text/html, Size: 2092 bytes --]
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft)
2015-08-28 20:28 ` Btc Drak
2015-08-28 21:15 ` Matt Whitlock
@ 2015-08-29 9:38 ` jl2012
1 sibling, 0 replies; 26+ messages in thread
From: jl2012 @ 2015-08-29 9:38 UTC (permalink / raw)
To: Btc Drak; +Cc: Bitcoin Dev
We need some game theory experts to analyse this but I see there are 3
major problems:
1. Tragedy of the commons: Some miners have to scarify their income to
increase the block size, and all miners will share the beneficial
outcome of the increase. All miners would like to be free riders.
2. Promote the formation of mining cartel: miners have to make sure that
their vote for increase is supported by at least 50% of miners, or they
will lose income for nothing. A miner also needs to make sure that he is
not voting "excessively" (in terms of size and vote count), as the
excessive part will never be counted due to the use of median. So
basically you will either have exactly 1009 miners voting for the same
size increase in a cycle, or have no vote for increase at all. That will
require a lot of offline negotiations. Such cartel may work ONLY if
mining is highly centralized, and miners trust each other. Also, there
is no mechanism to punish those who betray the cartel.
3. Imbalance of power: it is costly to increase the size, while totally
free to decrease the size
Btc Drak via bitcoin-dev 於 2015-08-28 16:28 寫到:
> I have received a lot of feedback on the original gist[1], reddit[2],
> ML and IRC and have reworked the text somewhat.
>
> I also request the BIP maintainer for a BIP number assignment
>
> [1] https://gist.github.com/btcdrak/1c3a323100a912b605b5
> [2]
> https://www.reddit.com/r/Bitcoin/comments/3ibia0/bipxx_consensus_based_block_size_retargeting/
>
> Pull request: https://github.com/bitcoin/bips/pull/187
>
> <pre>
> BIP: XX
> Title: Consensus based block size retargeting algorithm
> Author: BtcDrak <btcdrak@gmail•com>
> Status: Draft
> Type: Standards Track
> Created: 2015-08-21
> </pre>
>
> ==Abstract==
>
> A method of altering the maximum allowed block size of the Bitcoin
> protocol
> using a consensus based approach.
>
> ==Motivation==
>
> There is a belief that Bitcoin cannot easily respond to raising the
> blocksize limit if popularity was to suddenly increase due to a mass
> adoption
> curve, because co-ordinating a hard fork takes considerable time, and
> being
> unable to respond in a timely manner would irreparably harm the
> credibility of
> bitcoin.
>
> Additionally, predetermined block size increases are problematic
> because they
> attempt to predict the future, and if too large could have unintended
> consequences like damaging the possibility for a fee market to develop
> as block subsidy decreases substantially over the next 9 years;
> introducing
> or exacerbating mining attack vectors; or somehow affect the network in
> unknown
> or unpredicted ways. Since fixed changes are hard to deploy, the damage
> could be
> extensive.
>
> Dynamic block size adjustments also suffer from the potential to be
> gamed by the
> larger hash power.
>
> Free voting as suggested by BIP100 allows miners to sell their votes
> out of band
> at no risk, and enable the sponsor the ability to manipulate the
> blocksize.
> It also provides a cost free method or the larger pools to vote in ways
> to
> manipulate the blocksize such to disadvantage or attack smaller pools.
>
>
> ==Rationale==
>
> By introducing a cost to increase the block size ensures the mining
> community
> will collude to increase it only when there is a clear necessity, and
> reduce it
> when it is unnecessary. Larger miners cannot force their wishes so
> easily
> because not only will they have to pay extra a difficulty target, then
> can be
> downvoted at no cost by the objecting hash power.
>
> Using difficulty as a penalty is better than a fixed cost in bitcoins
> because it
> is less predictable.
>
>
> ==Specification==
>
> The initial block size limit shall be 1MB.
>
> Each time a miner creates a block, they may vote to increase or
> decrease the
> blocksize by a maximum of 10% of the current block size limit. These
> votes will
> be used to recalculate the new block size limit every 2016 blocks.
>
> Votes are cast using the block's coinbase field.
>
> The first 4 bytes of the coinbase field shall be repurposed for voting
> as an
> unsigned long integer which will be the block size in bytes.
>
> If a miner votes for an increase, the block hash must meet a difficulty
> target
> which is proportionally larger than the standard difficulty target
> based on the
> percentage increase they voted for.
>
> Votes proposing decreasing the block size limit do not need to meet a
> higher
> difficulty target.
>
> Miners can vote for no change by voting for the current block size.
>
> For blocks to be valid the blockhash must meet the required difficulty
> target
> for the vote otherwise the block is invalid and will be rejected.
>
> Every 2016 blocks, the block size limit will be recalculated by the
> median of
> all votes in the last 2016 blocks. This will redefine the block size
> limit for
> the next 2016 blocks.
>
> Blocks that are larger than the calculated base block size limit are
> invalid and
> will be rejected.
>
> The base block size limit may not reduce below 1MB.
>
>
> ==Acknowledgements==
>
> This proposal is based on ideas and concepts derived from the writings
> of
> Meni Rosenfeld and Gregory Maxwell.
>
>
> ==Copyright==
>
> This work is placed in the public domain.
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft)
2015-08-29 0:29 ` Mark Friedenbach
@ 2015-08-29 10:15 ` Btc Drak
2015-08-29 17:51 ` Eric Lombrozo
` (2 more replies)
0 siblings, 3 replies; 26+ messages in thread
From: Btc Drak @ 2015-08-29 10:15 UTC (permalink / raw)
To: Mark Friedenbach; +Cc: Bitcoin Dev
On Sat, Aug 29, 2015 at 1:29 AM, Mark Friedenbach via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:
> Ah, then my mistake. It seemed so similar to an idea that was proposed
> before on this mailing list:
>
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008033.html
>
> that my mind just filled in the gaps. I concur -- having miners -- or any
> group -- vote on block size is not an intrinsically good thing. The the
> original proposal due to Greg Maxwell et al was not a mechanism for "voting"
> but rather a feedback control that made the maximum block size that which
> generated the most fees.
Mark and Jorge,
I am very glad you have brought up this particular objection because
it's something I thought about but was unclear if it was an opinion
that would be shared by others. I chose to omit it from the proposal
to see if it would come up during peer review.
I feel that giving miners a blank cheque to increase blocksize, by any
means, goes against a key design of bitcoin's security model. Full
nodes keep miners honest by ensuring by validating their blocks. Under
any voting-only scheme there is no way for full nodes to keep miners
in cheque because miner have free reign to increase the blocksize.
This problem can be solved by introducing a hard cap on blocksize. By
introducing an upper limit miners now have the freedom to increase
blocksize but only within defined parameters. Remember my proposal
allows blocksize to increase and decrease in such a way that miners
must collectively agree if they want the size to increase.
I believe the idea of a hard upper limit has become rather politicised
but is essential to the security model of bitcoin.
With respect to the flexicap idea where miners can create a larger
block by paying extra difficulty, I believe that proposal has a
critical flaw because, as Gavin pointed out, it makes it very
expensive (and risky) to include a few extra transactions. I believe
it suffers from tragedy of the commons because there is no incentive
for the mining community to reach consensus. Each and every block is
going to be a gamble, "should we include a few extra transactions at
the risk of losing the block?". Under my proposal miners can
collectively agree to change the blocksize. Let's say they want a 10%
increase, they can collude together to make that increase and once
reached, it remains until they want to change it again. Yet, the upper
hard limit keeps the ultimate control of the maximum block size
squarely in the hands of full nodes.
Whilst the exact number may be up for discussion, I would propose an
initial upper limit of 8MB, so under my proposal the blocksize would
be flexible between 1MB and 8MB.
An alternative methodology to voting in the coinbase would be to
change the vote to be the blocksize itself
1. miners pay extra difficulty to create a larger block.
2. every 2016 blocks the average or median of the last 2016 blocks is
calculated and becomes the new maximum blocksize limit.
This would retain incentive to collude to increase blocksize, as well
as the property of costing to increase while being free to propose
decrease.
It would still require an upper blocksize limit in order for full
nodes to retain control. Without an upper limit, any proposal is going
to break the security model as full nodes give up some oversight
control over miners.
Another way of looking at these ideas is we're raising blocksize hard
limit (to 8MB or whatever is decided), but making a soft of "softer"
or inner limit part of consensus. Such a concept is not really
departing from the current idea of a soft limit except to make it
consensus enforced. Obviously it's not identical, but I think you can
see the similarities.
Does that make sense?
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft)
2015-08-29 10:15 ` Btc Drak
@ 2015-08-29 17:51 ` Eric Lombrozo
2015-08-29 19:13 ` Natanael
2015-08-29 19:03 ` jl2012
2015-08-29 20:41 ` Jorge Timón
2 siblings, 1 reply; 26+ messages in thread
From: Eric Lombrozo @ 2015-08-29 17:51 UTC (permalink / raw)
To: Btc Drak, Mark Friedenbach; +Cc: Bitcoin Dev
[-- Attachment #1: Type: text/plain, Size: 4745 bytes --]
In principle I am sympathetic to dynamic block size proposals...but in
practice it seems we're barking up the wrong tree. Without mechanisms for
incentivizing validators...and checks and balances between the interests of
regular users (who want to reduce fees and confirmation time), miners (who
want to balance hashing and propagation time costs with revenue), and
validator nodes (who currrently lack any direct incentives), I think we're
talking about significant protocol complications with potential benefits
that are hard to model at best.
On Sat, Aug 29, 2015, 3:16 AM Btc Drak via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> On Sat, Aug 29, 2015 at 1:29 AM, Mark Friedenbach via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation.org> wrote:
> > Ah, then my mistake. It seemed so similar to an idea that was proposed
> > before on this mailing list:
> >
> >
> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008033.html
> >
> > that my mind just filled in the gaps. I concur -- having miners -- or any
> > group -- vote on block size is not an intrinsically good thing. The the
> > original proposal due to Greg Maxwell et al was not a mechanism for
> "voting"
> > but rather a feedback control that made the maximum block size that which
> > generated the most fees.
>
> Mark and Jorge,
>
> I am very glad you have brought up this particular objection because
> it's something I thought about but was unclear if it was an opinion
> that would be shared by others. I chose to omit it from the proposal
> to see if it would come up during peer review.
>
> I feel that giving miners a blank cheque to increase blocksize, by any
> means, goes against a key design of bitcoin's security model. Full
> nodes keep miners honest by ensuring by validating their blocks. Under
> any voting-only scheme there is no way for full nodes to keep miners
> in cheque because miner have free reign to increase the blocksize.
>
> This problem can be solved by introducing a hard cap on blocksize. By
> introducing an upper limit miners now have the freedom to increase
> blocksize but only within defined parameters. Remember my proposal
> allows blocksize to increase and decrease in such a way that miners
> must collectively agree if they want the size to increase.
>
> I believe the idea of a hard upper limit has become rather politicised
> but is essential to the security model of bitcoin.
>
> With respect to the flexicap idea where miners can create a larger
> block by paying extra difficulty, I believe that proposal has a
> critical flaw because, as Gavin pointed out, it makes it very
> expensive (and risky) to include a few extra transactions. I believe
> it suffers from tragedy of the commons because there is no incentive
> for the mining community to reach consensus. Each and every block is
> going to be a gamble, "should we include a few extra transactions at
> the risk of losing the block?". Under my proposal miners can
> collectively agree to change the blocksize. Let's say they want a 10%
> increase, they can collude together to make that increase and once
> reached, it remains until they want to change it again. Yet, the upper
> hard limit keeps the ultimate control of the maximum block size
> squarely in the hands of full nodes.
>
> Whilst the exact number may be up for discussion, I would propose an
> initial upper limit of 8MB, so under my proposal the blocksize would
> be flexible between 1MB and 8MB.
>
> An alternative methodology to voting in the coinbase would be to
> change the vote to be the blocksize itself
>
> 1. miners pay extra difficulty to create a larger block.
> 2. every 2016 blocks the average or median of the last 2016 blocks is
> calculated and becomes the new maximum blocksize limit.
>
> This would retain incentive to collude to increase blocksize, as well
> as the property of costing to increase while being free to propose
> decrease.
>
> It would still require an upper blocksize limit in order for full
> nodes to retain control. Without an upper limit, any proposal is going
> to break the security model as full nodes give up some oversight
> control over miners.
>
> Another way of looking at these ideas is we're raising blocksize hard
> limit (to 8MB or whatever is decided), but making a soft of "softer"
> or inner limit part of consensus. Such a concept is not really
> departing from the current idea of a soft limit except to make it
> consensus enforced. Obviously it's not identical, but I think you can
> see the similarities.
>
> Does that make sense?
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
[-- Attachment #2: Type: text/html, Size: 5730 bytes --]
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft)
2015-08-29 10:15 ` Btc Drak
2015-08-29 17:51 ` Eric Lombrozo
@ 2015-08-29 19:03 ` jl2012
2015-08-29 20:41 ` Jorge Timón
2 siblings, 0 replies; 26+ messages in thread
From: jl2012 @ 2015-08-29 19:03 UTC (permalink / raw)
To: Btc Drak; +Cc: Bitcoin Dev
I am quite skeptical about any pay-to-increase proposal because it is
difficult to predict the game dynamics and determine the right amount of
penalty. But anyway, here is my response to your revised proposal:
1. I agree with you that there should be a cap in the rate of change,
and also the maximum possible size. This is already part of BIP100
2. Requiring a higher difficulty is bad for everyone:
a) it increases the variance of the miner;
b) average confirmation time for all tx are increased. It may even
cause a feedback: many tx in mempool -> increase block size -> wait
longer for confirmation -> more tx in mempool;
c) difficulty of the next round will be decreased, leading to a greater
fluctuation in confirmation time.
Instead, you should require miners to burn their coinbase reward. This
is effectively same as higher difficulty but is good for everyone: a)
mining variance and confirmation time unchanged; b) all bitcoin holders
become relatively richer
If you don't want to burn any bitcoin, you may require the miner the
send to penalty to <840000 + current height> OP_CHECKLOCKTIMEVERIFY,
which will subsidize the mining when the block reward drops below 1 BTC
3. It is a better idea to allow mining of a bigger block immediately,
which reduces (but not eliminates) the problem of tragedy of the
commons. However, you can't use the blocksize as the vote. Mining an
empty block doesn't mean the miner wants to decrease the block size to
200 bytes. That will just encourage some miners to fill up a block with
garbage which does no good for anyone. Therefore, you need to look at
both the actual block size and the coinbase vote, and always take the
bigger value to determine the penalty and the max block size of next
round. If a miner includes nothing in the coinbase, it should be
consider as a vote for the current max block size.
Btc Drak via bitcoin-dev 於 2015-08-29 06:15 寫到:
> On Sat, Aug 29, 2015 at 1:29 AM, Mark Friedenbach via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation.org> wrote:
>
> Mark and Jorge,
>
> I am very glad you have brought up this particular objection because
> it's something I thought about but was unclear if it was an opinion
> that would be shared by others. I chose to omit it from the proposal
> to see if it would come up during peer review.
>
> I feel that giving miners a blank cheque to increase blocksize, by any
> means, goes against a key design of bitcoin's security model. Full
> nodes keep miners honest by ensuring by validating their blocks. Under
> any voting-only scheme there is no way for full nodes to keep miners
> in cheque because miner have free reign to increase the blocksize.
>
> This problem can be solved by introducing a hard cap on blocksize. By
> introducing an upper limit miners now have the freedom to increase
> blocksize but only within defined parameters. Remember my proposal
> allows blocksize to increase and decrease in such a way that miners
> must collectively agree if they want the size to increase.
>
> I believe the idea of a hard upper limit has become rather politicised
> but is essential to the security model of bitcoin.
>
> With respect to the flexicap idea where miners can create a larger
> block by paying extra difficulty, I believe that proposal has a
> critical flaw because, as Gavin pointed out, it makes it very
> expensive (and risky) to include a few extra transactions. I believe
> it suffers from tragedy of the commons because there is no incentive
> for the mining community to reach consensus. Each and every block is
> going to be a gamble, "should we include a few extra transactions at
> the risk of losing the block?". Under my proposal miners can
> collectively agree to change the blocksize. Let's say they want a 10%
> increase, they can collude together to make that increase and once
> reached, it remains until they want to change it again. Yet, the upper
> hard limit keeps the ultimate control of the maximum block size
> squarely in the hands of full nodes.
>
> Whilst the exact number may be up for discussion, I would propose an
> initial upper limit of 8MB, so under my proposal the blocksize would
> be flexible between 1MB and 8MB.
>
> An alternative methodology to voting in the coinbase would be to
> change the vote to be the blocksize itself
>
> 1. miners pay extra difficulty to create a larger block.
> 2. every 2016 blocks the average or median of the last 2016 blocks is
> calculated and becomes the new maximum blocksize limit.
>
> This would retain incentive to collude to increase blocksize, as well
> as the property of costing to increase while being free to propose
> decrease.
>
> It would still require an upper blocksize limit in order for full
> nodes to retain control. Without an upper limit, any proposal is going
> to break the security model as full nodes give up some oversight
> control over miners.
>
> Another way of looking at these ideas is we're raising blocksize hard
> limit (to 8MB or whatever is decided), but making a soft of "softer"
> or inner limit part of consensus. Such a concept is not really
> departing from the current idea of a soft limit except to make it
> consensus enforced. Obviously it's not identical, but I think you can
> see the similarities.
>
> Does that make sense?
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft)
2015-08-29 17:51 ` Eric Lombrozo
@ 2015-08-29 19:13 ` Natanael
0 siblings, 0 replies; 26+ messages in thread
From: Natanael @ 2015-08-29 19:13 UTC (permalink / raw)
To: Eric Lombrozo; +Cc: bitcoin-dev
[-- Attachment #1: Type: text/plain, Size: 2735 bytes --]
My current idea:
* There's a scheduled hardcap that goes up over time.
* Miners vote on the blocksize limit within the hardcap, choosing the new
votecap. No particular idea for scheduling change. The 2016 block period
seems a bit long though, in case of sudden peak load.
(I'd suggest rolling vote over X blocks, enacted Y blocks later (with votes
counted from block A to block B = block A+X, the change is enacted at block
C = B+Y = A+X+Y). I'm fine with fixed-period schedules too if they span a
reasonable time, such as IMHO 2 days - we need rapid peak adjustment. No
suggestion on vote result calculation mechanism.)
* Casting votes are free.
* The mean (average) blocksize over the last time period X is calculated
for every block, or at the end of every fixed-length period (depending on
what scheduling is used for votes).
* Creating blocks larger than the mean but below the votecap raises the
difficulty target for the miner (and slightly raises the mean for future
blocks).
* The degree of difficulty raise depends on where between the mean and
votecap that the size of the given block is (and it follows that lots of
votes for large raise reduces per-extra-Kb penalty, allowing for cheaper
peak load adjustment if a large miner majority agrees). The degree of
increase may be either linear or logarithmic, I've got no suggestion
currently on any particular metric.
(Some might think this is an easy way for miners to collude to make large
blocks cheaper. If so, you could commit to only pay fee to miners that
don't vote for a block size above the size you accept, as a
counter-incentive.)
* Question: When the votecap is lowered, should the calculated mean be
forced down to follow (forcing a penalty for making blocks close to the
votecap straight after the change)? If so, how? Or should it be allowed to
fall naturally as new blocks with size below the votecap are created?
This is how miners would pay for actually creating larger blocks, and
leaves us with three methods of keeping the size in check (hardcap, votecap
and softcap). The softcap mechanism is then our third check to use if
deemed necessary (orphaning valid blocks if considered problematically
large). This third option do not need coordination with miners, they just
need to be aware which block size is accepted by the community.
I can't think of any sensible non-miner mechanism of deciding max block
size outside of using a community coordinated softcap, anything else will
not work reliably. Too hard to measure objectively and judge fairly.
The community would thus agree on a hardcap schedule in advance, and have
the option to threaten orphaning blocks via softfork later on if
circumstances would change and the votecap is too large.
[-- Attachment #2: Type: text/html, Size: 2962 bytes --]
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft)
2015-08-29 10:15 ` Btc Drak
2015-08-29 17:51 ` Eric Lombrozo
2015-08-29 19:03 ` jl2012
@ 2015-08-29 20:41 ` Jorge Timón
2015-08-30 17:13 ` jl2012
2 siblings, 1 reply; 26+ messages in thread
From: Jorge Timón @ 2015-08-29 20:41 UTC (permalink / raw)
To: Btc Drak; +Cc: Bitcoin Dev
On Sat, Aug 29, 2015 at 12:15 PM, Btc Drak <btcdrak@gmail•com> wrote:
> On Sat, Aug 29, 2015 at 1:29 AM, Mark Friedenbach via bitcoin-dev
> <bitcoin-dev@lists•linuxfoundation.org> wrote:
>> Ah, then my mistake. It seemed so similar to an idea that was proposed
>> before on this mailing list:
>>
>> http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008033.html
>>
>> that my mind just filled in the gaps. I concur -- having miners -- or any
>> group -- vote on block size is not an intrinsically good thing. The the
>> original proposal due to Greg Maxwell et al was not a mechanism for "voting"
>> but rather a feedback control that made the maximum block size that which
>> generated the most fees.
>
> Mark and Jorge,
>
> I am very glad you have brought up this particular objection because
> it's something I thought about but was unclear if it was an opinion
> that would be shared by others. I chose to omit it from the proposal
> to see if it would come up during peer review.
>
> I feel that giving miners a blank cheque to increase blocksize, by any
> means, goes against a key design of bitcoin's security model. Full
> nodes keep miners honest by ensuring by validating their blocks. Under
> any voting-only scheme there is no way for full nodes to keep miners
> in cheque because miner have free reign to increase the blocksize.
>
> This problem can be solved by introducing a hard cap on blocksize. By
> introducing an upper limit miners now have the freedom to increase
> blocksize but only within defined parameters. Remember my proposal
> allows blocksize to increase and decrease in such a way that miners
> must collectively agree if they want the size to increase.
Then I only care about the hard cap (for example, to me bip100 is
practically equivalent to just raise the limit to 32 MB directly).
Miners can always produce smaller blocks by modifying their local policy.
So if we need a maximum that cannot be altered by miners anyway, why
take the additional complexity of miners voting on a lower and
changing maximum size?
> With respect to the flexicap idea where miners can create a larger
> block by paying extra difficulty, I believe that proposal has a
> critical flaw because, as Gavin pointed out, it makes it very
> expensive (and risky) to include a few extra transactions. I believe
> it suffers from tragedy of the commons because there is no incentive
> for the mining community to reach consensus. Each and every block is
> going to be a gamble, "should we include a few extra transactions at
> the risk of losing the block?".
How expensive it is depends on the concrete function f(extra_nBits) =
extra_size_allowed
But the goal of that proposal is not to raise the size maximum
permanently, but rather temporarily allow bigger blocks when there are
spikes in demand (ie many fees to collect in unconfirmed
transactions).
Yes miners will ask that question to themselves, and the answer will
depend on the concrete function and on the fees of those extra
transactions.
The miner paying for the costs will get the gains: no tragedy of the
commons here.
> Under my proposal miners can
> collectively agree to change the blocksize. Let's say they want a 10%
> increase, they can collude together to make that increase and once
> reached, it remains until they want to change it again. Yet, the upper
> hard limit keeps the ultimate control of the maximum block size
> squarely in the hands of full nodes.
I believe the tragedy of the commons actually happens with your
proposal. Why would I pay alone for something that benefits all
miners?
> An alternative methodology to voting in the coinbase would be to
> change the vote to be the blocksize itself
>
> 1. miners pay extra difficulty to create a larger block.
> 2. every 2016 blocks the average or median of the last 2016 blocks is
> calculated and becomes the new maximum blocksize limit.
>
> This would retain incentive to collude to increase blocksize, as well
> as the property of costing to increase while being free to propose
> decrease.
This seems to solve the tragedy of the commons problem with your
current proposal.
It would be like flexcap but instead of the change in size being
temporary, it affects the next maximum size permanently.
One thing to worry about is miners filling blocks with
pay-to-themselves garbage to avoid reducing the size when they don't
have enough attractive transactions to include (ie it may not be free
for the network for miners to vote on "maintain current size").
> It would still require an upper blocksize limit in order for full
> nodes to retain control. Without an upper limit, any proposal is going
> to break the security model as full nodes give up some oversight
> control over miners.
>
> Another way of looking at these ideas is we're raising blocksize hard
> limit (to 8MB or whatever is decided), but making a soft of "softer"
> or inner limit part of consensus. Such a concept is not really
> departing from the current idea of a soft limit except to make it
> consensus enforced. Obviously it's not identical, but I think you can
> see the similarities.
>
> Does that make sense?
I still don't see the point in having a lower moving size maximum.
If 8 MB is mining-centralization-safe, let's move directly to 8 MB
without adding this seemingly useless extra complexity.
If it's not, mining voting on a lower moving maximum won't make it safer.
Once we have more objective tools (centralization metrics, simulators,
etc...) to determine whether or not a block size is
mining-centralization-safe for a given point in time (looking at
current centralization and current technology available), I don't see
the problem with repeating the equivalent of bip102 periodically
(every 2 years?) to adapt the size to better technology or lower
mining centralization.
It would be also helpful to have a tool to somehow measure "size
increase urgency" (ie right now free transactions get mined and blocks
aren't full or close to be full, I don't think the current general
sense of urgency on this matter is justified).
With all respect, I believe bip100 and this proposal are
over-engineering; and bip101 and bip103 (pieter's) are
overly-optimistic (in their exponential technological growth
assumptions).
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft)
2015-08-29 20:41 ` Jorge Timón
@ 2015-08-30 17:13 ` jl2012
2015-08-30 18:56 ` Jorge Timón
0 siblings, 1 reply; 26+ messages in thread
From: jl2012 @ 2015-08-30 17:13 UTC (permalink / raw)
To: Jorge Timón; +Cc: Bitcoin Dev
Jorge Timón via bitcoin-dev 於 2015-08-29 16:41 寫到:
>
> I still don't see the point in having a lower moving size maximum.
> If 8 MB is mining-centralization-safe, let's move directly to 8 MB
> without adding this seemingly useless extra complexity.
> If it's not, mining voting on a lower moving maximum won't make it
> safer.
>
> Once we have more objective tools (centralization metrics, simulators,
> etc...) to determine whether or not a block size is
> mining-centralization-safe for a given point in time (looking at
> current centralization and current technology available), I don't see
> the problem with repeating the equivalent of bip102 periodically
> (every 2 years?) to adapt the size to better technology or lower
> mining centralization.
> It would be also helpful to have a tool to somehow measure "size
> increase urgency" (ie right now free transactions get mined and blocks
> aren't full or close to be full, I don't think the current general
> sense of urgency on this matter is justified).
>
> With all respect, I believe bip100 and this proposal are
> over-engineering; and bip101 and bip103 (pieter's) are
> overly-optimistic (in their exponential technological growth
> assumptions).
This is based on the assumption that miners would always like to use up
the last byte of the available block size. However, this is just not
true:
1. The 6 year blockchain history has shown that most miners have a soft
cap with their block size.
2. Chinese miners, controlling 60% of the network, rejected Gavin's
initial 20MB proposal and asked for 8MB:
http://cointelegraph.com/news/114577/chinese-mining-pools-propose-alternative-8-mb-block-size
3. BTCChina supports BIP100 and will vote for 2MB at the beginning, with
8MB as a mid-term goal:
https://vip.btcchina.com/page/noticetemplate?id=100.
BTCChina is controlling 12% of the network in the past month. If BIP100
uses the 20-percentile vote as the block size, it takes only 8% more
vote to keep the size at 2MB
For many reasons miners may want to have a smaller block size, which we
don't need to list them here. Although they can limit it by a softfork
or even 51% attack, it is a very violent process. Why don't we just
allow them to vote for a lower limit?
So I think the right way is to choose a mining-centralization-safe
limit, and let it free float within a range based on miner's vote. If we
are lucky enough to have some responsible miners, they will keep it as
low as possible, until the legitimate tx volume catches up. Even in the
worst case, the block size is still mining-centralization-safe. The
upper limit may increase linearly, if not exponentially, until we find a
better long-term solution. (sort of a combination of BIP100 and 101,
with different parameters)
--------
For the matter of "urgency", I agree with you that there is no actual
urgency AT THIS MOMENT. However, if a hardfork may take 5 years to
deploy (as you suggested), we really have the urgency to make a decision
now. Actually, the main point is not urgency but uncertainty. We have
debated for 5 years. Why won't we have 5 more years of debate, plus 5
years of deployment delay? Are we sticking to 1MB for 10 years? In that
case Bitcoin Core must be abandoned by the economic majority and a
Schism fork must occur.
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft)
2015-08-30 17:13 ` jl2012
@ 2015-08-30 18:56 ` Jorge Timón
2015-08-31 18:50 ` jl2012
0 siblings, 1 reply; 26+ messages in thread
From: Jorge Timón @ 2015-08-30 18:56 UTC (permalink / raw)
To: jl2012; +Cc: Bitcoin Dev
On Sun, Aug 30, 2015 at 7:13 PM, <jl2012@xbt•hk> wrote:
> This is based on the assumption that miners would always like to use up the
> last byte of the available block size. However, this is just not true:
>
> 1. The 6 year blockchain history has shown that most miners have a soft cap
> with their block size.
>
> 2. Chinese miners, controlling 60% of the network, rejected Gavin's initial
> 20MB proposal and asked for 8MB:
> http://cointelegraph.com/news/114577/chinese-mining-pools-propose-alternative-8-mb-block-size
> [...]
No, I'm not making such assumption. I'm focusing on what they CAN do,
while suspending judgement on their good will and not trying to
predict their future behavior from historic behaviour.
With 60% of the hashrate, you can easily get 100% by orphaning
everybody else's blocks. More importantly, being under the same
jurisdiction they can be forced to behave in certain way (for example,
censor transactions) by law.
I'm very worried about the current situation no matter how benevolent
current miners are. Thus weakening the only limit to mining
centralization that we have at the consensus rule level seems
extremely risky at this point.
> For many reasons miners may want to have a smaller block size, which we
> don't need to list them here. Although they can limit it by a softfork or
> even 51% attack, it is a very violent process. Why don't we just allow them
> to vote for a lower limit?
>
> So I think the right way is to choose a mining-centralization-safe limit,
> and let it free float within a range based on miner's vote. If we are lucky
> enough to have some responsible miners, they will keep it as low as
> possible, until the legitimate tx volume catches up. Even in the worst case,
> the block size is still mining-centralization-safe. The upper limit may
> increase linearly, if not exponentially, until we find a better long-term
> solution. (sort of a combination of BIP100 and 101, with different
> parameters)
My point is, a "soft cap" determined by miners clearly doesn't protect
us from mining centralization: the "hard cap" does.
Knowing that, and given that miners can currently set their own policy
block size maximum, what does this "voting on a lower limit" achieve?
What are the gains? Why are we "lucky" if they keep the lower one as
low as possible?
> For the matter of "urgency", I agree with you that there is no actual
> urgency AT THIS MOMENT. However, if a hardfork may take 5 years to deploy
> (as you suggested), we really have the urgency to make a decision now.
Thank you for admitting it is not urgent!
I suggested 5 years for the concrete hardfork in bip99 because it's
clearly non-urgent and I wanted to be very conservative. I'm happy to
reduce that to say, 1 year (specially given that the change is very
simple to implement).
For a simple block size change (like, say bip102) 1 year (maybe 6
months + miner's confirmation) is probably more than enough as well.
And we can always deploy an urgency hardfork if it is necessary.
> Actually, the main point is not urgency but uncertainty. We have debated for
> 5 years. Why won't we have 5 more years of debate, plus 5 years of
> deployment delay? Are we sticking to 1MB for 10 years? In that case Bitcoin
> Core must be abandoned by the economic majority and a Schism fork must
> occur.
Fortunately we haven't been discussing this for 5 years, I don't know
where you get that from.
A schism fork it's certainly always a possibility but I would only
consider it after an urgency hardfork (once the issue becomes urgent)
fails due to not being uncontroversial.
Would you agree with me on that?
What would be your criterion for considering an increase in block size urgent?
Mine is: we should consider a block increase only when minimum market
fees for transactions to be mined (currently zero satoshis) increase
above a high fee (admittedly undefined, but certainly greater than
zero).
Even if it's "urgent", I think we should only increase the maximum if,
at the same time, the new size can be considered safe
mining-centralization-wise (unfortunately we don't have any metric to
measure that nor enough tools to realistically simulate different
sizes in different network topologies at the moment). But once we have
them, the next discussion will be much simpler, so I don't see the
need for block size maximum that changes over time (neither
exponentially nor linearly).
Would you agree with me that mining centralization should be the most
important criterion when changing the block size maximum rule rather
than the level of minimum fees?
If the community can't agree on this, I'm afraid there will be a
schism hardfork eventually. Another possibility is that those who
aren't concerned with mining centralization start their own altcoin
(centralizedcoin? ), maybe a spinoff [
https://bitcointalk.org/index.php?topic=563972.0 ] if they want to
keep Bitcoin's utxo at the moment of the separation.
But if the community agrees with this and just disagrees on the
maximum block size consensus rule having any effect on mining
centralization (like Gavin and I disagree), we should calm down and
use scientific processes to find out what the relation between the two
actually is (if there's any relation at all).
Would you agree with me on this?
^ permalink raw reply [flat|nested] 26+ messages in thread
* Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft)
2015-08-30 18:56 ` Jorge Timón
@ 2015-08-31 18:50 ` jl2012
0 siblings, 0 replies; 26+ messages in thread
From: jl2012 @ 2015-08-31 18:50 UTC (permalink / raw)
To: Jorge Timón; +Cc: Bitcoin Dev
Jorge Timón 於 2015-08-30 14:56 寫到:
> On Sun, Aug 30, 2015 at 7:13 PM, <jl2012@xbt•hk> wrote:
>> This is based on the assumption that miners would always like to use
>> up the
>> last byte of the available block size. However, this is just not true:
>>
>> 1. The 6 year blockchain history has shown that most miners have a
>> soft cap
>> with their block size.
>>
>> 2. Chinese miners, controlling 60% of the network, rejected Gavin's
>> initial
>> 20MB proposal and asked for 8MB:
>> http://cointelegraph.com/news/114577/chinese-mining-pools-propose-alternative-8-mb-block-size
>> [...]
>
> No, I'm not making such assumption. I'm focusing on what they CAN do,
> while suspending judgement on their good will and not trying to
> predict their future behavior from historic behaviour.
> With 60% of the hashrate, you can easily get 100% by orphaning
> everybody else's blocks. More importantly, being under the same
> jurisdiction they can be forced to behave in certain way (for example,
> censor transactions) by law.
> I'm very worried about the current situation no matter how benevolent
> current miners are. Thus weakening the only limit to mining
> centralization that we have at the consensus rule level seems
> extremely risky at this point.
The reason for 60% of block were generated in China is same as the
reason for 60% of your clothes were made in China. The electricity there
is the cheapest on the planet. Many dams were built in the past 10 years
and now they have huge amount of surplus electricity due to economic
downturn.
Not sure if you are aware of this thread:
https://bitcointalk.org/index.php?topic=1072474.0 . Could you imagine
this in any developed country? As long as mining is largely dependent on
energy, there is no hope to break the balance/imbalance.
Bandwidth is probably only a few percent of miners' cost. There is no
evidence that the current level of centralization is a result of block
size. Instead, clear evidence has shown that centralization is a result
of pool mining*, invention of ASIC, and disparity of energy cost. (*
People started pool mining in 2010 because they wanted lower variance,
not because of the inability to run a full node)
>> For many reasons miners may want to have a smaller block size, which
>> we
>> don't need to list them here. Although they can limit it by a softfork
>> or
>> even 51% attack, it is a very violent process. Why don't we just allow
>> them
>> to vote for a lower limit?
>>
>> So I think the right way is to choose a mining-centralization-safe
>> limit,
>> and let it free float within a range based on miner's vote. If we are
>> lucky
>> enough to have some responsible miners, they will keep it as low as
>> possible, until the legitimate tx volume catches up. Even in the worst
>> case,
>> the block size is still mining-centralization-safe. The upper limit
>> may
>> increase linearly, if not exponentially, until we find a better
>> long-term
>> solution. (sort of a combination of BIP100 and 101, with different
>> parameters)
>
> My point is, a "soft cap" determined by miners clearly doesn't protect
> us from mining centralization: the "hard cap" does.
> Knowing that, and given that miners can currently set their own policy
> block size maximum, what does this "voting on a lower limit" achieve?
> What are the gains? Why are we "lucky" if they keep the lower one as
> low as possible?
Even if we could quantify the level of centralization, it is a continuum
and we must compromise between utility and centralization. Unless
BIP101/103 is adopted, adjusting the hard cap always require a hardfork.
For obvious technical and political reasons we can't have hardfork too
frequently. Therefore, we need to leave some leeway: the hard cap may be
a bit too high for today, but we are sure that technology will catch up
in the near future.
Assuming we have plenty amount of "benevolent" miners, they will keep
the block size low unless there is a real demand for larger block space.
This is different from setting an individual soft limit, as that will
lead to block size scarcity and therefore higher tx fee, which may be
good for all miners. And as we say "miners can always decrease the block
size with softfork or 51% attack", BIP100 materializes this possibility
in a much smoother way.
I say "lucky" because I wholeheartedly believe it is good to keep the
block as small as we really need. We can't do this by an equation so I
would prefer to leave the power to miners (and they always have this
power, anyway).
>
>> For the matter of "urgency", I agree with you that there is no actual
>> urgency AT THIS MOMENT. However, if a hardfork may take 5 years to
>> deploy
>> (as you suggested), we really have the urgency to make a decision now.
>
> Thank you for admitting it is not urgent!
> I suggested 5 years for the concrete hardfork in bip99 because it's
> clearly non-urgent and I wanted to be very conservative. I'm happy to
> reduce that to say, 1 year (specially given that the change is very
> simple to implement).
> For a simple block size change (like, say bip102) 1 year (maybe 6
> months + miner's confirmation) is probably more than enough as well.
> And we can always deploy an urgency hardfork if it is necessary.
>
>> Actually, the main point is not urgency but uncertainty. We have
>> debated for
>> 5 years. Why won't we have 5 more years of debate, plus 5 years of
>> deployment delay? Are we sticking to 1MB for 10 years? In that case
>> Bitcoin
>> Core must be abandoned by the economic majority and a Schism fork must
>> occur.
>
> Fortunately we haven't been discussing this for 5 years, I don't know
> where you get that from.
Jeff and Satoshi discussed this in 2010, although the flame throwing
debate did not start until 2013.
> A schism fork it's certainly always a possibility but I would only
> consider it after an urgency hardfork (once the issue becomes urgent)
> fails due to not being uncontroversial.
> Would you agree with me on that?
> What would be your criterion for considering an increase in block size
> urgent?
The problem is the definition of "urgency" itself is controversial. And
I believe an urgent hardfork should only be done as a bug fix, not
implementation of a new feature. Block size increase should be a planned
feature, as we don't want the tx fee raised to 10USD, before suddenly
dropping to 0.01USD with the hardfork.
I don't think it's urgent today because my free tx always get mined. I
don't know what is urgent and different people have different
definition, but in general I think that should be measured by tx fee in
USD. 0.001USD/byte may be intolerable for many people. (It's about
$0.0001/byte now, and $0.0005/byte when it was $1200/BTC). It's not
difficult to reach this level given the halving and potential bull
market is coming.
> Mine is: we should consider a block increase only when minimum market
> fees for transactions to be mined (currently zero satoshis) increase
> above a high fee (admittedly undefined, but certainly greater than
> zero).
As I argued above, it's already too late when things become really
urgent. That will lead to serious market disruption, and the uncertainty
could be very harmful to the development of the bitcoin economy.
> Even if it's "urgent", I think we should only increase the maximum if,
> at the same time, the new size can be considered safe
> mining-centralization-wise (unfortunately we don't have any metric to
> measure that nor enough tools to realistically simulate different
> sizes in different network topologies at the moment). But once we have
> them, the next discussion will be much simpler, so I don't see the
> need for block size maximum that changes over time (neither
> exponentially nor linearly).
>
> Would you agree with me that mining centralization should be the most
> important criterion when changing the block size maximum rule rather
> than the level of minimum fees?
As I said above, strictly limiting the block size may have little effect
on mining centralization (because block size at this level is not a
determining factor), while it may seriously suppress the utility.
I'm all for mining decentralization but block size is just not the right
way to improve the situation.
> If the community can't agree on this, I'm afraid there will be a
> schism hardfork eventually. Another possibility is that those who
> aren't concerned with mining centralization start their own altcoin
> (centralizedcoin? ), maybe a spinoff [
> https://bitcointalk.org/index.php?topic=563972.0 ] if they want to
> keep Bitcoin's utxo at the moment of the separation.
>
> But if the community agrees with this and just disagrees on the
> maximum block size consensus rule having any effect on mining
> centralization (like Gavin and I disagree), we should calm down and
> use scientific processes to find out what the relation between the two
> actually is (if there's any relation at all).
>
> Would you agree with me on this?
I agree with you, but the balance between centralization and utility is
also important. (and I believe the difference between 1MB and 8MB is
tolerable, at least I must keep my full node running at this level)
I also have an idea to have a "decentralizedcoin", with very small
blocks and everyone could mine with a CPU. That would be interesting if
it is backed by famous devs in this area and is not
yet-another-scamcoin.
^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2015-08-31 18:50 UTC | newest]
Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2015-08-21 22:22 [bitcoin-dev] Consensus based block size retargeting algorithm (draft) Btc Drak
2015-08-21 23:17 ` Paul Sztorc
2015-08-22 0:06 ` Ahmed Zsales
2015-08-28 20:28 ` Btc Drak
2015-08-28 21:15 ` Matt Whitlock
2015-08-28 22:24 ` Gavin
2015-08-28 23:35 ` Chris Pacia
2015-08-28 23:38 ` Mark Friedenbach
2015-08-28 23:42 ` Matt Whitlock
2015-08-28 23:42 ` Chris Pacia
2015-08-29 0:00 ` Jorge Timón
2015-08-29 0:29 ` Mark Friedenbach
2015-08-29 10:15 ` Btc Drak
2015-08-29 17:51 ` Eric Lombrozo
2015-08-29 19:13 ` Natanael
2015-08-29 19:03 ` jl2012
2015-08-29 20:41 ` Jorge Timón
2015-08-30 17:13 ` jl2012
2015-08-30 18:56 ` Jorge Timón
2015-08-31 18:50 ` jl2012
2015-08-28 23:46 ` Btc Drak
2015-08-29 9:15 ` Elliot Olds
2015-08-28 23:38 ` Btc Drak
2015-08-28 23:36 ` Btc Drak
2015-08-28 23:44 ` Jorge Timón
2015-08-29 9:38 ` jl2012
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox