[bitcoin-dev] Dynamic limit to the block size - BIP draft discussion

[Washington Sanchez via bitcoin-dev]

Hi everyone,

I know many of us feel that the last thing the Bitcoin community needs is
another BIP related to the block size, but after a lot of reading and
commenting, I'd like to throw this idea out there.

I've already written it up as a BIP and would like some constructive
feedback/suggestions/alternatives related to some of the variables in my
specification:


Dynamic limit to the block size
===

The goal is to dynamically increase the maximum block size conservatively,
but allow meaningful relief to transaction volume pressure in response to
true market demand. The specification follows:

- Every 4032 blocks (~4 weeks), the maximum block size will be increased by
10% *IF* a minimum of 2000 blocks has a size >= 60% of the maximum block
size at that time
  + This calculates to theoretically 13 increases per year
- The maximum block size can only ever be increased, not decreased

For example, if this rule were to be instituted January 1st 2016, with a
present maximum block size 1 MB, the limit would be increased to 1.1 MB on
January 29th 2016. The theoretical maximum block size at the end of 2016
would be ~3.45 MB, assuming all 13 increases are triggered.

As the maximum block size rises, so the cost of artificially triggering an
increase in the maximum block size.


Regards,
Wash


---
*Dr Washington Y. Sanchez *
Co-founder, OB1 
Core developer of OpenBazaar 
@drwasho 
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Dynamic limit to the block size - BIP draft discussion

[Btc Drak via bitcoin-dev]

> but allow meaningful relief to transaction volume pressure in response to 
> true market demand

If blocksize can only increase then it's like a market that only goes
up which is unrealistic. Transaction will volume ebb and flow
significantly. Some people have been looking at transaction volume
charts over time and all they can see is an exponential curve which
they think will go on forever, yet nothing goes up forever and it will
go through significant trend cycles (like everything does). If you
dont want to hurt the fee market, the blocksize has to be elastic and
allow contraction as well as expansion.

On Tue, Sep 8, 2015 at 8:45 AM, Washington Sanchez via bitcoin-dev
 wrote:
> Hi everyone,
>
> I know many of us feel that the last thing the Bitcoin community needs is
> another BIP related to the block size, but after a lot of reading and
> commenting, I'd like to throw this idea out there.
>
> I've already written it up as a BIP and would like some constructive
> feedback/suggestions/alternatives related to some of the variables in my
> specification:
>
>
> Dynamic limit to the block size
> ===
>
> The goal is to dynamically increase the maximum block size conservatively,
> but allow meaningful relief to transaction volume pressure in response to
> true market demand. The specification follows:
>
> - Every 4032 blocks (~4 weeks), the maximum block size will be increased by
> 10% *IF* a minimum of 2000 blocks has a size >= 60% of the maximum block
> size at that time
>   + This calculates to theoretically 13 increases per year
> - The maximum block size can only ever be increased, not decreased
>
> For example, if this rule were to be instituted January 1st 2016, with a
> present maximum block size 1 MB, the limit would be increased to 1.1 MB on
> January 29th 2016. The theoretical maximum block size at the end of 2016
> would be ~3.45 MB, assuming all 13 increases are triggered.
>
> As the maximum block size rises, so the cost of artificially triggering an
> increase in the maximum block size.
>
>
> Regards,
> Wash
>
>
> ---
> Dr Washington Y. Sanchez
> Co-founder, OB1
> Core developer of OpenBazaar
> @drwasho
>
>
> ___
> 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] Dynamic limit to the block size - BIP draft discussion

[Ivan Brightly via bitcoin-dev]

This is true, but miners already control block size through soft caps.
Miners are fully capable of producing smaller blocks regardless of the max
block limit, with or without collusion. Arguably, there is no need to ever
reduce the max block size unless technology advances for some reason
reverse course - aka, WW3 takes a toll on the internet and the average
bandwidth available halves. The likelihood of significant technology
contraction in the near future seems rather unlikely and is more broadly
problematic for society than bitcoin specifically.

