Errata + clarity (in bold): > > > - So in my proposal, if 2000+ *blocks *have a size >= 60% *of the > current limit*, 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. > > On Wed, Sep 9, 2015 at 9:11 AM, Washington Sanchez < washington.sanc...@gmail.com> wrote:
> 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) > > -- ------------------------------------------- *Dr Washington Y. Sanchez <http://onename.com/drwasho>* Co-founder, OB1 <http://ob1.io> Core developer of OpenBazaar <https://openbazaar.org> @drwasho <https://twitter.com/drwasho>
_______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
