[bitcoin-dev] Three hardfork-related BIPs

I've put together three hardfork-related BIPs. This is parallel to the ongoing research into the MMHF/SHF WIP BIP, which might still be best long-term. 1) The first is a block size limit protocol change. It also addresses three criticisms of segwit: 1) segwit increases the block size limit which is already considered by many to be too large; 2) segwit treats pre-segwit transactions “unfairly” by giving the witness discount only to segwit transactions; and 3) that spam blocks can be larger than blocks mining legitimate transactions. This proposal may (depending on activation date) initially reduce the block size limit to a more sustainable size in the short- term, and gradually increase it up over the long-term to 31 MB; it will also extend the witness discount to non-segwit transactions. Should the initial block size limit reduction prove to be too controversial, miners can simply wait to activate it until closer to the point where it becomes acceptable and/or increases the limit. However, since the BIP includes a hardfork, the eventual block size increase needs community consensus before it can be deployed. Proponents of block size increases should note that this BIP does not interfere with another more aggressive block size increase hardfork in the meantime. I believe I can immediately recommend this for adoption; however, peer and community review are welcome to suggest changes. Text: https://github.com/luke-jr/bips/blob/bip-blksize/bip-blksize.mediawiki Code: https://github.com/bitcoin/bitcoin/compare/master...luke-jr:bip-blksize (consensus code changes only) 2) The second is a *preparatory* change, that should allow trivially transforming certain classes of hardforks into softforks in the future. It essentially says that full nodes should relax their rule enforcement, after sufficient time that would virtually guarantee they have ceased to be enforcing the full set of rules anyway. This allows these relaxed rules to be modified or removed in a softfork, provided the proposal to do so is accepted and implemented with enough advance notice. Attempting to implement this has proven more complicated than I originally expected, and it may make more sense for full nodes to simply stop functioning (with a user override) after the cut-off date). In light of this, I do not yet recommend its adoption, but am posting it for review and comments only. Text: https://github.com/luke-jr/bips/blob/bip-hfprep/bip-hfprep.mediawiki 3) Third is an anti-replay softfork which can be used to prevent replay attacks whether induced by a hardfork-related chain split, or even in ordinary operation. It does this by using a new opcode (OP_CHECKBLOCKATHEIGHT) for the Bitcoin scripting system that allows construction of transactions which are valid only on specific blockchains. Text: https://github.com/luke-jr/bips/blob/bip-noreplay/bip-noreplay.mediawiki Luke