{"type":"rich","version":"1.0","author_name":"npub1s4lj77xuzcu7wy04afcr487f0r3za0f8n2775xrpkld2sv639mjqsd44kw","author_url":"https://nostr.ae/npub1s4lj77xuzcu7wy04afcr487f0r3za0f8n2775xrpkld2sv639mjqsd44kw","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-05-28\n📝 Original message:On Fri, May 8, 2015 at 3:20 AM, Matt Whitlock \u003cbip at mattwhitlock.name\u003e wrote:\n\n\u003e Between all the flames on this list, several ideas were raised that did\n\u003e not get much attention. I hereby resubmit these ideas for consideration and\n\u003e discussion.\n\u003e\n\u003e - Perhaps the hard block size limit should be a function of the actual\n\u003e block sizes over some trailing sampling period. For example, take the\n\u003e median block size among the most recent 2016 blocks and multiply it by 1.5.\n\u003e This allows Bitcoin to scale up gradually and organically, rather than\n\u003e having human beings guessing at what is an appropriate limit.\n\u003e\n\nA lot of people like this idea, or something like it. It is nice and\nsimple, which is really important for consensus-critical code.\n\nWith this rule in place, I believe there would be more \"fee pressure\"\n(miners would be creating smaller blocks) today. I created a couple of\nhistograms of block sizes to infer what policy miners are ACTUALLY\nfollowing today with respect to block size:\n\nLast 1,000 blocks:\n  http://bitcoincore.org/~gavin/sizes_last1000.html\n\nNotice a big spike at 750K -- the default size for Bitcoin Core.\nThis graph might be misleading, because transaction volume or fees might\nnot be high enough over the last few days to fill blocks to whatever limit\nminers are willing to mine.\n\nSo I graphed a time when (according to statoshi.info) there WERE a lot of\ntransactions waiting to be confirmed:\n   http://bitcoincore.org/~gavin/sizes_357511.html\n\nThat might also be misleading, because it is possible there were a lot of\ntransactions waiting to be confirmed because miners who choose to create\nsmall blocks got lucky and found more blocks than normal.  In fact, it\nlooks like that is what happened: more smaller-than-normal blocks were\nfound, and the memory pool backed up.\n\nSo: what if we had a dynamic maximum size limit based on recent history?\n\nThe average block size is about 400K, so a 1.5x rule would make the max\nblock size 600K; miners would definitely be squeezing out transactions /\nputting pressure to increase transaction fees. Even a 2x rule (implying\n800K max blocks) would, today, be squeezing out transactions / putting\npressure to increase fees.\n\nUsing a median size instead of an average means the size can increase or\ndecrease more quickly. For example, imagine the rule is \"median of last\n2016 blocks\" and 49% of miners are producing 0-size blocks and 51% are\nproducing max-size blocks. The median is max-size, so the 51% have total\ncontrol over making blocks bigger.  Swap the roles, and the median is\nmin-size.\n\nBecause of that, I think using an average is better-- it means the max size\nwill change (up or down) more slowly.\n\nI also think 2016 blocks is too long, because transaction volumes change\nquicker than that. An average over 144 blocks (last 24 hours) would be\nbetter able to handle increased transaction volume around major holidays,\nand would also be able to react more quickly if an economically irrational\nattacker attempted to flood the network with fee-paying transactions.\n\nSo my straw-man proposal would be:  max size 2x average size over last 144\nblocks, calculated at every block.\n\nThere are a couple of other changes I'd pair with that consensus change:\n\n+ Make the default mining policy for Bitcoin Core neutral-- have its target\nblock size be the average size, so miners that don't care will \"go along\nwith the people who do care.\"\n\n+ Use something like Greg's formula for size instead of bytes-on-the-wire,\nto discourage bloating the UTXO set.\n\n\n---------\n\nWhen I've proposed (privately, to the other core committers) some dynamic\nalgorithm the objection has been \"but that gives miners complete control\nover the max block size.\"\n\nI think that worry is unjustified right now-- certainly, until we have\nsize-independent new block propagation there is an incentive for miners to\nkeep their blocks small, and we see miners creating small blocks even when\nthere are fee-paying transactions waiting to be confirmed.\n\nI don't even think it will be a problem if/when we do have size-independent\nnew block propagation, because I think the combination of the random timing\nof block-finding plus a dynamic limit as described above will create a\nhealthy system.\n\nIf I'm wrong, then it seems to me the miners will have a very strong\nincentive to, collectively, impose whatever rules are necessary (maybe a\nsoft-fork to put a hard cap on block size) to make the system healthy again.\n\n\n-- \n--\nGavin Andresen\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150528/5681756b/attachment.html\u003e"}