The only reason for reducing the max block limit other than technology
availability is if you think that this is what will produce the fee market,
which is back to an economic discussion - not a technology scaling
discussion.

On Tue, Sep 8, 2015 at 4:49 AM, Btc Drak via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> > but allow meaningful relief to transaction volume pressure in response
> to true market demand
>
> If blocksize can only increase then it's like a market that only goes
> up which is unrealistic. Transaction will volume ebb and flow
> significantly. Some people have been looking at transaction volume
> charts over time and all they can see is an exponential curve which
> they think will go on forever, yet nothing goes up forever and it will
> go through significant trend cycles (like everything does). If you
> dont want to hurt the fee market, the blocksize has to be elastic and
> allow contraction as well as expansion.
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Proposal to add the bitcoin symbol to Unicode

[Danny Thorpe via bitcoin-dev]

What of this prior effort, proposing B-with-horizontal-bar (Ƀ)?
http://bitcoinsymbol.org/

They argue that B-with-2-vertical-bars is easily confused with the Thai
Bhat currency symbol, which is a B with a single vertical bar.

I'm not terribly fond of the B-with-horizontal-bar as a symbol, but it does
have the advantage that it is already in the Unicode glyph set, already
available on most Unicode enabled devices.

-Danny

On Sat, Sep 5, 2015 at 7:11 AM, Ken Shirriff via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Use of the bitcoin symbol in text is inconvenient, because the bitcoin
> symbol isn't in the Unicode standard. To fix this, I've written a proposal
> to have the common B-with-vertical-bars bitcoin symbol added to Unicode.
> I've successfully proposed a new character for Unicode before, so I'm
> familiar with the process and think this has a good chance of succeeding.
> The proposal is at http://righto.com/bitcoin-unicode.pdf
>
> I received a suggestion to run this proposal by the bitcoin-dev group, so
> I hope this email is appropriate here. Endorsement by Bitcoin developers
> will help the Unicode Committee realize the importance of adding this
> symbol, so please let me know if you support this proposal.
>
> Thanks,
> Ken
>
>
>
> ___
> 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] Proposal to add the bitcoin symbol to Unicode

[Ken Shirriff via bitcoin-dev]

On Tue, Sep 8, 2015 at 1:28 PM, Danny Thorpe  wrote:

> What of this prior effort, proposing B-with-horizontal-bar (Ƀ)?
> http://bitcoinsymbol.org/
>
> They argue that B-with-2-vertical-bars is easily confused with the Thai
> Bhat currency symbol, which is a B with a single vertical bar.
>

Actually that page argues that using the Thai Bhat currency symbol *for*
Bitcoin causes confusion. From the page you linked to:

The Thai Baht (฿ ) is sometimes
used to represent Bitcoin, but this certainly raises a problem of
differenciation between the Thai Baht and Bitcoin.

Their main motivation for using the horizontal-bar Ƀ (which they admit is a
hack) is they consider adding a character to Unicode to be a "really long
and complicated process". My view is that adding the bitcoin sign to
Unicode avoids confusion with the Thai Baht, avoids hacks such as Ƀ, and
lets everyone use the standard symbol. Hopefully it won't be a really long
and complicated process...

Ken


> I'm not terribly fond of the B-with-horizontal-bar as a symbol, but it
> does have the advantage that it is already in the Unicode glyph set,
> already available on most Unicode enabled devices.
>
> -Danny
>
> On Sat, Sep 5, 2015 at 7:11 AM, Ken Shirriff via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Use of the bitcoin symbol in text is inconvenient, because the bitcoin
>> symbol isn't in the Unicode standard. To fix this, I've written a proposal
>> to have the common B-with-vertical-bars bitcoin symbol added to Unicode.
>> I've successfully proposed a new character for Unicode before, so I'm
>> familiar with the process and think this has a good chance of succeeding.
>> The proposal is at http://righto.com/bitcoin-unicode.pdf
>>
>> I received a suggestion to run this proposal by the bitcoin-dev group, so
>> I hope this email is appropriate here. Endorsement by Bitcoin developers
>> will help the Unicode Committee realize the importance of adding this
>> symbol, so please let me know if you support this proposal.
>>
>> Thanks,
>> Ken
>>
>>
>>
>> ___
>> 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] Dynamic limit to the block size - BIP draft discussion

[Washington Sanchez via bitcoin-dev]

>
> The maximum block-size is one that can be filled at zero-cost by
> miners, and so allows some kinds of amplification of selfish-mining
> related attacks


A selfish mining attack would have to be performed for at least 2000 blocks
over a period of 4 weeks in order to achieve a meager 10% increase in the
block size.

If there goal is to simply drive up fees to gain acceptance into the block,
we're in exactly the same position we are in today (as in nothing stops a
miner from doing this).
If the goal is to increase the block size to push out smaller miners,
they'll have to perform this attack over the course of years and destroy
any economic incentives they have for mining in the first place.

 why give this power up to a subsection of the ecosystem in order to make
> it easier to change or game


Well this same could be said for developers trying to predict what the
appropriate block size should be over the next 20 years... it's a hallmark
to a group of bankers trying to predict the appropriate interest rate for
the entire economy. Just as it is impossible to predict the appropriate
hash rate to secure the network, so it goes for the block size. Both need
to adjust dynamically to the scale/adoption of the network.

On Tue, Sep 8, 2015 at 11:13 PM, Adam Back  wrote:

> The maximum block-size is one that can be filled at zero-cost by
> miners, and so allows some kinds of amplification of selfish-mining
> related attacks.
>
> Adam
>
>
> On 8 September 2015 at 13:28, Ivan Brightly via bitcoin-dev
>  wrote:
> > This is true, but miners already control block size through soft caps.
> > Miners are fully capable of producing smaller blocks regardless of the
> max
> > block limit, with or without collusion. Arguably, there is no need to
> ever
> > reduce the max block size unless technology advances for some reason
> reverse
> > course - aka, WW3 takes a toll on the internet and the average bandwidth
> > available halves. The likelihood of significant technology contraction in
> > the near future seems rather unlikely and is more broadly problematic for
> > society than bitcoin specifically.
> >
> > The only reason for reducing the max block limit other than technology
> > availability is if you think that this is what will produce the fee
> market,
> > which is back to an economic discussion - not a technology scaling
> > discussion.
> >
> > On Tue, Sep 8, 2015 at 4:49 AM, Btc Drak via bitcoin-dev
> >  wrote:
> >>
> >> > but allow meaningful relief to transaction volume pressure in response
> >> > to true market demand
> >>
> >> If blocksize can only increase then it's like a market that only goes
> >> up which is unrealistic. Transaction will volume ebb and flow
> >> significantly. Some people have been looking at transaction volume
> >> charts over time and all they can see is an exponential curve which
> >> they think will go on forever, yet nothing goes up forever and it will
> >> go through significant trend cycles (like everything does). If you
> >> dont want to hurt the fee market, the blocksize has to be elastic and
> >> allow contraction as well as expansion.
> >
> >
> > ___
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
>



-- 
---
*Dr Washington Y. Sanchez *
Co-founder, OB1 
Core developer of OpenBazaar 
@drwasho 
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Dynamic limit to the block size - BIP draft discussion

[Adam Back via bitcoin-dev]

The maximum block-size is one that can be filled at zero-cost by
miners, and so allows some kinds of amplification of selfish-mining
related attacks.

Adam


On 8 September 2015 at 13:28, Ivan Brightly via bitcoin-dev
 wrote:
