Your BIP implementation should stress the capacity to softfork the rate of blocksize increase if necessary. You briefly mention that: *If over time, this growth factor is beyond what the actual technology offers, the intention should be to soft fork a tighter limit.* However this can work both ways so that the rate can potentially be increased also. I think just mentioning this will soothe a lot of future critiques. Daniele *Message: 5Date: Fri, 27 Jan 2017 01:06:59 +0000From: Luke Dashjr >To: bitcoin-dev@lists.linuxfoundation.org Subject: [bitcoin-dev] Three hardfork-related BIPsMessage-ID: <201701270107.01092.luke@dashjr.org <201701270107.01092.luke@dashjr.org>>Content-Type: Text/Plain; charset="utf-8"I've put together three hardfork-related BIPs. This is parallel to the ongoingresearch 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 threecriticisms of segwit: 1) segwit increases the block size limit which isalready considered by many to be too large; 2) segwit treats pre-segwittransactions ?unfairly? by giving the witness discount only to segwittransactions; and 3) that spam blocks can be larger than blocks mininglegitimate 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 alsoextend the witness discount to non-segwit transactions. Should the initialblock size limit reduction prove to be too controversial, miners can simplywait to activate it until closer to the point where it becomes acceptableand/or increases the limit. However, since the BIP includes a hardfork, theeventual block size increase needs community consensus before it can bedeployed. Proponents of block size increases should note that this BIP doesnot interfere with another more aggressive block size increase hardfork in themeantime. 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 triviallytransforming certain classes of hardforks into softforks in the future. Itessentially says that full nodes should relax their rule enforcement, aftersufficient time that would virtually guarantee they have ceased to beenforcing the full set of rules anyway. This allows these relaxed rules to bemodified or removed in a softfork, provided the proposal to do so is acceptedand implemented with enough advance notice. Attempting to implement this hasproven more complicated than I originally expected, and it may make more sensefor full nodes to simply stop functioning (with a user override) after thecut-off date). In light of this, I do not yet recommend its adoption, but amposting 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 replayattacks whether induced by a hardfork-related chain split, or even in ordinaryoperation. It does this by using a new opcode (OP_CHECKBLOCKATHEIGHT) for theBitcoin scripting system that allows construction of transactions which arevalid only on specific blockchains.Text: https://github.com/luke-jr/bips/blob/bip-noreplay/bip-noreplay.mediawiki Luke* Daniele Pinna, Ph.D