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
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
|
Return-Path: <hampus.sjoberg@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id B07B6CB5
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 13 Jul 2017 22:50:35 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qt0-f195.google.com (mail-qt0-f195.google.com
[209.85.216.195])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D8392142
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 13 Jul 2017 22:50:33 +0000 (UTC)
Received: by mail-qt0-f195.google.com with SMTP id v31so7948992qtb.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 13 Jul 2017 15:50:33 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to;
bh=msQLJpnu6vLSib4g0UY3YAUeOpOj4FjxBGzWBnGz1wk=;
b=tdKGVrZ77u4zxRf/7u4SaksRXUQFq7f8waPwOY5seUXSCOo1wQixEM6JC0BYQpUw0j
+LPf3pV0ixezI2nBy7m1F/1OURZx98mpVljFgJfVIlt5LMxoE7YICNHLX8ugB39ZQ5Mp
gXJlJX49or56Yv+FvQC6QrWKgOucXQ+vIkr8sJ8Btl9LFQNiapCICfopqYGP1FLN1vLo
36+QeuL9h+eGGDsQpIz3rbSfBvI/ewx9czi5ZQshNSlKykcKttBC57rqQEWoNQoPGZyd
Sm0jhbQiYphkQGhbEe7Ary1q8G4LFfuBAe29RVh/wMx4tM8d3MC/aBwrkpJH+V8EGXKH
/dDA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to;
bh=msQLJpnu6vLSib4g0UY3YAUeOpOj4FjxBGzWBnGz1wk=;
b=J0oLbQFHhQ4BUY/MIsNE3rYsZpQ3ChdShcSlyL4mEZtvAhR6p7CH15O8qRGIur6Kmq
9O4w4mYhzHPbbP/qYMjVXiUij1ACnE0xXtT6aARB8x0W7nXZyFjIr58rpzSMUyr2WOmW
6RpMj0rRxirtfQAr0T8I1eK8DVAELAzp68syJEu8tR56x8YvqiXKXfVDUvqHW2AymfND
HUqLZfVheGouwyA1c/xjlD6NHxKdEAPA57VjSjbROoTuP9hBJ+wEY3C5VyTPY3K9faxY
PnS31l8oISSbOfINvwgnaHa26fQHajsODD2Ob2hT4Qdp3xJZgScby/hY67ONRGdwFIpl
ZfTA==
X-Gm-Message-State: AIVw112UY9h9yLLQx/I/NZXzskfrqfwSUTLtevWHUONiF+lbHDO+Cozu
dXmKnJb74DB+AI/FzFik35Aa5tv5F+i+m3Aouw==
X-Received: by 10.200.51.23 with SMTP id t23mr8761374qta.38.1499986232999;
Thu, 13 Jul 2017 15:50:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.12.186.175 with HTTP; Thu, 13 Jul 2017 15:50:32 -0700 (PDT)
In-Reply-To: <4921ce4f-06bc-8ff1-4e70-5bd55d1ff5ca@osc.co.cr>
References: <0119661e-a11a-6d4b-c9ec-fd510bd4f144@gmail.com>
<CAAS2fgRDVgdMYZo776iLwbm23aGNDWL85YgD=yF=M-0_vqJ5nQ@mail.gmail.com>
<1c1d06a9-2e9f-5b2d-42b7-d908ada4b09e@gmail.com>
<CAAS2fgTsjfMGw6D_OxDthSrrdLEFx2skGedLAjTwz3yCQijyug@mail.gmail.com>
<001b20f2-1f33-3484-8ad2-1420ae1a2df5@gmail.com>
<CAAS2fgR3FQ-wSwGwK6PDD_nZKpnBDAtM=5-fvR-smDa48xjW4Q@mail.gmail.com>
<03cf3326-ae84-96f9-5eee-158054341eff@osc.co.cr>
<CAAS2fgR1aGOpVoLyGWtO=Q5XU04gBMBEQARPtxMe4WnwQ2CO5w@mail.gmail.com>
<CAP=-fx6hju0NAa-HcYzivwNbJH0HXwUL=t7iD38XAK_Fwodjng@mail.gmail.com>
<CAFMkqK9+pvRRtcOomo6is5t8xQ2gLmGb7XaGV80TOm-eO6ZoqA@mail.gmail.com>
<0be972b9-328c-394a-1e90-bd7a37642598@osc.co.cr>
<CADL_X_cZc4K3k=JzVES7Jba6qqZwv0Lx7opCi8eL_GM5M01Y8A@mail.gmail.com>
<4921ce4f-06bc-8ff1-4e70-5bd55d1ff5ca@osc.co.cr>
From: =?UTF-8?Q?Hampus_Sj=C3=B6berg?= <hampus.sjoberg@gmail.com>
Date: Fri, 14 Jul 2017 00:50:32 +0200
Message-ID: <CAFMkqK-s=Xtg_40dMY7B3ecbOsjtcekHa6qFn2h8dVhuUMv=pw@mail.gmail.com>
To: Dan Libby <dan@osc.co.cr>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="001a114109f09603fe05543ac2b0"
X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
RCVD_IN_DNSWL_NONE,
RCVD_IN_SORBS_SPAM autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Thu, 13 Jul 2017 23:35:25 +0000
Subject: Re: [bitcoin-dev] how to disable segwit in my build?
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: Thu, 13 Jul 2017 22:50:35 -0000
--001a114109f09603fe05543ac2b0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
> I would like to understand it a bit better, as I think it applies
equally to any pre-segwit node, yes? So let's say I am running 0.13.0
and someone sends me bitcoins to a P2PKH address, but that person
previously received them to a P2WPKH address.
Yes, this applies to all non-SegWit nodes.
> If I understand correctly, my node will accept the incoming tx inputs
but obviously will not perform any segwit related validation, thus those
inputs are not fully validated.
Yes.
So you have two choices to be fully secure:
1. Validate using the new rules of the network (in other words, run a
SegWit node)
2. Avoid any chain of transaction that contains a SegWit transaction
> I don't yet understand how my node
thinks they are valid at all given that it does not understand P2WPKH
address format, so either it doesn't need to, or P2WPKH is somehow
already valid.
So how softforks often work is that you make the transaction appear to be
always spendable for old nodes, regardless if it really was spendable or
not. This will make sure it is a softfork, the update is backwards
compatible.
If it would be the other way around, if new rules that the node doesn't
understand would always be invalid, it would be hardfork, which is what
we're trying to avoid in the first place.
> so if
someone can point me towards a document that explains it I'd be happy to
read that.
See
https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#Backward_com=
patibility
So the witness program is encoded in a new format that old nodes do not
understand.
This means that for old nodes, a number >0 will be put on the stack. When
the script is done, it will be evaluated to true (because of >0) and be
counted as a valid spend.
https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki also
explains the new witness program more in detail (I left out some details in
my explanation).
Cheers
Hampus
2017-07-13 23:58 GMT+02:00 Dan Libby via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org>:
> On 07/13/2017 09:35 AM, Jameson Lopp wrote:
> >
> >
> > On Thu, Jul 13, 2017 at 12:19 PM, Dan Libby via bitcoin-dev
> > <bitcoin-dev@lists.linuxfoundation.org
> > <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
> >
> > On 07/13/2017 06:39 AM, Hampus Sj=C3=B6berg via bitcoin-dev wrote:
> > >> I believe that a good reason not to wish your node to be segwit
> > > compliant is to avoid having to deal with the extra bandwidth tha=
t
> > > segwit could require. Running a 0.14.2 node means being ok with
> >1MB
> > > blocks, in case segwit is activated and widely used. Users not
> > > interested in segwit transactions may prefer to keep the cost of
> their
> > > node lower.
> > >
> > > If the majority of the network decides to deploy SegWit, it would
> be in
> > > your best interest to validate the SegWit transactions, because y=
ou
> > > might will be downgraded to near-SPV node validation.
> > > It would be okay to still run a "non-SegWit" node if there's no
> SegWit
> > > transactions in the chain of transactions for your bitcoins,
> otherwise
> > > you cannot fully verify the the ownership of your bitcoins.
> > > I'm not sure the practicality of this in the long run, but it
> makes a
> > > case for having an up-to-date non-SegWit node, although I think
> it's a
> > > bit of a stretch.
> >
> > Right. Well, if I never upgrade to segwit, then there seems little
> > (zero?) risk of having any segwit tx in my tx chain.
> >
> >
> > If you mean you wish to avoid receiving UTXOs that have value that was
> > at one point previously encumbered by a SegWit output then no, you can'=
t
> > avoid that. No more than you can currently avoid receiving BTC that wer=
e
> > at one point in time encumbered by a P2SH output.
>
> fair enough. This actually wasn't an area I'd considered much before
> Hampus brought it up.
>
> I would like to understand it a bit better, as I think it applies
> equally to any pre-segwit node, yes? So let's say I am running 0.13.0
> and someone sends me bitcoins to a P2PKH address, but that person
> previously received them to a P2WPKH address.
>
> If I understand correctly, my node will accept the incoming tx inputs
> but obviously will not perform any segwit related validation, thus those
> inputs are not fully validated. I don't yet understand how my node
> thinks they are valid at all given that it does not understand P2WPKH
> address format, so either it doesn't need to, or P2WPKH is somehow
> already valid. I know this has all been discussed in the past, so if
> someone can point me towards a document that explains it I'd be happy to
> read that.
>
> thanks!
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--001a114109f09603fe05543ac2b0
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div>> I would like to understand it a bit better,=
as I think it applies<br>
equally to any pre-segwit node, yes?=C2=A0 =C2=A0So let's say I am runn=
ing 0.13.0<br>
and someone sends me bitcoins to a P2PKH address, but that person<br>
previously received them to a P2WPKH address.<br><br></div>Yes, this applie=
s to all non-SegWit nodes.<br><br>> If I understand correctly, my node w=
ill accept the incoming tx inputs<br>
but obviously will not perform any segwit related validation, thus those<br=
>
inputs are not fully validated.<br><br></div><div>Yes.<br></div><div>So you=
have two choices to be fully secure:<br>1. Validate using the new rules of=
the network (in other words, run a SegWit node)<br></div><div>2. Avoid any=
chain of transaction that contains a SegWit transaction<br></div><div><br>=
> I don't yet understand how my node<br>
thinks they are valid at all given that it does not understand P2WPKH<br>
address format, so either it doesn't need to, or P2WPKH is somehow<br>
already valid. <br><br></div><div>So how softforks often work is that you m=
ake the transaction appear to be always spendable for old nodes, regardless=
if it really was spendable or not. This will make sure it is a softfork, t=
he update is backwards compatible.<br></div><div>If it would be the other w=
ay around, if new rules that the node doesn't understand would always b=
e invalid, it would be hardfork, which is what we're trying to avoid in=
the first place.<br><br>> so if<br>
someone can point me towards a document that explains it I'd be happy t=
o<br>
read that.<br><br></div><div>See <a href=3D"https://github.com/bitcoin/bips=
/blob/master/bip-0141.mediawiki#Backward_compatibility">https://github.com/=
bitcoin/bips/blob/master/bip-0141.mediawiki#Backward_compatibility</a><br><=
/div><div>So the witness program is encoded in a new format that old nodes =
do not understand.<br></div><div>This means that for old nodes, a number &g=
t;0 will be put on the stack. When the script is done, it will be evaluated=
to true (because of >0) and be counted as a valid spend.<br></div><div>=
<br><a href=3D"https://github.com/bitcoin/bips/blob/master/bip-0143.mediawi=
ki">https://github.com/bitcoin/bips/blob/master/bip-0143.mediawiki</a> also=
explains the new witness program more in detail (I left out some details i=
n my explanation).<br><br></div><div>Cheers<br></div><div>Hampus<br></div>
</div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">2017-07-13 =
23:58 GMT+02:00 Dan Libby via bitcoin-dev <span dir=3D"ltr"><<a href=3D"=
mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitcoin-dev=
@lists.linuxfoundation.org</a>></span>:<br><blockquote class=3D"gmail_qu=
ote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex=
"><span class=3D"">On 07/13/2017 09:35 AM, Jameson Lopp wrote:<br>
><br>
><br>
> On Thu, Jul 13, 2017 at 12:19 PM, Dan Libby via bitcoin-dev<br>
> <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-d=
ev@lists.<wbr>linuxfoundation.org</a><br>
</span><span class=3D"">> <mailto:<a href=3D"mailto:bitcoin-dev@lists=
.linuxfoundation.org">bitcoin-dev@lists.<wbr>linuxfoundation.org</a>>>=
; wrote:<br>
><br>
>=C2=A0 =C2=A0 =C2=A0On 07/13/2017 06:39 AM, Hampus Sj=C3=B6berg via bit=
coin-dev wrote:<br>
>=C2=A0 =C2=A0 =C2=A0>> I believe that a good reason not to wish y=
our node to be segwit<br>
>=C2=A0 =C2=A0 =C2=A0> compliant is to avoid having to deal with the =
extra bandwidth that<br>
>=C2=A0 =C2=A0 =C2=A0> segwit could require.=C2=A0 =C2=A0Running a 0.=
14.2 node means being ok with >1MB<br>
>=C2=A0 =C2=A0 =C2=A0> blocks, in case segwit is activated and widely=
used. Users not<br>
>=C2=A0 =C2=A0 =C2=A0> interested in segwit transactions may prefer t=
o keep the cost of their<br>
>=C2=A0 =C2=A0 =C2=A0> node lower.<br>
>=C2=A0 =C2=A0 =C2=A0><br>
>=C2=A0 =C2=A0 =C2=A0> If the majority of the network decides to depl=
oy SegWit, it would be in<br>
>=C2=A0 =C2=A0 =C2=A0> your best interest to validate the SegWit tran=
sactions, because you<br>
>=C2=A0 =C2=A0 =C2=A0> might will be downgraded to near-SPV node vali=
dation.<br>
>=C2=A0 =C2=A0 =C2=A0> It would be okay to still run a "non-SegW=
it" node if there's no SegWit<br>
>=C2=A0 =C2=A0 =C2=A0> transactions in the chain of transactions for =
your bitcoins, otherwise<br>
>=C2=A0 =C2=A0 =C2=A0> you cannot fully verify the the ownership of y=
our bitcoins.<br>
>=C2=A0 =C2=A0 =C2=A0> I'm not sure the practicality of this in t=
he long run, but it makes a<br>
>=C2=A0 =C2=A0 =C2=A0> case for having an up-to-date non-SegWit node,=
although I think it's a<br>
>=C2=A0 =C2=A0 =C2=A0> bit of a stretch.<br>
><br>
>=C2=A0 =C2=A0 =C2=A0Right.=C2=A0 Well, if I never upgrade to segwit, th=
en there seems little<br>
>=C2=A0 =C2=A0 =C2=A0(zero?) risk of having any segwit tx in my tx chain=
.<br>
><br>
><br>
> If you mean you wish to avoid receiving UTXOs that have value that was=
<br>
> at one point previously encumbered by a SegWit output then no, you can=
't<br>
> avoid that. No more than you can currently avoid receiving BTC that we=
re<br>
> at one point in time encumbered by a P2SH output.<br>
<br>
</span>fair enough.=C2=A0 This actually wasn't an area I'd consider=
ed much before<br>
Hampus brought it up.<br>
<br>
I would like to understand it a bit better, as I think it applies<br>
equally to any pre-segwit node, yes?=C2=A0 =C2=A0So let's say I am runn=
ing 0.13.0<br>
and someone sends me bitcoins to a P2PKH address, but that person<br>
previously received them to a P2WPKH address.<br>
<br>
If I understand correctly, my node will accept the incoming tx inputs<br>
but obviously will not perform any segwit related validation, thus those<br=
>
inputs are not fully validated.=C2=A0 I don't yet understand how my nod=
e<br>
thinks they are valid at all given that it does not understand P2WPKH<br>
address format, so either it doesn't need to, or P2WPKH is somehow<br>
already valid.=C2=A0 I know this has all been discussed in the past, so if<=
br>
someone can point me towards a document that explains it I'd be happy t=
o<br>
read that.<br>
<br>
thanks!<br>
<div class=3D"HOEnZb"><div class=3D"h5">______________________________<wbr>=
_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
</div></div></blockquote></div><br></div>
--001a114109f09603fe05543ac2b0--
|
