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
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
|
Return-Path: <vincent.truong@procabiak.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id D3247CE3
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 8 Dec 2015 21:02:57 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-io0-f173.google.com (mail-io0-f173.google.com
[209.85.223.173])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2BB8714D
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 8 Dec 2015 21:02:56 +0000 (UTC)
Received: by iofh3 with SMTP id h3so37749611iof.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 08 Dec 2015 13:02:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=procabiak.com; s=procabiakindustries;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=+0GQNFFyCObhDRQj7us7AtVyha2GNHdd4WWCFOAiBWQ=;
b=SX9p+S8FJR3hBTyAN4JQhui82Xup/fcDExpKN2j0sx1VIS4gsxemri4ICWCAaqlHNr
Ow8u5eOfMcio3MK7iltEEm/klxPExdeumltDB0JCy7ccYHcRerqXGXkNl6pk3Oa3eqmR
Z6ir+gKrdOiLf/khwWjFuEN9ULLWTmcAQaTJ8=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:date
:message-id:subject:from:to:cc:content-type;
bh=+0GQNFFyCObhDRQj7us7AtVyha2GNHdd4WWCFOAiBWQ=;
b=IFO14vA5MsyqolD1Nu5QaGsQ9djqEQo9J5E7A7lyirRfj3LGBjw0QYpyOjaMfapiVI
x6OCTUJutdasqpu87RswAd/F1t5JXglJQcNue/llnJobYOpCgZKQWVNVbmCywrinUX8g
LdbTuNIuqxE1VgFrq2ik1pmDhFH8LSE7O1h/Ng6YIdjqdwX0MojiOz/WzDelLr/2faPt
ohSKTCQxq0HPtF7wfw54A471P7+KKvGCuj5u2NerzCAiSjwYzQFctwMsCIJWV45fDYRr
yWxOtdwTzQy+gUtf6n8NW97zz8G8K7SjREaXkoj6TFcdIPlxYiQpOji47RLWG3ywt+Pw
ev5w==
X-Gm-Message-State: ALoCoQlUZQ6DQj+3yaA6X1AOPSBtXBMkzx1BgindfWnMqYgkE2K488ZnZ5XflEgvEXLzLG+JNxigNVlwtjV5bEmHdUaBfC+acQ==
MIME-Version: 1.0
X-Received: by 10.107.133.101 with SMTP id h98mr1958965iod.16.1449608575596;
Tue, 08 Dec 2015 13:02:55 -0800 (PST)
Received: by 10.36.129.10 with HTTP; Tue, 8 Dec 2015 13:02:55 -0800 (PST)
X-Originating-IP: [1.152.96.96]
Received: by 10.36.129.10 with HTTP; Tue, 8 Dec 2015 13:02:55 -0800 (PST)
In-Reply-To: <CAAcC9ysviyCaajpwZezzLnPhVVeFxgTKNfFuH6o-CyXNFNBHbA@mail.gmail.com>
References: <CACrzPenvAWdkgRG3Y7P31JiNEVRYvd+f1nMp=QRhAp5P_eGRow@mail.gmail.com>
<CAAcC9ysviyCaajpwZezzLnPhVVeFxgTKNfFuH6o-CyXNFNBHbA@mail.gmail.com>
Date: Wed, 9 Dec 2015 08:02:55 +1100
Message-ID: <CACrzPenQadaNMNgnN_1fv5tqspRDtGUgzEmGsDtjMOdjWedZjQ@mail.gmail.com>
From: Vincent Truong <vincent.truong@procabiak.com>
To: Chris Priest <cp368202@ohiou.edu>
Content-Type: multipart/alternative; boundary=001a113ff85a3651a40526694cb6
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,HTML_MESSAGE,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
X-Mailman-Approved-At: Tue, 08 Dec 2015 21:10:03 +0000
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP 9 style version bits for txns
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: Tue, 08 Dec 2015 21:02:57 -0000
--001a113ff85a3651a40526694cb6
Content-Type: text/plain; charset=UTF-8
I suppose whether the wallet devs want to implement the soft fork or not is
irrelevant. They only need to indicate if they are ready i.e. they've
tested the new soft fork, hard fork or feature and validated that it
doesn't break their nodes or wallet software.
On Dec 9, 2015 6:40 AM, "Chris Priest" <cp368202@ohiou.edu> wrote:
> I proposed in my Wildcard Inputs BIP that the version field be split
> in two. The first 4 bytes are version number (which in practice is
> being used for script version), and the second 4 bits are used for
> transaction type.
>
> I don't think the BIP9 mechanism really applies to transactions. A
> block is essentially a collection of transactions, therefore voting on
> the block applies to the many parties who have transactions in the
> block. A transaction on the other hand only effects at most two
> parties (the sender and the receiver). In other words, block are
> "communal" data structures, transactions are individual data
> structures. Also, the nature of soft forks are that wallets can choose
> to implement a new feature or not. For instance, if no wallets
> implement RBF or SW, then those features effectively don't exist,
> regardless of how many nodes have upgraded to handle the feature.
>
> Any new transaction feature should get a new "type" number. A new
> transaction feature can't happen until the nodes support it.
>
> On 12/8/15, Vincent Truong via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > So I have been told more than once that the version announcement in
> blocks
> > is not a vote, but a signal for readiness, used in isSupermajority().
> > Basically, if soft forks (and hard forks) won't activate unless a
> certain %
> > of blocks have been flagged with the version up (or bit flipped when
> > versionbits go live) to signal their readiness, that is a vote against
> > implementation if they never follow up. I don't like this politically
> > correct speech because in reality it is a vote... But I'm not here to
> argue
> > about that... I would like to see if there are any thoughts on
> > extending/copying isSupermajority() for a new secondary/non-critical
> > function to also look for a similar BIP 9 style version bit in txns.
> > Apologies if already proposed, haven't heard of it anywhere.
> >
> > If we are looking for a signal of readiness, it is unfair to wallet
> > developers and exchanges that they are unable to signal if they too are
> > ready for a change. As more users are going into use SPV or SPV-like
> > wallets, when a change occurs that makes them incompatible/in need of
> > upgrade we need to make sure they aren't going to break or introduce
> > security flaws for users.
> >
> > If a majority of transactions have been sent are flagged ready, we know
> > that they're also good to go.
> >
> > Would you implement the same versionbits for txn's version field, using 3
> > bits for versioning and 29 bits for flags? This indexing of every txn
> might
> > sound insane and computationally expensive for bitcoin Core to run, but
> if
> > it isn't critical to upgrade with soft forks, then it can be watched
> > outside the network by enthusiasts. I believe this is the most
> politically
> > correct way to get wallet devs and exchanges involved. (If it were me I
> > would absolutely try figure out a way to stick it in isSupermajority...)
> >
> > Miners can watch for readiness flagged by wallets before they themselves
> > flag ready. We will have to trust miners to not jump the gun, but that's
> > the trade off.
> >
> > Thoughts?
> >
>
--001a113ff85a3651a40526694cb6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">I suppose whether the wallet devs want to implement the soft=
fork or not is irrelevant. They only need to indicate if they are ready i.=
e. they've tested the new soft fork, hard fork or feature and validated=
that it doesn't break their nodes or wallet software.</p>
<div class=3D"gmail_quote">On Dec 9, 2015 6:40 AM, "Chris Priest"=
<<a href=3D"mailto:cp368202@ohiou.edu">cp368202@ohiou.edu</a>> wrote=
:<br type=3D"attribution"><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I proposed in my W=
ildcard Inputs BIP that the version field be split<br>
in two. The first 4 bytes are version number (which in practice is<br>
being used for script version), and the second 4 bits are used for<br>
transaction type.<br>
<br>
I don't think the BIP9 mechanism really applies to transactions. A<br>
block is essentially a collection of transactions, therefore voting on<br>
the block applies to the many parties who have transactions in the<br>
block. A transaction on the other hand only effects at most two<br>
parties (the sender and the receiver). In other words, block are<br>
"communal" data structures, transactions are individual data<br>
structures. Also, the nature of soft forks are that wallets can choose<br>
to implement a new feature or not. For instance, if no wallets<br>
implement RBF or SW, then those features effectively don't exist,<br>
regardless of how many nodes have upgraded to handle the feature.<br>
<br>
Any new transaction feature should get a new "type" number. A new=
<br>
transaction feature can't happen until the nodes support it.<br>
<br>
On 12/8/15, Vincent Truong via bitcoin-dev<br>
<<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@li=
sts.linuxfoundation.org</a>> wrote:<br>
> So I have been told more than once that the version announcement in bl=
ocks<br>
> is not a vote, but a signal for readiness, used in isSupermajority().<=
br>
> Basically, if soft forks (and hard forks) won't activate unless a =
certain %<br>
> of blocks have been flagged with the version up (or bit flipped when<b=
r>
> versionbits go live) to signal their readiness, that is a vote against=
<br>
> implementation if they never follow up. I don't like this politica=
lly<br>
> correct speech because in reality it is a vote... But I'm not here=
to argue<br>
> about that... I would like to see if there are any thoughts on<br>
> extending/copying isSupermajority() for a new secondary/non-critical<b=
r>
> function to also look for a similar BIP 9 style version bit in txns.<b=
r>
> Apologies if already proposed, haven't heard of it anywhere.<br>
><br>
> If we are looking for a signal of readiness, it is unfair to wallet<br=
>
> developers and exchanges that they are unable to signal if they too ar=
e<br>
> ready for a change. As more users are going into use SPV or SPV-like<b=
r>
> wallets, when a change occurs that makes them incompatible/in need of<=
br>
> upgrade we need to make sure they aren't going to break or introdu=
ce<br>
> security flaws for users.<br>
><br>
> If a majority of transactions have been sent are flagged ready, we kno=
w<br>
> that they're also good to go.<br>
><br>
> Would you implement the same versionbits for txn's version field, =
using 3<br>
> bits for versioning and 29 bits for flags? This indexing of every txn =
might<br>
> sound insane and computationally expensive for bitcoin Core to run, bu=
t if<br>
> it isn't critical to upgrade with soft forks, then it can be watch=
ed<br>
> outside the network by enthusiasts. I believe this is the most politic=
ally<br>
> correct way to get wallet devs and exchanges involved. (If it were me =
I<br>
> would absolutely try figure out a way to stick it in isSupermajority..=
.)<br>
><br>
> Miners can watch for readiness flagged by wallets before they themselv=
es<br>
> flag ready. We will have to trust miners to not jump the gun, but that=
's<br>
> the trade off.<br>
><br>
> Thoughts?<br>
><br>
</blockquote></div>
--001a113ff85a3651a40526694cb6--
|