rich1.0npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwethttps://nostr.ae/npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwetnjumphttps://nostr.ae📅 Original date posted:2013-03-13 📝 Original message:On Wed, Mar 13, 2013 at 5:56 AM, Luke-Jr <luke at dashjr.org> wrote: > FROM block 262144 to block 393216 (hard fork #1): > - Never make, and reject any block that includes more than 24391 transaction > modifications on its own (this *should* be equivalent to 1 MB) > - (this rules can make older client backports safe unless a reorg is more than > 6 blocks deep) I'm not a fan of the two stages, your before block 262144 part sounds fine to me, though I thought the safe number was closer to 5000. Perhaps 4911? The goal here is to pick something which is _absolutely sure_ to be less than what pre-0.8 accepts (so that its is just a soft fork), but it need not be needlessly smaller than that. I think we can accept some small risk of "backport" clients getting stuck after large reorgs after there has been sufficient upgrade time. Performance reasons mean that its very likely no one will be mining on those nodes by then, and so if they get stuck they'll just need to manually unstick them. Difficulty is high enough that its unlikely anything important will remain stuck long enough for a malicious party to exploit them by mining blocks on the stuck fork. By allowing that risk you halve the complexity of your change by not requiring two hard forks. The 'never make' half of it would probably be fine. As far as the size change, that should be a separate process after we've proven the ability to make a hardforking change with something low risk/low controversy like this, and only after someone has actually shown that the software is stable under those conditions lest we get another issue like we have now where the increase in block target from 500k/250k to 1MB by a miner exposed inadequate testing.