rich1.0npub1vtwuk4rjyj6zrq3tv2z9lvdm6a7g8zujf0gz9q2vljlztdaqw36sjjsjpghttps://nostr.ae/npub1vtwuk4rjyj6zrq3tv2z9lvdm6a7g8zujf0gz9q2vljlztdaqw36sjjsjpgnjumphttps://nostr.ae📅 Original date posted:2015-05-08 📝 Original message:On Fri, May 8, 2015 at 2:20 AM, Matt Whitlock <bip at mattwhitlock.name> wrote: > - Perhaps the hard block size limit should be a function of the actual block sizes over some > trailing sampling period. For example, take the median block size among the most recent > 2016 blocks and multiply it by 1.5. This allows Bitcoin to scale up gradually and organically, > rather than having human beings guessing at what is an appropriate limit. Block contents can be grinded much faster than hashgrinding and mining. There is a significant run-away effect there, and it also works in the gradual sense as a miner probabilistically mines large blocks that get averaged into that 2016 median block size computation. At least this proposal would be a slower way of pushing out miners and network participants that can't handle 100 GB blocks immediately.. As the size of the blocks are increased, low-end hardware participants have to fall off the network because they no longer meet the minimum performance requirements. Adjustment might become severely mismatched with general economic trends in data storage device development or availability or even current-market-saturation of said storage devices. With the assistance of transaction stuffing or grinding, that 2016 block median metric can be gamed to increase faster than other participants can keep up with or, perhaps worse, in a way that was unintended by developers yet known to be a failure mode. These are just some issues to keep and mind and consider. - Bryan http://heybryan.org/ 1 512 203 0507