<div dir="ltr"><div><span style="font-size:12.8px">Your BIP implementation should stress the capacity to softfork the rate of blocksize increase if necessary. You briefly mention that: </span><br></div><div><span style="font-size:12.8px"><br></span><span style="color:rgb(51,51,51);font-family:-apple-system,blinkmacsystemfont,"segoe ui",helvetica,arial,sans-serif,"apple color emoji","segoe ui emoji","segoe ui symbol";font-size:16px;line-height:24px"><i>If over time, this growth factor is beyond what the actual technology offers, the intention should be to soft fork a tighter limit.</i></span><span style="font-size:12.8px"><i><br></i></span></div><div><span style="color:rgb(51,51,51);font-family:-apple-system,blinkmacsystemfont,"segoe ui",helvetica,arial,sans-serif,"apple color emoji","segoe ui emoji","segoe ui symbol";font-size:16px;line-height:24px"><i><br></i></span></div><div><span style="font-size:12.8px">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.</span><br></div><div><i style="font-size:12.8px"><br></i></div><div><span style="font-size:12.8px">Daniele</span></div><div><i style="font-size:12.8px"><br></i></div><div><i style="font-size:12.8px"><br></i></div><div><i style="font-size:12.8px"><br></i></div><i><span style="font-size:12.8px">Message: 5</span><br style="font-size:12.8px"><span style="font-size:12.8px">Date: Fri, 27 Jan 2017 01:06:59 +0000</span><br style="font-size:12.8px"><span style="font-size:12.8px">From: Luke Dashjr <</span><a href="mailto:luke@dashjr.org" style="font-size:12.8px">luke@dashjr.org</a><span style="font-size:12.8px">></span><br style="font-size:12.8px"><span style="font-size:12.8px">To: </span><a href="mailto:bitcoin-dev@lists.linuxfoundation.org" style="font-size:12.8px">bitcoin-dev@lists.<wbr>linuxfoundation.org</a><br style="font-size:12.8px"><span style="font-size:12.8px">Subject: [bitcoin-dev] Three hardfork-related BIPs</span><br style="font-size:12.8px"><span style="font-size:12.8px">Message-ID: <</span><a href="mailto:201701270107.01092.luke@dashjr.org" style="font-size:12.8px">201701270107.01092.luke@<wbr>dashjr.org</a><span style="font-size:12.8px">></span><br style="font-size:12.8px"><span style="font-size:12.8px">Content-Type: Text/Plain; charset="utf-8"</span><br style="font-size:12.8px"><br style="font-size:12.8px"><span style="font-size:12.8px">I've put together three hardfork-related BIPs. This is parallel to the ongoing</span><br style="font-size:12.8px"><span style="font-size:12.8px">research into the MMHF/SHF WIP BIP, which might still be best long-term.</span><br style="font-size:12.8px"><br style="font-size:12.8px"><span style="font-size:12.8px">1) The first is a block size limit protocol change. It also addresses three</span><br style="font-size:12.8px"><span style="font-size:12.8px">criticisms of segwit: 1) segwit increases the block size limit which is</span><br style="font-size:12.8px"><span style="font-size:12.8px">already considered by many to be too large; 2) segwit treats pre-segwit</span><br style="font-size:12.8px"><span style="font-size:12.8px">transactions ?unfairly? by giving the witness discount only to segwit</span><br style="font-size:12.8px"><span style="font-size:12.8px">transactions; and 3) that spam blocks can be larger than blocks mining</span><br style="font-size:12.8px"><span style="font-size:12.8px">legitimate transactions. This proposal may (depending on activation date)</span><br style="font-size:12.8px"><span style="font-size:12.8px">initially reduce the block size limit to a more sustainable size in the short-</span><br style="font-size:12.8px"><span style="font-size:12.8px">term, and gradually increase it up over the long-term to 31 MB; it will also</span><br style="font-size:12.8px"><span style="font-size:12.8px">extend the witness discount to non-segwit transactions. Should the initial</span><br style="font-size:12.8px"><span style="font-size:12.8px">block size limit reduction prove to be too controversial, miners can simply</span><br style="font-size:12.8px"><span style="font-size:12.8px">wait to activate it until closer to the point where it becomes acceptable</span><br style="font-size:12.8px"><span style="font-size:12.8px">and/or increases the limit. However, since the BIP includes a hardfork, the</span><br style="font-size:12.8px"><span style="font-size:12.8px">eventual block size increase needs community consensus before it can be</span><br style="font-size:12.8px"><span style="font-size:12.8px">deployed. Proponents of block size increases should note that this BIP does</span><br style="font-size:12.8px"><span style="font-size:12.8px">not interfere with another more aggressive block size increase hardfork in the</span><br style="font-size:12.8px"><span style="font-size:12.8px">meantime. I believe I can immediately recommend this for adoption; however,</span><br style="font-size:12.8px"><span style="font-size:12.8px">peer and community review are welcome to suggest changes.</span><br style="font-size:12.8px"><span style="font-size:12.8px">Text: </span><a href="https://github.com/luke-jr/bips/blob/bip-blksize/bip-blksize.mediawiki" rel="noreferrer" target="_blank" style="font-size:12.8px">https://github.com/luke-jr/<wbr>bips/blob/bip-blksize/bip-<wbr>blksize.mediawiki</a><br style="font-size:12.8px"><span style="font-size:12.8px">Code: </span><a href="https://github.com/bitcoin/bitcoin/compare/master...luke-jr:bip-blksize" rel="noreferrer" target="_blank" style="font-size:12.8px">https://github.com/bitcoin/<wbr>bitcoin/compare/master...luke-<wbr>jr:bip-blksize</a><br style="font-size:12.8px"><span style="font-size:12.8px">(consensus code changes only)</span><br style="font-size:12.8px"><br style="font-size:12.8px"><span style="font-size:12.8px">2) The second is a *preparatory* change, that should allow trivially</span><br style="font-size:12.8px"><span style="font-size:12.8px">transforming certain classes of hardforks into softforks in the future. It</span><br style="font-size:12.8px"><span style="font-size:12.8px">essentially says that full nodes should relax their rule enforcement, after</span><br style="font-size:12.8px"><span style="font-size:12.8px">sufficient time that would virtually guarantee they have ceased to be</span><br style="font-size:12.8px"><span style="font-size:12.8px">enforcing the full set of rules anyway. This allows these relaxed rules to be</span><br style="font-size:12.8px"><span style="font-size:12.8px">modified or removed in a softfork, provided the proposal to do so is accepted</span><br style="font-size:12.8px"><span style="font-size:12.8px">and implemented with enough advance notice. Attempting to implement this has</span><br style="font-size:12.8px"><span style="font-size:12.8px">proven more complicated than I originally expected, and it may make more sense</span><br style="font-size:12.8px"><span style="font-size:12.8px">for full nodes to simply stop functioning (with a user override) after the</span><br style="font-size:12.8px"><span style="font-size:12.8px">cut-off date). In light of this, I do not yet recommend its adoption, but am</span><br style="font-size:12.8px"><span style="font-size:12.8px">posting it for review and comments only.</span><br style="font-size:12.8px"><span style="font-size:12.8px">Text: </span><a href="https://github.com/luke-jr/bips/blob/bip-hfprep/bip-hfprep.mediawiki" rel="noreferrer" target="_blank" style="font-size:12.8px">https://github.com/luke-jr/<wbr>bips/blob/bip-hfprep/bip-<wbr>hfprep.mediawiki</a><br style="font-size:12.8px"><br style="font-size:12.8px"><span style="font-size:12.8px">3) Third is an anti-replay softfork which can be used to prevent replay</span><br style="font-size:12.8px"><span style="font-size:12.8px">attacks whether induced by a hardfork-related chain split, or even in ordinary</span><br style="font-size:12.8px"><span style="font-size:12.8px">operation. It does this by using a new opcode (OP_CHECKBLOCKATHEIGHT) for the</span><br style="font-size:12.8px"><span style="font-size:12.8px">Bitcoin scripting system that allows construction of transactions which are</span><br style="font-size:12.8px"><span style="font-size:12.8px">valid only on specific blockchains.</span><br style="font-size:12.8px"><span style="font-size:12.8px">Text: </span><a href="https://github.com/luke-jr/bips/blob/bip-noreplay/bip-noreplay.mediawiki" rel="noreferrer" target="_blank" style="font-size:12.8px">https://github.com/luke-jr/<wbr>bips/blob/bip-noreplay/bip-<wbr>noreplay.mediawiki</a><br style="font-size:12.8px"><br style="font-size:12.8px"><span style="font-size:12.8px">Luke</span></i><br clear="all"><div><div class="gmail_signature"><div dir="ltr"><div>Daniele Pinna, Ph.D</div></div></div></div>
</div>