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
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1VbCGH-00043D-5y
for bitcoin-development@lists.sourceforge.net;
Tue, 29 Oct 2013 16:35:21 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.149.55 as permitted sender)
client-ip=62.13.149.55; envelope-from=pete@petertodd.org;
helo=outmail149055.authsmtp.co.uk;
Received: from outmail149055.authsmtp.co.uk ([62.13.149.55])
by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1VbCGE-0005t0-UE for bitcoin-development@lists.sourceforge.net;
Tue, 29 Oct 2013 16:35:21 +0000
Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235])
by punt9.authsmtp.com (8.14.2/8.14.2) with ESMTP id r9TGZCnF010851;
Tue, 29 Oct 2013 16:35:12 GMT
Received: from petertodd.org (petertodd.org [174.129.28.249])
(authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id r9TGZ6DD056510
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Tue, 29 Oct 2013 16:35:10 GMT
Date: Tue, 29 Oct 2013 12:35:05 -0400
From: Peter Todd <pete@petertodd.org>
To: Mike Hearn <mike@plan99.net>
Message-ID: <20131029163505.GA28320@petertodd.org>
References: <526B45DB.2030200@jerviss.org>
<CABsx9T2OMA_u=S9yUh2j78QDuCDUorYctktuixjwAjqc6neW=Q@mail.gmail.com>
<526DD18A.7060201@jerviss.org> <l4lajm$3ga$1@ger.gmane.org>
<CAAS2fgSuL4f9Sdg2CyK-EuCKK04gD98zHDoKFyTg_Fp_cNiz=A@mail.gmail.com>
<CABsx9T3p6KFc8FiOgBwLtQsmkETE_iUbMhO47pS7J3hi3a9_4w@mail.gmail.com>
<CANEZrP1teOnb=Gt_Nybh0jfQopK06Ps34Hy73OxOpHwuz-iZig@mail.gmail.com>
<20131029101452.GA15808@savin>
<7a22afbd-ad30-4748-8c88-9a1eda3e2fe9@email.android.com>
<CANEZrP2cu7WJs2TbrFxFibwAHDVbxb7EJQ3mOrVs+ZQm-uU1LQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="VS++wcV0S1rZb1Fb"
Content-Disposition: inline
In-Reply-To: <CANEZrP2cu7WJs2TbrFxFibwAHDVbxb7EJQ3mOrVs+ZQm-uU1LQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 14472d7a-40b8-11e3-b802-002590a15da7
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aQdMdAsUF1YAAgsB AmUbWlJeU1h7WGM7 ag1VcwRfa1RMVxto
VEFWR1pVCwQmQxVl cXQYJm1ycgNDeX4+ Z0JkVnAVXUB+ckQp
RR9JEW1UbXphaTUc TRJQdwFJcANIexZF O1F6ACIKLwdSbGoL
NQ4vNDcwO3BTJTpY RgYVKF8UXXNDOTh0 XBcMAXAhGlcGXG06
KRBuKlcGEAMfNV8x KjMA
X-Authentic-SMTP: 61633532353630.1023:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 174.129.28.249/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
X-Spam-Score: -1.5 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information. [URIs: petertodd.org]
X-Headers-End: 1VbCGE-0005t0-UE
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>,
Andreas Schildbach <andreas@schildbach.de>
Subject: Re: [Bitcoin-development] On soft-forks and hard-forks
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Tue, 29 Oct 2013 16:35:21 -0000
--VS++wcV0S1rZb1Fb
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
> On Tue, Oct 29, 2013 at 12:38 PM, Peter Todd <pete@petertodd.org> wrote:
> > Peter Todd <pete@petertodd.org> wrote:
> > >On Tue, Oct 29, 2013 at 10:52:31AM +0100, Mike Hearn wrote:
> > >> For block 0x11 again shall there be a separate code for "block is
> > >from the
> > >> future"? We don't want to lose the nVersion field to people just
> > >using it
> > >> for nonsense, so does it make sense to reject blocks that claim to be
> > >v2 or
> > >> v3?
> > >
> > >That would prevent us from using nVersion as a soft-forking mechanism.
> >
> > Actually, that statement didn't go far enough: rejecting blocks with
> > nVersions that you don't expect is a hard fork.
>
> Yes, exactly. That's the point. As you well know I think the whole
> soft-fork mechanism is wrong and should not be used. If the rules change,
> your node is *supposed* to end up on a chain fork and trigger an alert to
> you, that's pretty much the whole purpose of Bitcoin's design. Undermining
> that security model is problematic.
That's a nice sentiment, but there's a lot more nuance to it than
"soft-forks are bad"
We're talking about rejection here: you don't want to end up on an
isolated chain fork wondering if maybe miners have been unlucky. You
want to know that a longer chain exists so as to have solid evidence
that you're local configuration isn't what miners are mining. Thus not
only should you "accept" blocks with versions you don't know about, you
should relay those blocks as well so that other out-of-date nodes have
the highest possible chance of finding out about them. Creating a block
is expensive, so with some minor safeguards - a high minimum difficulty,
and maximum size - relaying blocks you consider invalid is perfectly
safe and doesn't enable DoS attacks. Relaying block headers has similar
logic, and even less DoS attack worry. (don't apply bloom filters to
invalid blocks though!)
I had this discussion with Warren the other day actually: Litecoin is
considering banning old node versions and rejecting their attempts to
connect. I pointed out how you wanted to be damn sure there was no-one
mining with them, least you wind up creating a slowly growing fork mined
by nodes unaware of the main chain.
Soft-forks and SPV nodes is another topic. SPV nodes don't do any
meaningful validation - they usually don't even have the transaction
inputs spent by a transaction to determine if a scriptSig is valid.
Their security is already dependent on miners, so allowing those miners
to upgrade does no harm. In addition there are even cases where what
would be a hard-fork for a full node, is a soft-fork for a SPV node. On
the other hand if your "SPV" node is more sophisticated, then by all
means use a nVersion change to trigger an alert to the user. If you're
implementation relays blockchain data, continue doing so to ensure other
nodes find out about the new version as soon as possible. (all SPV nodes
should relay block headers if possible)
Note how the nVersion field is useful for voting: the "chain height in
coinbase" soft-fork was accomplished this way, changing nVersion from 1
to 2 with full enforcement of the rule triggered by a 95% supermajority.
Bitcoin is a decentralized system, so any changes need to be done by
voting to show that a clear consensus of hashing power will enforce and
validate the new rules. (time and height deadlines can be disasters if
the upgrade is ever ignored or delayed)
Interestingly this suggests that what we actually want is two nVersions
per upgrade: the first to signal that nodes wish to upgrade, and are
showing their intent to use the new rules. The second to signal that the
upgrade has actually happened and the old rules are now ignored. Client
software can use this two stage approach to know when rules may have
changed, and the user probably should consider upgrading. As applied to
the chain height upgrade we would have gone from version 2 during the
voting, to version 3 for any block produced while the rules were in
effect. Put another way, the last in nVersion is simply to signify that
the new blockchain rules are now active, as opposed to being proposed.
--=20
'peter'[:-1]@petertodd.org
000000000000000180dabf823b09a30b4f2032b5cab7ba1d0351cab350bee91f
--VS++wcV0S1rZb1Fb
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
iQEcBAEBCAAGBQJSb+O5AAoJEBmcgzuo5/CFSFMIALH6Ouh20Dj0e4hpKvY/MF7I
3ZKfRslfVmyw6ak03D1FD1yPPknbfqwavzA8zpIGlfxmXvT6OP803MsoLA+78Tks
pP1Stpj3r/bKCGYSmfXrX2QwClgjkwJ0QgATLThDg3ZDWCk4oxzYUhiUYWE85hxE
qQeL7Sfn+GYtCcTARQQzRxGCZLnrmu7lZcSNR5dO556oJjE33TUH08qMrCJpcNF0
tT7gxfTkGc86ZMUzGguddfIKBzh5HoQaSNJv/knQMAcwxFFxoZs+UAJeu0RDHNA6
MZapymKcLfRvREJDWloojBGOCbmwLKd2Q8oyn4nYT7u6Tw7Dwh4I6zyxIn/wwp4=
=DZRm
-----END PGP SIGNATURE-----
--VS++wcV0S1rZb1Fb--
|
