[bitcoin-discuss] Block size idea - allow miners to dynamically adjust while disincentivising bloat

There are a few proposals on dynamic blocksizes so your first step maybe to catch up on those. This 2013 post by Peter Todd is probably a good place to start https://bitcointalk.org/index.php?topic=144895.0 And proof of the same by Dr Daniel Pina https://www.mail-archive.com/bitcoin-dev@lists.linuxfoundation.org/msg01838.html I do think flex cap proposals are interesting https://scalingbitcoin.org/hongkong2015/presentations/DAY2/3_tweaking_the_chain_2_friedenbach.pdf presentation https://www.youtube.com/watch?v=vfIs_trEhao&t=36m09s Some economic commentary from Jonathan Bier https://www.youtube.com/watch?v=ivgxcEOyWNs&t=1h1m Meni Rosenfeld also had a related proposal. Also improving the accounting of costs to reflect system resource demands can help scalability. http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/validation-cost-metric/ and https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-November/011662.html I gave some views on scaling fundamentals here http://diyhpl.us/wiki/transcripts/adam3us-bitcoin-scaling-tradeoffs/ and another more back to first principles version here https://diyhpl.us/wiki/transcripts/2015-09-07-epicenter-bitcoin-adam3us-scalability/ One open question to me, is with or without flexcaps, should we be concerned that Bitcoin would centralise to the point of failure, meaning essentially no one outside of some tier1 data centers with big iron equipment could gain trustless security assurances of Bitcoin (which are only achievable by operating your own fullnode). One could argue, that if that were to happen, it may be more secure to have bitcoin operate in a hybrid where there is a provable reserve kind of service or payment channel or centralised payment channel services plus bitcoin main chain, plus separately lightning. I say that because it's better for part of the system to be centralised than all of it, and you cant build trustless/decentralised systems on top of centralised systems, but the reverse is certainly possible. Theymos wrote about these kind of hybrid scale mechanisms https://www.reddit.com/r/Bitcoin/comments/5gjg5f/worst_case_scenario_protocol_is_set_in_stone_no/dat10wy/ For the immediate term I think we should look to scale bitcoin onchain as fast as we can within technical limits (and there are dozens of bottlenecks that have been profiled and optimised over years, in some cases multiple full refactors like IBD for example), which is pretty much what has been happing for the last years, and in parallel work to see what scale can be achieved by deploying the lightning layer on top of segwit which lots of people are also working on. Adam On 9 January 2017 at 02:05, John Hardy via bitcoin-discuss <bitcoin-discuss at lists.linuxfoundation.org> wrote: > Hi all, > > I’ve been trying to think of a way to implement a hard fork blocksize > increase that will satisfy as much of the community as possible. I wanted to > jot down my thinking incase anybody had any improvements and could then look > at turning it into a BIP. > > Handing control of the block size to the miners worries me. I do however see > merit in allowing miners to help guide the block size when needed, more > dynamically and easily than through hard forks each time. Rather than give > miners free reign I think there needs to be a risk to miners in order to > justify them making changes to the network, and to disincentivise > bloat/spam. > > I’d like to find a solution that kicks the can as far down the road as > possible until other solutions have hopefully resolved many scaling > concerns. Any proposal that minimises the need for any > unnecessary/additional hard forks is desirable. > > My basic idea is for miners to vote in each block to increase the block > size. > > A potential annual block size increase of 100% should satisfy those who are > concerned about the timescale/ability of offchain solutions to meet demand, > and mean that exponential growth on-chain is still possible. > > This would be achieved by each of the previous 2016 blocks voting to > increase the block size by the maximum amount of 2.7% each time. 26 > fortnightly increases of 2.7% would result in a block size increase of 99.9% > (rounding). > > We only need to use 3 bits for miners to vote on block size: > 000 = not voting > 001 = vote no change > 011 = vote decrease 2% > 101 = vote increase 1.35%, pay 10% of transaction fees to next block > 111 = vote increase 2.7%, pay 25% of transaction fees to next block > > Not including any transactions in a block will waive a miners’ right to > vote. > > Each block is a vote, and the block size change could be calculated by > averaging out all the votes over 2016 blocks. > > In order to achieve an increase in block size, the blocks must also have > been sufficiently full to justify one. Transactions with no fee and perhaps > outliers far from the mean tx fee/kb should perhaps not be included. > > By asking miners to pay a percentage of their transaction fees to the miner > of the next block, you discourage miners from stuffing the blocks with > transactions to artificially inflate the block size. > > If miners are in unanimous agreement that the block size needs to increase, > the fees would average out and all miners should still be equally rewarded. > Only miners trying to increase the block size when consensus is not there > would incur a cost. > > There should be a limit on the maximum increase, perhaps 8MB. Combined with > SegWit this should provide a reasonable balance between satisfying those who > are worried about missing out on exponential growth for a few years if LN > and other solutions are not as fast or effective as hoped. > > This is just an idea I’ve been thinking about to try and buy us as much > possible time before we need to hard fork again, and I hope its got > potential. Please let me know any thoughts/improvements and whether it might > be worth writing a BIP. > > Regards, > > John Hardy > john at seebitcoin.com > > > _______________________________________________ > bitcoin-discuss mailing list > bitcoin-discuss at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-discuss >