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 <adam@cypherspace.org> 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



--
-------------------------------------------
Co-founder, OB1
Core developer of OpenBazaar


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