Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft)

[jl2012 via bitcoin-dev]

Jorge Timón 於 2015-08-30 14:56 寫到:

On Sun, Aug 30, 2015 at 7:13 PM,   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

Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft)

[Jorge Timón via bitcoin-dev]

On Sun, Aug 30, 2015 at 7:13 PM,  jl2...@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 

Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft)

[Elliot Olds via bitcoin-dev]

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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft)

[Eric Lombrozo via bitcoin-dev]

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

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft)

[Jorge Timón via bitcoin-dev]

On Sat, Aug 29, 2015 at 12:15 PM, Btc Drak btcd...@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 

Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft)

[Mark Friedenbach via bitcoin-dev]

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/90 * 20 = 0.1 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


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft)

[Btc Drak via bitcoin-dev]

On Fri, Aug 28, 2015 at 11:24 PM, Gavin gavinandre...@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/90 * 20 = 0.1 BTC

Typo, 0.0

 ... 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.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft)

[Matt Whitlock via bitcoin-dev]

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/90 * 20 = 0.1 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
 
 
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft)

[Chris Pacia via bitcoin-dev]

On Aug 28, 2015 7:38 PM, Mark Friedenbach m...@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/90 * 20 = 0.1 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

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft)

[Gavin via 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/90 * 20 = 0.1 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

Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft)

[Matt Whitlock via bitcoin-dev]

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

Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft)

[Btc Drak via 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 btcd...@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

Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft)

[Mark Friedenbach via bitcoin-dev]

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 jti...@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.

___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Consensus based block size retargeting algorithm (draft)

[Btc Drak via 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 btcd...@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

Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft)

[Paul Sztorc via 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 btcd...@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.
 

Re: [bitcoin-dev] Consensus based block size retargeting algorithm (draft)

[Ahmed Zsales via bitcoin-dev]

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 btcd...@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