> This is true, but miners already control block size through soft caps.
> Miners are fully capable of producing smaller blocks regardless of the max
> block limit, with or without collusion. Arguably, there is no need to ever
> reduce the max block size unless technology advances for some reason reverse
> course - aka, WW3 takes a toll on the internet and the average bandwidth
> available halves. The likelihood of significant technology contraction in
> the near future seems rather unlikely and is more broadly problematic for
> society than bitcoin specifically.
>
> The only reason for reducing the max block limit other than technology
> availability is if you think that this is what will produce the fee market,
> which is back to an economic discussion - not a technology scaling
> discussion.
>
> On Tue, Sep 8, 2015 at 4:49 AM, Btc Drak via bitcoin-dev
>  wrote:
>>
>> > but allow meaningful relief to transaction volume pressure in response
>> > to true market demand
>>
>> If blocksize can only increase then it's like a market that only goes
>> up which is unrealistic. Transaction will volume ebb and flow
>> significantly. Some people have been looking at transaction volume
>> charts over time and all they can see is an exponential curve which
>> they think will go on forever, yet nothing goes up forever and it will
>> go through significant trend cycles (like everything does). If you
>> dont want to hurt the fee market, the blocksize has to be elastic and
>> allow contraction as well as expansion.
>
>
> ___
> 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] Dynamic limit to the block size - BIP draft discussion

[Washington Sanchez via bitcoin-dev]

>
> If you want me to take your proposal seriously, you need to justify why
> 60% full is a good answer
>

Sure thing Gavin.

If you want blocks to be at least 60% full...


First off, I do not want blocks to be at least 60% full, so let me try and
explain where I got this number from

   - The idea of this parameter is set a *triggering level* for an increase
   in the block size
   - The triggering level is the point where a reasonable medium-term trend
   can be observed. That trend is an increase in the transaction volume that,
   left unchecked, would fill up blocks.
   - Determining the appropriate triggering level is difficult, and it
   consists of 3 parameters:
  1. Evaluation period
 - *Period of time where you check to see if the conditions to
 trigger a raise the block size are true *
 - Ideally you want an increase to occur in response to a real
 increase of transaction volume from the market, and not some
short term
 spam attack.
 - Too short, spam attacks can be used to trigger multiple
 increases (at least early on). Too long, the block size
doesn't increase
 fast enough to transaction demand.
 - I selected a period of *4032 blocks*
 2. Capacity
 - *The capacity level that a majority of blocks would demonstrate
 in order to trigger a block size increase*
 - The capacity level, in tandem with the evaluation period and
 threshold level, needs to reflect an underlying trend towards filling
 blocks.
 - If the capacity level is too low, block size increases can be
 triggered prematurely. If the capacity level is too high, the
network could
 be unnecessarily jammed with the transactions before an
increase can kick
 in.
 - I selected a capacity level of *60%*.
  3. Threshold
 - *The number of blocks during the evaluation period that are
 above the capacity level in order to trigger a block size increase.*
 - If blocks are getting larger than 60% over a 4032 block period,
 how many reflect a market-driven increase transaction volume?
 - If the threshold is too low, increases could be triggered
 artificially or prematurely. If the threshold is too high,
the easier it
 gets for 1-2 mining pools to prevent any increases in the
block size or the
 block size doesn't respond fast enough to a real increase in
transaction
 volume.
 - I selected a threshold of *2000 blocks or ~50%*.
  - So in my proposal, if 2000+ nodes have a block size >= 60%, this is
   an indication that real transaction volume has increased and we're
   approaching a time where block could be filled to capacity without an
   increase. The block size increase, 10%, is triggered.

A centralized decision, presumably by Satoshi, was made on the parameters
that alter the target difficulty, rather than attempt to forecast hash
rates based on his CPU power. He allowed the system to scale to a level
where real market demand would take it. I believe the same approach should
be replicated for the block size. The trick of course is settling on the
right variables. I hope this proposal is a good way to do that.

*Some additional calculations*

Block sizes for each year are *theoretical maximums* if ALL trigger points
are activated in my proposal (unlikely, but anyway).
These calculations assume zero transactions are taken off-chain by third
party processors or the LN, and no efficiency improvements.

   - 2015
  - 1 MB/block
  - 2 tps (conservative factor, also carried on below)
  - 0.17 million tx/day
   - 2016
  - 3.45 MB/block
  - 7 tps
  - 0.6 million tx/day
   - 2017
  - 12 MB/block
  - 24 tps
  - 2 million tx/day
   - 2018
  - 41 MB/block
  - 82 tps
  - 7 million tx/day
   - 2019
  - 142 MB/block
  - 284 tps
  - 25 million tx/day
   - 2020
  - 490 MB/block
  - 980 tps
  - 85 million tx/day

