From: Luke Dashjr <luke@dashjr.org>
To: bitcoin-dev@lists.linuxfoundation.org
Date: Fri, 27 Jan 2017 01:06:59 +0000
User-Agent: KMail/1.13.7 (Linux/4.4.39-gentoo; KDE/4.14.24; x86_64; ; )
MIME-Version: 1.0
Content-Type: Text/Plain;
  charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Message-Id: <201701270107.01092.luke@dashjr.org>
Subject: [bitcoin-dev] Three hardfork-related BIPs
Precedence: list

I've put together three hardfork-related BIPs. This is parallel to the ongo=
ing=20
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=
=20
criticisms of segwit: 1) segwit increases the block size limit which is=20
already considered by many to be too large; 2) segwit treats pre-segwit=20
transactions =E2=80=9Cunfairly=E2=80=9D by giving the witness discount only=
 to segwit=20
transactions; and 3) that spam blocks can be larger than blocks mining=20
legitimate transactions. This proposal may (depending on activation date)=20
initially reduce the block size limit to a more sustainable size in the sho=
rt-
term, and gradually increase it up over the long-term to 31 MB; it will als=
o=20
extend the witness discount to non-segwit transactions. Should the initial=
=20
block size limit reduction prove to be too controversial, miners can simply=
=20
wait to activate it until closer to the point where it becomes acceptable=20
and/or increases the limit. However, since the BIP includes a hardfork, the=
=20
eventual block size increase needs community consensus before it can be=20
deployed. Proponents of block size increases should note that this BIP does=
=20
not interfere with another more aggressive block size increase hardfork in =
the=20
meantime. I believe I can immediately recommend this for adoption; however,=
=20
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-blksi=
ze=20
(consensus code changes only)

2) The second is a *preparatory* change, that should allow trivially=20
transforming certain classes of hardforks into softforks in the future. It=
=20
essentially says that full nodes should relax their rule enforcement, after=
=20
sufficient time that would virtually guarantee they have ceased to be=20
enforcing the full set of rules anyway. This allows these relaxed rules to =
be=20
modified or removed in a softfork, provided the proposal to do so is accept=
ed=20
and implemented with enough advance notice. Attempting to implement this ha=
s=20
proven more complicated than I originally expected, and it may make more se=
nse=20
for full nodes to simply stop functioning (with a user override) after the=
=20
cut-off date). In light of this, I do not yet recommend its adoption, but a=
m=20
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=20
attacks whether induced by a hardfork-related chain split, or even in ordin=
ary=20
operation. It does this by using a new opcode (OP_CHECKBLOCKATHEIGHT) for t=
he=20
Bitcoin scripting system that allows construction of transactions which are=
=20
valid only on specific blockchains.
Text: https://github.com/luke-jr/bips/blob/bip-noreplay/bip-noreplay.mediaw=
iki

Luke