<oembed><type>rich</type><version>1.0</version><author_name>npub1lupuse8cysuanxcpq8h4d32359xxzedzjj83rmwv4yr9qxfmhtzqghjqch</author_name><author_url>https://nostr.ae/npub1lupuse8cysuanxcpq8h4d32359xxzedzjj83rmwv4yr9qxfmhtzqghjqch</author_url><provider_name>njump</provider_name><provider_url>https://nostr.ae</provider_url><html>📅 Original date posted:2016-12-05&#xA;📝 Original message:BIP Proposal - Managing Bitcoin’s block size the same way we do difficulty&#xA;(aka Block75)&#xA;&#xA;The every two-week adjustment of difficulty has proven to be a reasonably&#xA;effective and predictable way of managing how quickly blocks are mined.&#xA;Bitcoin needs a reasonably effective and predictable way of managing the&#xA;maximum block size.&#xA;&#xA;It’s clear at this point that human beings should not be involved in the&#xA;determination of max block size, just as they’re not involved in deciding&#xA;the difficulty.&#xA;&#xA;Instead of setting an arbitrary max block size (1MB, 2MB, 8MB, etc.) or&#xA;passing the decision to miners/pool operators, the max block size should be&#xA;adjusted every two weeks (2016 blocks) using a system similar to how&#xA;difficulty is calculated.&#xA;&#xA;Put another way: let’s stop thinking about what the max block size should&#xA;be and start thinking about how full we want the average block to be&#xA;regardless of size. Over the last year, we’ve had averages of 75% or&#xA;higher, so aiming for 75% full seems reasonable, hence naming this concept&#xA;‘Block75’.&#xA;&#xA;The target capacity over 2016 blocks would be 75%. If the last 2016 blocks&#xA;are more than 75% full, add the difference to the max block size. Like this:&#xA;&#xA;MAX_BLOCK_BASE_SIZE = 1000000&#xA;TARGET_CAPACITY = 750000&#xA;AVERAGE_OVER_CAP = average block size of last 2016 blocks minus&#xA;TARGET_CAPACITY&#xA;&#xA;To check if a block is valid, ≤ (MAX_BLOCK_BASE_SIZE + AVERAGE_OVER_CAP)&#xA;&#xA;For example, if the last 2016 blocks are 85% full (average block is 850&#xA;KB), add 10% to the max block size. The new max block size would be 1,100&#xA;KB until the next 2016 blocks are mined, then reset and recalculate. The&#xA;1,000,000 byte limit that exists currently would remain, but would&#xA;effectively be the minimum max block size.&#xA;&#xA;Another two weeks goes by, the last 2016 blocks are again 85% full, but now&#xA;that means they average 935 KB out of the 1,100 KB max block size. This is&#xA;93.5% of the 1,000,000 byte limit, so 18.5% would be added to that to make&#xA;the new max block size of 1,185 KB.&#xA;&#xA;Another two weeks passes. This time, the average block is 1,050 KB. The new&#xA;max block size is calculated to 1,300 KB (as blocks were 105% full, minus&#xA;the 75% capacity target, so 30% added to max block size).&#xA;&#xA;Repeat every 2016 blocks, forever.&#xA;&#xA;If Block75 had been applied at the difficulty adjustment on November 18th,&#xA;the max block size would have been 1,080KB, as the average block during&#xA;that period was 83% full, so 8% is added to the 1,000KB limit. The current&#xA;size, after the December 2nd adjustment would be 1,150K.&#xA;&#xA;Block75 would allow the max block size to grow (or shrink) in response to&#xA;transaction volume, and does so predictably, reasonably quickly, and in a&#xA;method that prevents wild swings in block size or transaction fees. It&#xA;attempts to keep blocks at 75% total capacity over each two week period,&#xA;the same way difficulty tries to keep blocks mined every ten minutes. It&#xA;also keeps blocks as small as possible.&#xA;&#xA;Thoughts?&#xA;&#xA;-t.k.&#xA;-------------- next part --------------&#xA;An HTML attachment was scrubbed...&#xA;URL: &lt;http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20161205/c24d6c6d/attachment.html&gt;</html></oembed>