By way of comparison, Alipay (payment processor for the Alibaba Group's
ecosystem) processes 30 million escrow transactions per day. This gives us
at least 4-5 years to reach the present day transaction processing capacity
of 1 corporation... in reality it will take a little longer as I doubt all
block size triggers will be activated. This also gives us at least 4-5
years to develop efficiency improvements within the protocol, develop the
LN to take many of these transactions off-chain, and network infrastructure
to be significantly improved (and anything else this ecosystem can come up
with).

(let me know if any of these calculations are off)
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Dynamic limit to the block size - BIP draft discussion

[Washington Sanchez via bitcoin-dev]

1) It's not really clear to me how that would work, but assuming it does
then it will go into a basket of attacks that are possible but unlikely due
to the economic disincentives to do so.

2) That said, is the Achilles heal of this proposal the lack of a mechanism
to lower the block size?

3) Let me put it another way, I've read that both Gavin and yourself are
favorable to a dynamic limit on the block size. In your view, what is
missing from this proposal, or what variables should be adjusted, to get
the rules to a place where you and other Core developers would seriously
consider it?

On Wed, Sep 9, 2015 at 12:18 AM, Adam Back  wrote:

> > A selfish mining attack would have to be performed for at least 2000
> blocks over a period of 4 weeks in order to achieve a meager 10% increase
> in the block size.
>
> You seem to be analysing a different attack - I mean that if someone
> has enough hashrate to do a selfish mining attack, then setting up a
> system that has no means to reduce block-size risks that at a point
> where there is excess block-size they can use that free transaction
> space to amplify selfish mining instead of collecting transaction
> fees.
>
> Adam
>



-- 
---
*Dr Washington Y. Sanchez *
Co-founder, OB1 
Core developer of OpenBazaar 
@drwasho 
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Dynamic limit to the block size - BIP draft discussion

[Ivan Brightly via bitcoin-dev]

Agreed. For this reason, the scaling BIPs which don't allow for easy gaming
such as BIP101, your proposal or Pieter's are preferable for their
predictability and simplicity. Changing the fundamental rules for Bitcoin
is supposed to be hard - why give this power up to a subsection of the
ecosystem in order to make it easier to change or game?

On Tue, Sep 8, 2015 at 9:13 AM, Adam Back  wrote:

> The maximum block-size is one that can be filled at zero-cost by
> miners, and so allows some kinds of amplification of selfish-mining
> related attacks.
>
> Adam
>
>
> On 8 September 2015 at 13:28, Ivan Brightly via bitcoin-dev
>  wrote:
> > This is true, but miners already control block size through soft caps.
> > Miners are fully capable of producing smaller blocks regardless of the
> max
> > block limit, with or without collusion. Arguably, there is no need to
> ever
> > reduce the max block size unless technology advances for some reason
> reverse
> > course - aka, WW3 takes a toll on the internet and the average bandwidth
> > available halves. The likelihood of significant technology contraction in
> > the near future seems rather unlikely and is more broadly problematic for
> > society than bitcoin specifically.
> >
> > The only reason for reducing the max block limit other than technology
> > availability is if you think that this is what will produce the fee
> market,
> > which is back to an economic discussion - not a technology scaling
> > discussion.
> >
> > On Tue, Sep 8, 2015 at 4:49 AM, Btc Drak via bitcoin-dev
> >  wrote:
> >>
> >> > but allow meaningful relief to transaction volume pressure in response
> >> > to true market demand
> >>
> >> If blocksize can only increase then it's like a market that only goes
> >> up which is unrealistic. Transaction will volume ebb and flow
> >> significantly. Some people have been looking at transaction volume
> >> charts over time and all they can see is an exponential curve which
> >> they think will go on forever, yet nothing goes up forever and it will
> >> go through significant trend cycles (like everything does). If you
> >> dont want to hurt the fee market, the blocksize has to be elastic and
> >> allow contraction as well as expansion.
> >
> >
> > ___
> > 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] Dynamic limit to the block size - BIP draft discussion

