From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 0CB7AA87 for ; Fri, 27 Jan 2017 01:07:16 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 7D415F4 for ; Fri, 27 Jan 2017 01:07:15 +0000 (UTC) Received: from ishibashi.localnet (unknown [IPv6:2001:470:5:265:a45d:823b:2d27:961c]) (Authenticated sender: luke-jr) by zinan.dashjr.org (Postfix) with ESMTPSA id 1AE7E38A17B7 for ; Fri, 27 Jan 2017 01:07:03 +0000 (UTC) X-Hashcash: 1:25:170127:bitcoin-dev@lists.linuxfoundation.org::AcLtP+Zb2luXCEhO:a16m= From: Luke Dashjr 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; ; ) X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F X-PGP-Key-ID: BD02942421F4889F X-PGP-Keyserver: hkp://pgp.mit.edu MIME-Version: 1.0 Content-Type: Text/Plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201701270107.01092.luke@dashjr.org> X-Spam-Status: No, score=-5.1 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: [bitcoin-dev] Three hardfork-related BIPs X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Jan 2017 01:07:16 -0000 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