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
|
Return-Path: <roconnor@blockstream.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 3529EC000B
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 11 Jun 2021 11:43:38 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp2.osuosl.org (Postfix) with ESMTP id 2427E40107
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 11 Jun 2021 11:43:38 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Authentication-Results: smtp2.osuosl.org (amavisd-new);
dkim=pass (2048-bit key)
header.d=blockstream-com.20150623.gappssmtp.com
Received: from smtp2.osuosl.org ([127.0.0.1])
by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id Z_OQfZCr-fmE
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 11 Jun 2021 11:43:35 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-qv1-xf2d.google.com (mail-qv1-xf2d.google.com
[IPv6:2607:f8b0:4864:20::f2d])
by smtp2.osuosl.org (Postfix) with ESMTPS id 12CF7400C2
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 11 Jun 2021 11:43:34 +0000 (UTC)
Received: by mail-qv1-xf2d.google.com with SMTP id 5so6049801qvf.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 11 Jun 2021 04:43:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=blockstream-com.20150623.gappssmtp.com; s=20150623;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=w5SAoq7hOKJmu1lY5F0OIV8PX2svfC9NfAsS8UkzKK4=;
b=grwS/XmiU5/JxPCSWygOr1dJGq/ebx2nycxFpUnHKMCT6amEjUxt1VvgA3VY2Z/h06
9rf8UVL3rtchudANryZFAI06kkKSdsGo9auuzC5heRRRSwXtYRAMHRkVwpRsJLnwszQK
HeISr05m8jSRLZDhIUIPEC8k/cTAsmIDwlgJ8olUBLsxEvgchorxPXD2Pn0rOqPq3PX3
SmWec0UCq1tCmX2g/G0ox7RAP5RaHGciKsIb7dmwyo0IPvm30FzG6ho6CjGgjGfK8AKc
KXapvwqDk2/WI1skRerNZ+JOkPbPIum+x0U67EGv8osMAHvEj6ttYooKiNt3nf3kyqpY
TZAg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=w5SAoq7hOKJmu1lY5F0OIV8PX2svfC9NfAsS8UkzKK4=;
b=gGEBuvOawlU2C4AFSisJ35j2Z5wl2M/rmLJmTR9VpDRz8Mzspa3jRMv9KGMQ3GXQ3Q
j6yjaP+eW/iLIflI8uqLX+bNZ07VLveLjrpld84VpXVJ4fBWEZWeGCSe6RC1m4pMlfQW
uCwgAtWNCOX8MM9J6KBmDOb1aAfojefDyan35V2LNtjzTR5tOkZo4GkAU5tXgz3ykTXi
Nh7Jok0Uxgm498IVTQhYXFB9/VkeXFTrL2IHxI8E05G+J5nNxH7L6/czpLWbYSeJNAYZ
WC6eLLVH0yQc2AmXWuMBKU7fMyhtsZxMAimwrdU29eKMOuu6zf6dZ9TckaNb7OBCGu3X
WoLQ==
X-Gm-Message-State: AOAM530pnhXEgJv7bd6V0fOOhtzSy6GtMJRBps/yoVpJVGfV4BXDpz8R
LJIrC2kGgIv/cWE8oiG7jDaqBT1E3bg5HZjrfhmAxg==
X-Google-Smtp-Source: ABdhPJzwFKXvIDVa9ThbXeQNNBfVCtLTIqhOyk4C4vfcVNg20tmpbMaux/YYX7gohwwQj8y2yVoieSgtEX/wjCxKjEU=
X-Received: by 2002:a0c:ee8a:: with SMTP id u10mr4302299qvr.13.1623411813716;
Fri, 11 Jun 2021 04:43:33 -0700 (PDT)
MIME-Version: 1.0
References: <CAGpPWDYRcR1U-zwmM_jUA_49LRMsAC5h+DpNFjn5nGniQpN29w@mail.gmail.com>
<CAMZUoK=1Rw-rzYPh24VLaH2HmmEO-B2ipf_9ymPb1RQQGUzjvw@mail.gmail.com>
<CAGpPWDb4sp4XoQjb7qOfNK3BQTS3zNrx6SQ3s7N=HM+ZaiLPLw@mail.gmail.com>
<CAMZUoK=EM6cN2YYrZ=YxtrAi5GfxTuY5_6nb5HGWD-WL4RNOCg@mail.gmail.com>
<CAGpPWDZLzV0EghpeL1Hw-_5kToU_-Vzzco5DuxnivKEAS51NHg@mail.gmail.com>
<CAH+Axy7b8MS92ZeMnPx-TosvNzRv9=34UDQ9ia-fxeLzO_A0+Q@mail.gmail.com>
In-Reply-To: <CAH+Axy7b8MS92ZeMnPx-TosvNzRv9=34UDQ9ia-fxeLzO_A0+Q@mail.gmail.com>
From: "Russell O'Connor" <roconnor@blockstream.com>
Date: Fri, 11 Jun 2021 07:43:22 -0400
Message-ID: <CAMZUoKmytZm5boBKSYbrJdNa0LduxtTyUUheq=tjD1J_GO0TjA@mail.gmail.com>
To: James MacWhyte <macwhyte@gmail.com>
Content-Type: multipart/alternative; boundary="0000000000007b2b5c05c47c04ee"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
Billy Tetrud <billy.tetrud@gmail.com>
Subject: Re: [bitcoin-dev] OP_BEFOREBLOCKVERIFY - discussing and opcode that
invalidates a spend path after a certain block
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
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, 11 Jun 2021 11:43:38 -0000
--0000000000007b2b5c05c47c04ee
Content-Type: text/plain; charset="UTF-8"
On Fri, Jun 11, 2021 at 7:12 AM James MacWhyte <macwhyte@gmail.com> wrote:
> @Billy I like the idea. It is very obvious how useful an opcode like this
> would be! (My background is in wallet implementation)
>
> @Russell I do understand your concerns of monotonism, however I'm having a
> hard time really coming up with an attack vector. You said "one can design
> a wallet to passively take advantage of reorgs by always spending through
> an OP_BBV that is on the verge of becoming invalid." Unless I'm mistaken,
> this means you would need to send yourself a fresh transaction using OP_BBV
> set to, say, 2 blocks in the future, then immediately spend that output in
> a new payment to someone else and hope a reorg happens. Does this mean the
> theoretical double-spend wallet you are proposing would have to send two
> transactions every time you make a single payment, doubling the transaction
> fees and adding more uncertainty around when the second transaction would
> get confirmed?
>
Assuming the proposal is rewritten to place the maxheight into the taproot
annex in order to address the issue with caching of script validity, then
this auto-double-spend wallet would send every payment with an annex value
that limits the payment to being valid only up to the next block. If the
payment doesn't make it into the next block, then resign it with the annex
incremented to the next block, and repeat.
> In a normal double spend scenario, there is no cost to a failed attempt,
> but much to gain from a success. With your design, there is a real cost to
> every single attempt (transaction fees) and no evidence that the rate of
> success would be higher (you still have to bet on the reorg not including
> your transaction in the first few blocks). It sounds like this new system
> would actually be less attractive to double spenders than the current model!
>
> I also agree with Billy's idea for relay rules. We already have abusable
> chain rules (e.g. a tx can be included in a block with 0 transaction fee
> [spam?]) but we add protection with relay rules (e.g. minimum fee to
> relay). I don't see how this would be any different, if the chain rules
> only enforced the block height for confirmation and the relay rules forced
> a minimum OP_BBV value in order to protect against reorg double spends.
>
The inclusion of a tx with 0 transaction fee in a block is not in of itself
an abuse. There is nothing wrong with blocks containing such
transactions. The *relay* of 0 transaction fee transactions is what is an
abuse because it allows one to usurp Bitcoin's gossip network for their own
arbitrary communications platform without cost. Most Bitcoin users aren't
signing up for being a usenet provider. So, by policy, nodes require a
cost to relay transactions so that broadcasting isn't free. Even when that
price is paid to someone else, it still is an effective limitation on abuse.
--0000000000007b2b5c05c47c04ee
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Fri, Jun 11, 2021 at 7:12 AM James=
MacWhyte <<a href=3D"mailto:macwhyte@gmail.com">macwhyte@gmail.com</a>&=
gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div =
dir=3D"ltr">@Billy I like the idea. It is very obvious how useful an opcode=
like this would be! (My background is in wallet implementation)<div><br></=
div><div>@Russell I do understand your concerns of monotonism, however I=
9;m having a hard time really coming up with an attack vector. You said &qu=
ot;one can design a wallet to passively take advantage of reorgs by always =
spending through an OP_BBV that is on the verge of becoming invalid." =
Unless I'm mistaken, this means you would need to send yourself a fresh=
transaction using OP_BBV set to, say, 2 blocks in the future, then immedia=
tely spend that output in a new payment to someone else and hope a reorg=C2=
=A0happens. Does this mean the theoretical double-spend wallet you are prop=
osing would have to send two transactions every time you make a single paym=
ent, doubling the transaction fees and adding more uncertainty around when =
the second transaction would get confirmed?<br></div></div></blockquote><di=
v><br></div><div>Assuming the proposal is rewritten to place the maxheight =
into the taproot annex in order to address the issue with caching of script=
validity, then this auto-double-spend wallet would send every payment with=
an annex value that limits the payment to being valid only up to the next =
block.=C2=A0 If the payment doesn't make it into the next block, then r=
esign it with the annex incremented to the next block, and repeat.<br></div=
><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px=
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div di=
r=3D"ltr"><div>In a normal double spend scenario, there is no cost to a fai=
led attempt, but much to gain from a success. With your design, there is a =
real cost to every single attempt (transaction fees) and no evidence that t=
he rate of success would be higher (you still have to bet on the reorg not =
including your transaction in the first few blocks). It sounds like this ne=
w system would actually be less attractive to double spenders than the curr=
ent model!</div><div><br></div><div>I also agree with Billy's idea for =
relay rules. We already have abusable chain rules (e.g. a tx can be include=
d in a block with 0 transaction fee [spam?]) but we add protection with rel=
ay rules (e.g. minimum fee to relay). I don't see how this would be any=
different, if the chain rules only enforced the block height for confirmat=
ion and the relay rules forced a minimum OP_BBV value in order to protect a=
gainst reorg double spends.</div></div></blockquote><div><br></div><div>The=
inclusion of a tx with 0 transaction fee in a block is not in of itself an=
abuse.=C2=A0 There is nothing wrong with blocks containing such transactio=
ns.=C2=A0 The *relay* of 0 transaction fee transactions is what is an abuse=
because it allows one to usurp Bitcoin's gossip network for their own =
arbitrary communications platform without cost.=C2=A0 Most Bitcoin users ar=
en't signing up for being a usenet provider.=C2=A0 So, by policy, nodes=
require a cost to relay transactions so that broadcasting isn't free. =
Even when that price is paid to someone else, it still is an effective limi=
tation on abuse.<br></div></div></div>
--0000000000007b2b5c05c47c04ee--
|