1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
|
Return-Path: <luke@dashjr.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 0CB7AA87
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
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 <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; ; )
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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
|
