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
|
Return-Path: <jeremy.l.rubin@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
by lists.linuxfoundation.org (Postfix) with ESMTP id 872CFC000B;
Sat, 19 Feb 2022 00:38:45 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id 6887481769;
Sat, 19 Feb 2022 00:38:45 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp1.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp1.osuosl.org ([127.0.0.1])
by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id Yc_VCkVOHEH7; Sat, 19 Feb 2022 00:38:41 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-lf1-x134.google.com (mail-lf1-x134.google.com
[IPv6:2a00:1450:4864:20::134])
by smtp1.osuosl.org (Postfix) with ESMTPS id B9F4981425;
Sat, 19 Feb 2022 00:38:40 +0000 (UTC)
Received: by mail-lf1-x134.google.com with SMTP id e5so8354141lfr.9;
Fri, 18 Feb 2022 16:38:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to
:cc; bh=7fFErMLPUa0c0gxXagbL5qwaTHAQ73SX9QNPzwC79vQ=;
b=fNtplhpncULgvbh0DjL4a9JZ8fgSfn7dUebw3DrZkyhnvyEbAb/x5QDDlsKYcHH59w
6xSoIPfn5jnztFupiiLG0EEEgL7CEvhMmOKhR0YekNFP2+NjW3/4ELxvTv6qv9OP3Ejs
UyCrH5ju6Z8aaB3jBLptr1RPCLpZNVxNAIsC0gyV8ku31qN/wXirRYIO3mwoKeUDQmOC
+8jQYFiVFILIspmdMICTjNgXl3xCcbeqaOZsM3iDo9Rh4oQhqOmlhycjmLd3HgrInwvu
rNV1BdLXEZDZrNLQIJAuaGiK886ORqmWb5PqlEy7Pr47iPqPOqZKvDUFZRTqnY8q1t8o
NNSg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20210112;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to:cc;
bh=7fFErMLPUa0c0gxXagbL5qwaTHAQ73SX9QNPzwC79vQ=;
b=OL7SmTtXxDxu+CNUc8YTcsmyyYkUTYH0UF8b9shN+JTgXwIf+Mj2XeJmJNaneTVwlU
RCJekS189Wlj7Ej0e4H4j9vo5E0K6UF3Tj54xDih1pEi+6wz3qMUCt7c0iMUr+R5Mtu2
FB0muodLH0TLGIotyHQEZbF9FygsXw1MAER0A5kwXQeC9RvUafwcgcTKa0jpe+eSqvbv
tR+TcYYQr8OylYSqpIsCj2bZcpgmRXTEbiWD3AQifSVivPEQELt7h7QPD8Jp2SEDN2rH
PsKUcKNsF8HbMPsNISYol/uWlmgXhZH2bs81sIpU1+urnnnOPmfLsw1kM5MYfXEqsPwD
hI2g==
X-Gm-Message-State: AOAM531kboFsTIwNexfc7AMrxMarBfTrLdo03ISsMZ3i0oMCn0jQO/OG
KQC1tb3VWlwL4l3a4kMc+aUyGCRtbZ+omrZ0xWg=
X-Google-Smtp-Source: ABdhPJxK+equU/zk11jduEypaU9GEn5UhtbD9Gq2vcq66ZFTC710jCfnX8Kmj5KyrQyyUX/Dy0kfeMQFIQbjbknF9QY=
X-Received: by 2002:a05:6512:114c:b0:443:4d18:86c0 with SMTP id
m12-20020a056512114c00b004434d1886c0mr7214191lfg.226.1645231118498; Fri, 18
Feb 2022 16:38:38 -0800 (PST)
MIME-Version: 1.0
References: <CAD5xwhik6jVQpP2_ss7d5o+pPLsqDCHuaXG41AMKHVYhZMXF1w@mail.gmail.com>
<YgS3sJvg6kG3WnVJ@petertodd.org>
<CAD5xwhi3Ja8gdU2h_6-1ck4kdU0TiC2Kx5O-61=f9=6JQSMs=A@mail.gmail.com>
<YhAwr7+9mGJAe2/p@petertodd.org>
In-Reply-To: <YhAwr7+9mGJAe2/p@petertodd.org>
From: Jeremy Rubin <jeremy.l.rubin@gmail.com>
Date: Fri, 18 Feb 2022 16:38:27 -0800
Message-ID: <CAD5xwhi=sKckFZew75tZTogoeFABraWtJ6qMC+RgZjcirxYyZw@mail.gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary="000000000000643e2d05d8543839"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
lightning-dev <lightning-dev@lists.linuxfoundation.org>,
Jeremy <jlrubin@mit.edu>
Subject: Re: [bitcoin-dev] [Pre-BIP] Fee Accounts
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: Sat, 19 Feb 2022 00:38:45 -0000
--000000000000643e2d05d8543839
Content-Type: text/plain; charset="UTF-8"
> As I said, it's a new kind of pinning attack, distinct from other types
of pinning attack.
I think pinning is "formally defined" as sequences of transactions which
prevent or make it less likely for you to make any progress (in terms of
units of computation proceeding).
Something that only increases possibility to make progress cannot be
pinning.
If you want to call it something else, with a negative connotation, maybe
call it "necromancing" (bringing back txns that would otherwise be
feerate/fee irrational).
I would posit that we should be wholly unconcerned with necromancing -- if
your protocol is particularly vulnerable to a third party necromancing then
your protocol is insecure and we shouldn't hamper Bitcoin's forward
progress on secure applications to service already insecure ones. Lightning
is particularly necromancy resistant by design, but pinning vulnerable.
This is also true with things like coinjoins which are necromancy resistant
but pinning vulnerable.
Necromancy in particular is something that isn't uniquely un-present in
Bitcoin today, and things like package relay and elimination of pinning are
inherently at odds with making necromancy either for CPFP use cases.
In particular, for the use case you mentioned "Eg a third party could mess
up OpenTimestamps calendars at relatively low cost by delaying the mining
of timestamp txs.", this is incorrect. A third party can only accelerate
the mining on the timestamp transactions, but they *can* accelerate the
mining of any such timestamp transaction. If you have a single output chain
that you're RBF'ing per block, then at most they can cause you to shift the
calendar commits forward one block. But again, they cannot pin you. If you
want to shift it back one block earlier, just offer a higher fee for the
later RBF'd calendar. Thus the interference is limited by how much you wish
to pay to guarantee your commitment is in this block as opposed to the next.
By the way, you can already do out-of-band transaction fees to a very
similar effect, google "BTC transaction accelerator". If the attack were at
all valuable to perform, it could happen today.
Lastly, if you do get "necromanced" on an earlier RBF'd transaction by a
third party for OTS, you should be relatively happy because it cost you
less fees overall, since the undoing of your later RBF surely returned some
satoshis to your wallet.
Best,
Jeremy
--000000000000643e2d05d8543839
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:rgb(0,0,0)">>=C2=A0<span style=
=3D"font-family:Arial,Helvetica,sans-serif;color:rgb(34,34,34)">As I said, =
it's a new kind of pinning attack, distinct from other types of=C2=A0</=
span><span style=3D"font-family:Arial,Helvetica,sans-serif;color:rgb(34,34,=
34)">pinning attack.</span></div><div class=3D"gmail_default" style=3D"font=
-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><span =
style=3D"font-family:Arial,Helvetica,sans-serif;color:rgb(34,34,34)"><br></=
span></div><div class=3D"gmail_default" style=3D"font-family:arial,helvetic=
a,sans-serif;font-size:small;color:rgb(0,0,0)"><span style=3D"font-family:A=
rial,Helvetica,sans-serif;color:rgb(34,34,34)">I think pinning is "for=
mally defined" as sequences of transactions which prevent or make it l=
ess likely for you to=C2=A0make any progress (in terms of units of computat=
ion proceeding).</span></div><div class=3D"gmail_default" style=3D"font-fam=
ily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><span styl=
e=3D"font-family:Arial,Helvetica,sans-serif;color:rgb(34,34,34)"><br></span=
></div><div class=3D"gmail_default" style=3D"font-size:small">Something tha=
t only increases possibility to make progress cannot be pinning.</div><div =
class=3D"gmail_default" style=3D"font-size:small"><br></div><div class=3D"g=
mail_default" style=3D"font-size:small">If you want to call it something el=
se, with a negative connotation, maybe call it "necromancing" (br=
inging back txns that would otherwise be feerate/fee irrational).</div><div=
class=3D"gmail_default" style=3D"font-size:small"><br></div><div class=3D"=
gmail_default" style=3D"font-size:small">I would posit that we should be wh=
olly unconcerned with necromancing -- if your protocol is particularly vuln=
erable to a third party necromancing then your protocol is insecure and we =
shouldn't hamper Bitcoin's forward progress on secure applications =
to service already insecure ones. Lightning is particularly necromancy resi=
stant by design, but pinning vulnerable. This is also true with things like=
coinjoins which are necromancy resistant but pinning vulnerable.</div><div=
class=3D"gmail_default" style=3D"font-size:small"><br></div><div class=3D"=
gmail_default" style=3D"font-size:small">Necromancy in particular is someth=
ing that isn't uniquely un-present in Bitcoin today, and things like pa=
ckage relay and elimination of pinning are inherently at odds with making n=
ecromancy either for CPFP use cases.</div><div class=3D"gmail_default" styl=
e=3D"font-size:small"><br></div><div class=3D"gmail_default" style=3D"font-=
size:small">In particular, for the use case you mentioned "Eg a third =
party could mess up OpenTimestamps calendars at relatively low cost by dela=
ying the mining of timestamp txs.", this is incorrect. A third party c=
an only accelerate the mining on the timestamp transactions, but they *can*=
accelerate the mining of any such timestamp transaction. If you have a sin=
gle output chain that you're RBF'ing per block,=C2=A0then at most t=
hey can cause you to shift the calendar commits forward one block. But agai=
n, they cannot pin you. If you want to shift it back one block earlier, jus=
t offer a higher fee for the later RBF'd calendar. Thus the interferenc=
e is limited by how much you wish to pay to guarantee your commitment is in=
this block as opposed to the next.</div><div class=3D"gmail_default" style=
=3D"font-size:small"><br></div><div class=3D"gmail_default">By the way, you=
can already do out-of-band transaction fees to a very similar effect, goog=
le "BTC transaction accelerator". If the attack were at all valua=
ble to perform, it could happen today.</div><div class=3D"gmail_default"><b=
r></div><div class=3D"gmail_default">Lastly, if you do get "necromance=
d" on an earlier RBF'd transaction by a third party for OTS, you s=
hould be relatively happy because it cost you less fees overall, since the =
undoing of your later RBF surely returned some satoshis to your wallet.</di=
v><div class=3D"gmail_default"><br></div><div class=3D"gmail_default">Best,=
</div><div class=3D"gmail_default"><br></div><div class=3D"gmail_default">J=
eremy</div></div>
--000000000000643e2d05d8543839--
|