As Block75 maintains blocks at 75% full (average over time), it automatically stabilizes transaction fees at about the level they were in May/June 2016. It will even do so through changes in transaction size and volume caused by SegWit and Lightning. - t.k. On Mon, Jan 9, 2017 at 11:14 PM, Ryan J Martin via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > The adaptive/automatic block size notion has been around for a > while--- others would be better able to speak to why it hasn't gotten > traction. However my concern with something like that is that it doesn't > regard the optimal economic equilibrium for tx fees/size---not that the > current limit does either but the concern with an auto-adjusting size limit > that ignores this would be the potential to create unforeseen > externalities for miners/users. Miners may decide it is more profitable to > mine very small blocks to constrict supply and increase marginal fees and > with how centralized mining is, where a dozen pools have 85% hashrate, a > couple of pools could do this. Then on the other side, maybe the prisoner's > dilemma would hold and all miners would have minrelaytxfee set at zero and > users would push the blocks to larger and larger sizes causing higher and > higher latency and network issues. > Perhaps something like this could work (I can only speak to the > economic side anyway) but it would have to have some solid code that has a > social benefit model built in to adjust to an equilibrium that is able to > optimize---as in maximizes benefit/minimize cost for both sides via a > Marshallian surplus model--- for each size point. > To be clear, I'm not saying an auto-adjusting limit is unworkable > (again only from an economic standpoint), just that it would need to have > these considerations built in. > > -Ryan J. Martin > > > ________________________________________ > > ------------------------------ > > Message: 2 > Date: Mon, 9 Jan 2017 14:52:31 -0500 > From: "t. khan" > To: Bitcoin Protocol Discussion > > Subject: [bitcoin-dev] BIP - Block75 - Historical and future > projections > Message-ID: > gmail.com> > Content-Type: text/plain; charset="utf-8" > > Using daily average block size over the past year (source: > https://blockchain.info/charts/avg-block-size? > daysAverageString=14×pan=1year > ), here's how Block75 would have altered max block sizes: > > [image: Inline image 1] > > As of today, the max block size would be 1,135KB. > > Looking forward and using the last year's growth rate as a model: > > [image: Inline image 2] > > This shows the max block size one year from now would be 2,064KB, if > Block75 activated today. > > Of course, this is just an estimate, but even accounting for a substantial > increase in transactions in the last quarter of 2017 and changes brought > about by SegWit (hopefully) activating, Block75 alters the max size in such > a way that allows for growth, keeps blocks as small as possible, *and* > maintains transaction fees at a level similar to May/June 2016. > > If anyone has an alternate way to model future behavior, please run it > through the Block75 algorithm. > > Every 2016 blocks, do this: > > new max blocksize = x + (x * (AVERAGE_CAPACITY - TARGET_CAPACITY)) > > TARGET_CAPACITY = 0.75 //Block75's target of keeping blocks 75% full > AVERAGE_CAPACITY = average percentage full of the last 2016 blocks, as a > decimal > x = current max block size > > > Thanks, > > - t.k. > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: attachments/20170109/b0e0b713/attachment.html> > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: Block75 2016.png > Type: image/png > Size: 32088 bytes > Desc: not available > URL: attachments/20170109/b0e0b713/attachment.png> > -------------- next part -------------- > A non-text attachment was scrubbed... > Name: Block75 2017.png > Type: image/png > Size: 33176 bytes > Desc: not available > URL: attachments/20170109/b0e0b713/attachment-0001.png> > > ------------------------------ > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > End of bitcoin-dev Digest, Vol 20, Issue 21 > ******************************************* > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >