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
|
Return-Path: <tier.nolan@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 2D646BFB
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 14 Jul 2017 09:04:41 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-oi0-f66.google.com (mail-oi0-f66.google.com
[209.85.218.66])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1C3F4FF
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 14 Jul 2017 09:04:40 +0000 (UTC)
Received: by mail-oi0-f66.google.com with SMTP id n2so9571963oig.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 14 Jul 2017 02:04:40 -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=pUDEyIP30H+KZ/ELLjoY7w3ls6FdG8aBn2LTfY/eykI=;
b=nnIA/TZKfBdBZUvTZr4Jg6KMjA/tpoFaCljvgvrvdkBXMeq6aNxzE5OxGFd3zlOhvS
aiNzG3RlISizr9rpjcpCQLTxWFaGBvm4vfy99AY1BHH2EAj+c28pvQMutDBNEfFA/2kq
X6cVK3UuceIq5UyG6JZ6s4sQQL6tJ202kVn9qbVgOS3nXQLwDE3PMQabJZ0rjd+qX/mF
ati5/OqLNxhvSCY1sirIrvzvkFf+59RV6V4fdbpSYDbLGYAXiWemD4OFKbQ8qv6mkXN/
vhPjFdYsHC9kledxtp+lSAp002XiB4s+ZQZTrQ1i5Gyjht4HouHogCU2P+pYaQUA/cRe
/SBw==
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=pUDEyIP30H+KZ/ELLjoY7w3ls6FdG8aBn2LTfY/eykI=;
b=jtOjgyy72Ks9FeczlA82EAqBBFa7WqaHB2UPOkVcNSMSLzRRl7UCTdh+MJrD1BdEzt
DfpG6lyeIaZgMcXETw+mInDgKzZs8OF0MJc9W+XBKgf2eI8IXxcEz77UEgIz/tigTqgS
GuK6tpnM58gMvGhuQ4mrNVa+o7kj3FeEaIUYjdFBuT58i43AqXFV1EkEsC/73gAs+alk
YwMgIK4JBUxuqi7xETKfP3jfbmt0z19hRyQ+J71tWyXG1D0fhEhD4voYxxuXeEJK1Znt
7XY3o+toj05gzowelbCsBeih9AvHbUlbeMeqfk+g+XqTnn8G79cT9gFu5wHjcIZetlFP
XDaA==
X-Gm-Message-State: AIVw110URfgiLdFCdvUKwMmzEl9Qm2FqWUbRZbPUCubUzFhzWjqvnKSJ
Yn+RdRiix0xcEePVkwwYGn/cNxc5fbEp
X-Received: by 10.202.76.214 with SMTP id z205mr4643159oia.215.1500023078995;
Fri, 14 Jul 2017 02:04:38 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.74.170.203 with HTTP; Fri, 14 Jul 2017 02:03:58 -0700 (PDT)
In-Reply-To: <5af10ca3-8b97-f227-c09f-901bbb6176c3@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>
<CAFMkqK-s=Xtg_40dMY7B3ecbOsjtcekHa6qFn2h8dVhuUMv=pw@mail.gmail.com>
<5af10ca3-8b97-f227-c09f-901bbb6176c3@osc.co.cr>
From: Tier Nolan <tier.nolan@gmail.com>
Date: Fri, 14 Jul 2017 10:03:58 +0100
Message-ID: <CAE-z3OUdfgpfe30gTp8ptqxgpyLYys+feGA3Cx98d3z9gFtQdw@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="001a11c17df4c74d6b05544356c3"
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: Fri, 14 Jul 2017 11:54:09 +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: Fri, 14 Jul 2017 09:04:41 -0000
--001a11c17df4c74d6b05544356c3
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
On Fri, Jul 14, 2017 at 12:20 AM, Dan Libby via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On 07/13/2017 03:50 PM, Hampus Sj=C3=B6berg wrote:
> > 2. Avoid any chain of transaction that contains a SegWit transaction
>
> sounds good, though I'm unclear on how exactly to achieve (2) given that
> any party I have ever transacted with (or otherwise knows an address of
> mine) can send me coins at any time. So it seems the only possible way
> to be certain is to run a node that has never published an address to a
> 3rd party. Is that accurate?
>
You would also have to ensure that everyone you give your addresses to
follows the same rule. As time passes, there would be fewer and fewer
people who have "clean" outputs.
From the perspective of old nodes, segwit looks like lots of people are
transferring money to "anyone-can-spend" outputs. This outputs are
completely unprotected. Literally, anyone can spend them. (In practice,
miners would spend them, since why would they include a transaction that
sends "free money" to someone else).
If you run an old node, then someone could send you a transaction that only
spends segwit outputs and you would think it is a valid payment.
Imagine that there are only 3 UTXOs (Alice, Bob and Carl have all the
Bitcoins).
UTXO-1: Requires signature by Alice (legacy output)
UTXO-2: Anyone can pay (but is actually a segwit output that needs to be
signed by Bob)
UTXO-3: Anyone can pay (but is actually a segwit output that needs to be
signed by Carl)
Only Bob can spend UTXO-2, since it needs his signature.
Anyone could create a transaction that spends UTXO-2 and it would look good
to all legacy nodes. It is an "anyone can spend" output after all.
However, if they submit the transaction to the miners, then it will be
rejected, because according to the new rules, it is invalid (it needs to be
signed by Bob).
Once a soft fork goes through, then all miners will enforce the new rules.
A miner who added the transaction to one of his blocks (since it is valid
under the old rules) would find that no other miners would accept his block
and he would get no fees for that block. This means that all miners have
an incentive to upgrade once a soft fork activates.
His block would be accepted by legacy nodes, for a short while. However,
since 95% of the miners are on the main chain, their chain (which rejects
his block) would end up the longest.
If you are running a legacy client when a soft fork comes in, then you can
be tricked with "zero confirm" transactions. The transaction will look
good to you, but will be invalid under the new rules. This makes your
client think you have received (a lot of) money, but in practice, the
transaction will not be accepted by the miners.
> Another thing that could be done is to modify my own node so that it
> actually rejects such tx, but then I have modified consensus rules
> myself, thus defeating the goal of remaining with status-quo rules, and
> anyway the rest of the network would accept the tx. I guess the benefit
> is that I could be certain of the remaining funds I have.
>
If you wanted, you could mark any transaction that has a segwit looking
output as "dirty" and then all of its descendants as dirty.
However, pretty quickly, only a tiny fraction of all bitcoins would be
clean.
I suppose that it would be possible without modifying any rule to
> construct a "certain balance" and an "uncertain balance".
>
Right.
I think a reasonably compromise would be to assume that all transactions
buried more than a few hundred blocks deep are probably ok. Only segwit
looking outputs would be marked as "uncertain".
--001a11c17df4c74d6b05544356c3
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Fri, Jul 14, 2017 at 12:20 AM, Dan Libby via bitcoin-dev <span dir=
=3D"ltr"><<a target=3D"_blank" href=3D"mailto:bitcoin-dev@lists.linuxfou=
ndation.org">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<br=
><blockquote style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(20=
4,204,204);padding-left:1ex" class=3D"gmail_quote"><span class=3D"gmail-">O=
n 07/13/2017 03:50 PM, Hampus Sj=C3=B6berg wrote:<br>
> 2. Avoid any chain of transaction that contains a SegWit transaction<b=
r>
<br>
</span>sounds good, though I'm unclear on how exactly to achieve (2) gi=
ven that<br>
any party I have ever transacted with (or otherwise knows an address of<br>
mine) can send me coins at any time.=C2=A0 So it seems the only possible wa=
y<br>
to be certain is to run a node that has never published an address to a<br>
3rd party.=C2=A0 Is that accurate?<br></blockquote><div><br></div><div>You =
would also have to ensure that everyone you give your addresses to follows =
the same rule.=C2=A0 As time passes, there would be fewer and fewer people =
who have "clean" outputs.<br><br></div><div>From the perspective =
of old nodes, segwit looks like lots of people are transferring money to &q=
uot;anyone-can-spend" outputs.=C2=A0 This outputs are completely unpro=
tected.=C2=A0 Literally, anyone can spend them.=C2=A0 (In practice, miners =
would spend them, since why would they include a transaction that sends &qu=
ot;free money" to someone else).<br><br></div><div>If you run an old n=
ode, then someone could send you a transaction that only spends segwit outp=
uts and you would think it is a valid payment.<br><br></div><div>Imagine th=
at there are only 3 UTXOs (Alice, Bob and Carl have all the Bitcoins).=C2=
=A0 <br></div><div><br></div><div>UTXO-1:=C2=A0 Requires signature by Alice=
(legacy output)<br><br></div><div>UTXO-2: Anyone can pay (but is actually =
a segwit output that needs to be signed by Bob)<br><br></div><div>UTXO-3: A=
nyone can pay (but is actually a segwit output that needs to be signed by C=
arl)</div><div><br></div><div>Only Bob can spend UTXO-2, since it needs his=
signature.<br><br></div><div>Anyone could create a transaction that spends=
UTXO-2 and it would look good to all legacy nodes.=C2=A0 It is an "an=
yone can spend" output after all.<br><br></div><div>However, if they s=
ubmit the transaction to the miners, then it will be rejected, because acco=
rding to the new rules, it is invalid (it needs to be signed by Bob).=C2=A0=
<br><br>Once a soft fork goes through, then all miners will enforce the ne=
w rules.<br><br></div><div>A miner who added the transaction to one of his =
blocks (since it is valid under the old rules) would find that no other min=
ers would accept his block and he would get no fees for that block.=C2=A0 T=
his means that all miners have an incentive to upgrade once a soft fork act=
ivates.<br></div><div><br></div><div>His block would be accepted by legacy =
nodes, for a short while.=C2=A0 However, since 95% of the miners are on the=
main chain, their chain (which rejects his block) would end up the longest=
.<br><br></div><div>If you are running a legacy client when a soft fork com=
es in, then you can be tricked with "zero confirm" transactions.=
=C2=A0 The transaction will look good to you, but will be invalid under the=
new rules.=C2=A0 This makes your client think you have received (a lot of)=
money, but in practice, the transaction will not be accepted by the miners=
.<br><br></div><div></div><blockquote style=3D"margin:0px 0px 0px 0.8ex;bor=
der-left:1px solid rgb(204,204,204);padding-left:1ex" class=3D"gmail_quote"=
>
<br>
Another thing that could be done is to modify my own node so that it<br>
actually rejects such tx, but then I have modified consensus rules<br>
myself, thus defeating the goal of remaining with status-quo rules, and<br>
anyway the rest of the network would accept the tx.=C2=A0 I guess the benef=
it<br>
is that I could be certain of the remaining funds I have.<br></blockquote><=
div><br></div><div>If you wanted, you could mark any transaction that has a=
segwit looking output as "dirty" and then all of its descendants=
as dirty.<br><br></div><div>However, pretty quickly, only a tiny fraction =
of all bitcoins would be clean.<br></div><div><br></div><blockquote style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex" class=3D"gmail_quote">
I suppose that it would be possible without modifying any rule to<br>
construct a "certain balance" and an "uncertain balance"=
;.<br></blockquote><div><br></div><div>Right.<br><br></div><div>I think a r=
easonably compromise would be to assume that all transactions buried more t=
han a few hundred blocks deep are probably ok.=C2=A0 Only segwit looking ou=
tputs would be marked as "uncertain".<br></div></div></div></div>
--001a11c17df4c74d6b05544356c3--
|
