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
|
Return-Path: <dscotese@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 505A6BFA
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 24 Sep 2016 00:08:27 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-vk0-f44.google.com (mail-vk0-f44.google.com
[209.85.213.44])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1E8DC7D
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 24 Sep 2016 00:08:26 +0000 (UTC)
Received: by mail-vk0-f44.google.com with SMTP id z126so4283688vkd.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 23 Sep 2016 17:08:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:sender:in-reply-to:references:from:date:message-id
:subject:to:cc;
bh=DGIdQa9YyEcc6MsgDA5mAzqsc1HpaJx3iRt+HfDu8QM=;
b=roN+Ggd4Dg2EBGWipFtIUOb8bXjfmYX9iP3S1UteY9C6GxwWlqJiIBoU1lJ+Ly4p5T
9TD3jxu7FsVbiA0jeokGOiEfT+qQ9NUThYCD78PmH2K6kGlW+pumgQIYl7/guMAXdCtD
XErJZ21Ml2kep+AH51N4/l1CnOWvIZeqGQlOv2ENRSLfffRd//uRwe4SMjcegEe44qx7
BZiO7nP/zpPQMfZAVoabhOkpa4LuvgzRI0avzfrQrnAhuu/V+pNh6FVoGMyvPk26GjlH
Ha5J6mgsag+xgI4yWWsfGgkJCKtYZ3jGyYn9pxlTPWF75ZaTV+uq2BCMDM2TOSOzb+LQ
BmCQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:sender:in-reply-to:references:from
:date:message-id:subject:to:cc;
bh=DGIdQa9YyEcc6MsgDA5mAzqsc1HpaJx3iRt+HfDu8QM=;
b=awS5fhYPNP/w6R0JP1Edyx2xIc2x5ASqijYo/kw2t1vw3np8OjzM42x9y0AMKawZaB
3JmcT7xYDXNBqqgh/1RczLY9Nn5cNkYgdrGDUwjFvpkGWWW1n3ZgCRjD5N4orIHWoF0C
tDwKMKlPWM6zbNtILZltR+YDR5bGHV2psTHINzAPL+kcUoxi9rh6jkAdYNXJ/RDwAQ6W
tFxCBB2Lm6UR5kDfsDLDduyilmLGxTO2o1UHiovLm28vy769PuQeSd33xvxeqmQWGjX7
un1kx+VOKg1sjSkZB398Z83UCLT29EhQvLlVz/P1+YjB+p2k1LsJ09mrSySqekDK6NJO
iILw==
X-Gm-Message-State: AA6/9RkVu/PtYEAEJigtI0XoIGb4M10rjVIYc7sO1EHyJqTh6mlhm0x4C9DCkzWRs/2xMekO5ylPmwgqlqcV/w==
X-Received: by 10.31.163.134 with SMTP id m128mr731593vke.70.1474675705229;
Fri, 23 Sep 2016 17:08:25 -0700 (PDT)
MIME-Version: 1.0
Sender: dscotese@gmail.com
Received: by 10.176.1.168 with HTTP; Fri, 23 Sep 2016 17:08:24 -0700 (PDT)
In-Reply-To: <201609232234.43689.luke@dashjr.org>
References: <201609230957.03138.luke@dashjr.org> <2403444.9CSRyRIcH2@garp>
<201609232234.43689.luke@dashjr.org>
From: Dave Scotese <dscotese@litmocracy.com>
Date: Fri, 23 Sep 2016 17:08:24 -0700
X-Google-Sender-Auth: Vy-5RntO6ei0AfSuX1rVNWxj0eA
Message-ID: <CAGLBAhc3cSuKS6mszE-ygETChdoS5MXO4YePkHx4-AC2wGgQ_A@mail.gmail.com>
To: Luke Dashjr <luke@dashjr.org>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a1142d3c491b81c053d35b167
X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, 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
Subject: Re: [bitcoin-dev] BIP draft: OP_CHECKBLOCKATHEIGHT
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: Sat, 24 Sep 2016 00:08:27 -0000
--001a1142d3c491b81c053d35b167
Content-Type: text/plain; charset=UTF-8
If Alice knows enough to see that she needs CHECKBLOCKATHEIGHT to avoid
paying Bob twice, then she also knows that Fred owes her 4BTC. If Bob
complains about getting paid faster, Alice can let him know that Fred
essentially stole his coins and that when she is certain he (and she) can't
get them back, she will send a different four coins to Bob. If she can
establish trust with Bob (She'd trust Bob to pay her back if he gets back
the coins Fred stole), then she can pay him again. Bob could also make a
transaction to send the first input from Alice back to her (since he
doesn't have those coins anyway), sign it, and send that to her. She can
then keep it instead of having to use the new opcode.
Or she can let her wallet use the new opcode so that the logic is built in,
if we add this opcode. Wallet makers who want to help solve this problem
can either implement the new opcode, or they can offer people like Bob the
ability to refund orphaned transactions so that they can be duplicated in
the valid chain without any risk to the original sender.
With the opcode, Alice can solve the problem by herself. Without it, Bob
can solve it for Alice.
While the opcode adds complexity, it enables victims of double-spends to
pay untrusted creditors (Bob) without the risk that orphaned chains create
of paying them twice. I'm not sure the added complexity is worth the
reward. The reward is to protect Bitcoiners (Alice) from people we'd call
"untrusted creditors" (Bob) and I think that might be a mistake. Getting a
refund transaction signed and sent back to Alice is similar to how the LN
will work (where wallets hold transactions that they don't broadcast).
Am I understanding this correctly?
On Fri, Sep 23, 2016 at 3:34 PM, Luke Dashjr via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Joe sends Alice 5 BTC (UTXO 0).
> Fred sends Alice 4 BTC (UTXO 1).
> Alice sends Bob 4 BTC using UTXO 1 (creating UTXO 2).
> Fred double-spends UTXO 1 with UTXO 1-B. This invalidates Alice's transfer
> to
> Bob.
> Alice has UTXO 0 which she can send to Bob (UTXO 3), but if she does so,
> it is
> possible that UTXO 0 could be mined, and then both UTXO 2 and UTXO 3 which
> would result in her giving Bob a total of 8 BTC rather than merely 4 BTC.
> Even if Alice waits until Fred's UTXO 1-B confirms 10 blocks deep, it is
> not
> impossible for a reorganization to reverse those 10 blocks and confirm
> UTXO 1
> again.
> Using OP_CHECKBLOCKATHEIGHT, however, Alice can create UTXO 3 such that it
> is
> valid only in the blockchain where Fred's UTXO 1-B has confirmed. This
> way, if
> that block is reorganized out, UTXO 3 is invalid, and either Bob receives
> only
> the original UTXO 2, or Alice can create a UTXO 3-B which is valid in the
> reorganized blockchain if it again confirms the UTXO 1-B double-spend.
>
> Luke
>
> On Friday, September 23, 2016 2:37:39 PM Tom via bitcoin-dev wrote:
> > On Friday 23 Sep 2016 09:57:01 Luke Dashjr via bitcoin-dev wrote:
> > > This BIP describes a new opcode (OP_CHECKBLOCKATHEIGHT) for the Bitcoin
> > > scripting system to address reissuing bitcoin transactions when the
> coins
> > > they spend have been conflicted/double-spent.
> > >
> > > https://github.com/luke-jr/bips/blob/bip-cbah/bip-cbah.mediawiki
> >
> > Can you walk us through a real live usecase which this solves? I read it
> > and I think I understand it, but I can't see the attack every giving the
> > attacker any benefit (or the attacked losing anything).
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto
--001a1142d3c491b81c053d35b167
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div><div>If Alice knows enough to see that she needs=
<span class=3D"gmail-im">CHECKBLOCKATHEIGHT to avoid paying Bob twice, the=
n she also knows that Fred owes her 4BTC.=C2=A0 If Bob complains about gett=
ing paid faster, Alice can let him know that Fred essentially stole his coi=
ns and that when she is certain he (and she) can't get them back, she w=
ill send a different four coins to Bob.=C2=A0 If she can establish trust wi=
th Bob (She'd trust Bob to pay her back if he gets back the coins Fred =
stole), then she can pay him again.=C2=A0 Bob could also make a transaction=
to send the first input from Alice back to her (since he doesn't have =
those coins anyway), sign it, and send that to her.=C2=A0 She can then keep=
it instead of having to use the new opcode.<br><br></span></div><span clas=
s=3D"gmail-im">Or she can let her wallet use the new opcode so that the log=
ic is built in, if we add this opcode.=C2=A0 Wallet makers who want to help=
solve this problem can either implement the new opcode, or they can offer =
people like Bob the ability to refund orphaned transactions so that they ca=
n be duplicated in the valid chain without any risk to the original sender.=
<br><br></span></div><span class=3D"gmail-im">With the opcode, Alice can so=
lve the problem by herself.=C2=A0 Without it, Bob can solve it for Alice.<b=
r><br></span></div><span class=3D"gmail-im">While the opcode adds complexit=
y, it enables victims of double-spends to pay untrusted creditors (Bob) wit=
hout the risk that orphaned chains create of paying them twice.=C2=A0 I'=
;m not sure the added complexity is worth the reward. The reward is to prot=
ect Bitcoiners (Alice) from people we'd call "untrusted creditors&=
quot; (Bob) and I think that might be a mistake.=C2=A0 Getting a refund tra=
nsaction signed and sent back to Alice is similar to how the LN will work (=
where wallets hold transactions that they don't broadcast).<br><br></sp=
an><span class=3D"gmail-im">Am I understanding this correctly?=C2=A0 </span=
></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Fri, Se=
p 23, 2016 at 3:34 PM, Luke Dashjr via bitcoin-dev <span dir=3D"ltr"><<a=
href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bi=
tcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<br><blockquote cl=
ass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;p=
adding-left:1ex">Joe sends Alice 5 BTC (UTXO 0).<br>
Fred sends Alice 4 BTC (UTXO 1).<br>
Alice sends Bob 4 BTC using UTXO 1 (creating UTXO 2).<br>
Fred double-spends UTXO 1 with UTXO 1-B. This invalidates Alice's trans=
fer to<br>
Bob.<br>
Alice has UTXO 0 which she can send to Bob (UTXO 3), but if she does so, it=
is<br>
possible that UTXO 0 could be mined, and then both UTXO 2 and UTXO 3 which<=
br>
would result in her giving Bob a total of 8 BTC rather than merely 4 BTC.<b=
r>
Even if Alice waits until Fred's UTXO 1-B confirms 10 blocks deep, it i=
s not<br>
impossible for a reorganization to reverse those 10 blocks and confirm UTXO=
1<br>
again.<br>
Using OP_CHECKBLOCKATHEIGHT, however, Alice can create UTXO 3 such that it =
is<br>
valid only in the blockchain where Fred's UTXO 1-B has confirmed. This =
way, if<br>
that block is reorganized out, UTXO 3 is invalid, and either Bob receives o=
nly<br>
the original UTXO 2, or Alice can create a UTXO 3-B which is valid in the<b=
r>
reorganized blockchain if it again confirms the UTXO 1-B double-spend.<br>
<br>
Luke<br>
<br>
On Friday, September 23, 2016 2:37:39 PM Tom via bitcoin-dev wrote:<br>
<span class=3D"">> On Friday 23 Sep 2016 09:57:01 Luke Dashjr via bitcoi=
n-dev wrote:<br>
> > This BIP describes a new opcode (OP_CHECKBLOCKATHEIGHT) for the B=
itcoin<br>
> > scripting system to address reissuing bitcoin transactions when t=
he coins<br>
> > they spend have been conflicted/double-spent.<br>
> ><br>
> > <a href=3D"https://github.com/luke-jr/bips/blob/bip-cbah/bip-cbah=
.mediawiki" rel=3D"noreferrer" target=3D"_blank">https://github.com/luke-jr=
/<wbr>bips/blob/bip-cbah/bip-cbah.<wbr>mediawiki</a><br>
><br>
</span>> Can you walk us through a real live usecase which this solves?=
=C2=A0 I read it<br>
> and I think I understand it, but I can't see the attack every givi=
ng the<br>
> attacker any benefit (or the attacked losing anything).<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@l=
ists.<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.<wb=
r>org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
______________________________<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><br clear=3D"all"><br>-- <br><div class=
=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr">I =
like to provide some work at no charge to prove my value. Do you need a tec=
hie?=C2=A0 <br>I own <a href=3D"http://www.litmocracy.com" target=3D"_blank=
">Litmocracy</a> and <a href=3D"http://www.memeracing.net" target=3D"_blank=
">Meme Racing</a> (in alpha). <br>I'm the webmaster for <a href=3D"http=
://www.voluntaryist.com" target=3D"_blank">The Voluntaryist</a> which now a=
ccepts Bitcoin.<br>I also code for <a href=3D"http://dollarvigilante.com/" =
target=3D"_blank">The Dollar Vigilante</a>.<br>"He ought to find it mo=
re profitable to play by the rules" - Satoshi Nakamoto</div></div>
</div>
--001a1142d3c491b81c053d35b167--
|