[Gavin Andresen via bitcoin-dev]

>
> 3) Let me put it another way, I've read that both Gavin and yourself are
> favorable to a dynamic limit on the block size. In your view, what is
> missing from this proposal, or what variables should be adjusted, to get
> the rules to a place where you and other Core developers would seriously
> consider it?
>

I'm not clear on what problem(s) you're trying to solve.

If you want blocks to be at least 60% full, then just specify a simple rule
like "maximum block size is 1.0/0.6 = 1.666 times the average block size
over the last N blocks (applied at every block or every 2016 blocks or
whatever, details don't really matter)".

If you want an upper limit on growth, then just implement a simple rule
like "Absolute maximum block size is 1 megabyte in 2016, 3.45 megabytes in
2017, and increases by a maximum of 3.45 times every year."

If you want me to take your proposal seriously, you need to justify why 60%
full is a good answer (and why we need a centralized decision on how full
blocks "should" be), and why 3.45 times-per-year is a good answer for
maximum growth (and, again, why we need a centralized decision on that).

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

Re: [bitcoin-dev] Dynamic limit to the block size - BIP draft discussion

[Andrew Johnson via bitcoin-dev]

I rather like this idea, I like that we're taking block scaling back to a
technical method rather than political.  BIP100 is frightening to me as it
gives a disproportionate amount of power to the miners, who can already
control their own blocksize with a soft cap.  It also seems silly to worry
about a selfish mining attack if you're going to institute a miner vote
that an entity with that much hashrate can noticeably influence anyway.

101 is better but is still attempting to make a guess as to technological
progression quite far into the future.  And then when we do finally hit 8GB
we will need yet another hard fork if we need to go bigger(or we may need
to do it earlier if the increase schedule isn't aggressive enough).  And
who knows how large the ecosystem may be at that time, a hard fork may be
an undertaking of truly epic proportions due to the sheer number of devices
and embedded firmware that operates on the block chain.

I've done no math on this(posting from mobile) but something similar to
this would be reasonable, I think.  Unbounded growth, as Adam points out,
is also undesirable.

Every 4032 blocks (~4 weeks), the maximum block size will be decreased by
10% *IF* a minimum of 2500 blocks has a size <= 40% of the maximum block
size at that time.

This requires a larger threshold to be crossed to move downwards, that way
we hopefully aren't oscillating back and forth constantly.  I'll try to do
some blockchain research sometime this week and either back my plucked from
the air numbers or change them.

Andrew Johnson
On Sep 8, 2015 10:11 AM, "Washington Sanchez via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> 1) It's not really clear to me how that would work, but assuming it does
> then it will go into a basket of attacks that are possible but unlikely due
> to the economic disincentives to do so.
>
> 2) That said, is the Achilles heal of this proposal the lack of a
> mechanism to lower the block size?
>
> 3) Let me put it another way, I've read that both Gavin and yourself are
> favorable to a dynamic limit on the block size. In your view, what is
> missing from this proposal, or what variables should be adjusted, to get
> the rules to a place where you and other Core developers would seriously
> consider it?
>
> On Wed, Sep 9, 2015 at 12:18 AM, Adam Back  wrote:
>
>> > A selfish mining attack would have to be performed for at least 2000
>> blocks over a period of 4 weeks in order to achieve a meager 10% increase
>> in the block size.
>>
>> You seem to be analysing a different attack - I mean that if someone
>> has enough hashrate to do a selfish mining attack, then setting up a
>> system that has no means to reduce block-size risks that at a point
>> where there is excess block-size they can use that free transaction
>> space to amplify selfish mining instead of collecting transaction
>> fees.
>>
>> Adam
>>
>
>
>
> --
> ---
> *Dr Washington Y. Sanchez *
> Co-founder, OB1 
> Core developer of OpenBazaar 
> @drwasho 
>
>
> ___
> 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