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
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
|
Return-Path: <pete@petertodd.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id CDA2D10AC
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 30 Dec 2015 14:20:41 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from outmail149112.authsmtp.co.uk (outmail149112.authsmtp.co.uk
[62.13.149.112])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id 9114B128
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 30 Dec 2015 14:20:40 +0000 (UTC)
Received: from mail-c232.authsmtp.com (mail-c232.authsmtp.com [62.13.128.232])
by punt22.authsmtp.com (8.14.2/8.14.2/) with ESMTP id tBUEKd0p065199;
Wed, 30 Dec 2015 14:20:39 GMT
Received: from muck ([24.114.27.145]) (authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id tBUEKQNV086240
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Wed, 30 Dec 2015 14:20:36 GMT
Date: Wed, 30 Dec 2015 06:19:55 -0800
From: Peter Todd <pete@petertodd.org>
To: Jonathan Toomim <j@toom.im>
Message-ID: <20151230141955.GA15588@muck>
References: <6fc10e581a81abb76be5cd49275ebf48@openmailbox.org>
<8E12B367-1A55-435F-9244-101C09094BDA@toom.im>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="UlVJffcvxoiEqYs2"
Content-Disposition: inline
In-Reply-To: <8E12B367-1A55-435F-9244-101C09094BDA@toom.im>
X-Server-Quench: 7ff20de2-af00-11e5-829e-00151795d556
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aQdMdQIUHFAXAgsB AmMbWlBeUl17Wms7 aQ5PbARZfEhJQQRu
VVdMSlVNFUssc3l0 fX9gNBl6cQdCeDBx ZEJgWj5cChJ4dRIo
QFMFQ20GeGZhPWUC WEJRIh5UcAJPfxhM bwR6UXVDAzANdhEy
HhM4ODE3eDlSNhEd awdFLFcKRUsOEzgg TgwDGjNnGkNNbQQL
dkR8YlcHVE9ZKUI8 LVUmQ1FeWwA8
X-Authentic-SMTP: 61633532353630.1037:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 24.114.27.145/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] An implementation of BIP102 as a softfork.
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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: Wed, 30 Dec 2015 14:20:41 -0000
--UlVJffcvxoiEqYs2
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Wed, Dec 30, 2015 at 05:29:05AM -0800, Jonathan Toomim via bitcoin-dev w=
rote:
> As a first impression, I think this proposal is intellectually interestin=
g, but crufty and hackish and should never actually be deployed. Writing co=
de for Bitcoin in a future in which we have deployed a few generalized soft=
forks this way sounds terrifying.
<snip>
> It might be possible to make that a bit simpler with recursion, or by doi=
ng subsequent generalized softforks in a way that doesn't have multi-levels=
-deep block-within-a-block-within-a-block stuff. Still: ugh.
Your fear is misplaced: it's trivial to avoid recursion with a bit of
planning.
For instance, if Bitcoin was redesigned to incorporate the forced fork
concept, instead of block headers committing to just a merkle root,
they could instead commit to H(version + digest)
For version =3D=3D 0, digest would be a merkle root of all transactions. If
the version was > 0, any digest would be allowed and the block would be
interpreted as a NOP with no effect on the UTXO set.
In the event of a major change - e.g. what would otherwise be a
hard-forking change to the way the merkle root was calculated - a
soft-fork would change the block validity rules to make version =3D=3D 0
invalid, and verison =3D=3D 1 blocks would interpret the digest according to
the new merkle root rules. Again, version > 1 blocks would be treated as
NOPs.
A good exercise is to apply the above to the existing Bitcoin ecosystem
as a soft-fork - it certainely can be done, and done right is
technically very simple.
Regardless of how it's done - existing Bitcoin compatible or clean sheet
redesign - you get the significant safety advantages soft-forks have
over hard-forks in nearly all situations where you'd have to do a
hard-fork. OTOH, it's kinda scary how this institutionalizes what could
be seen as 51% attacks, possibly giving miners significantly more
control over the system politically. I'm not sure I agree with that
viewpoint - miners can do this anyway - but that has made people shy
away from promoting this idea in the past. (previously it's been often
referred to as an "evil" soft-fork)
--=20
'peter'[:-1]@petertodd.org
00000000000000000831fc2554d9370aeba2701fff09980123d24a615eee7416
--UlVJffcvxoiEqYs2
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
iQGrBAEBCACVBQJWg+gIXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAwODMxZmMyNTU0ZDkzNzBhZWJhMjcwMWZmZjA5OTgwMTIz
ZDI0YTYxNWVlZTc0MTYvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQwIXyHOf0udzccAf+Mnf/8IG+PuRMc1h1xwnqSBec
iingwOmih/ruy1qVUfK2kyh9fSVRHw5FvO/uUvnYY0GcLYdmX1OKRpCiBiIUEiMM
eCADPd54tddPP0IquqjCyI+SwlyZV0bhVHHXF3H7fwMn2eNtJsgt49NG40wTBulv
ycd0LILVnym1Shz3ckmi0qaO9b/90prtkimUEinZzG3+4WinvhiMTXZIujfuxKwS
wbYBUMNLsYuEllWxxh6qxLWmUz1p9rLKs0a1LzeH+TjRCCjLgQm7+oXPHY1gQnc5
BKeUfuyZOZyyj5/Ly2t4KgJrSGtcpe1Z9LjQftJQ8bpUJckuU1mgJXPrcM1qyg==
=y2u3
-----END PGP SIGNATURE-----
--UlVJffcvxoiEqYs2--
|
