summaryrefslogtreecommitdiff
path: root/12/e0d5cb1d39e9858849f5d76a0f843021be5679
blob: f3716c5bfc23ad5f631365c78b171a74f49a623c (plain)
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
Return-Path: <darosior@protonmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 5C0AFC000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 19 Feb 2022 17:20:27 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 4B0DB40905
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 19 Feb 2022 17:20:27 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level: 
X-Spam-Status: No, score=-2.102 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,
 RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=protonmail.com
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id CM8PTG3302_O
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 19 Feb 2022 17:20:25 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
Received: from mail-40132.protonmail.ch (mail-40132.protonmail.ch
 [185.70.40.132])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 884DE408F3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 19 Feb 2022 17:20:25 +0000 (UTC)
Date: Sat, 19 Feb 2022 17:20:19 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=protonmail3; t=1645291222;
 bh=aQ9WnEkfrwqOjhPFrNY4KG6MAri+9s6Efyq6M0nVn3w=;
 h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To:
 References:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
 Message-ID;
 b=C7QN5a+/jFOqgOWXTOV+khwCLB9A3jeOlsWZBfA0UNzvFW7Q3KlVYP1mA8ryO7K7x
 psY9/ZDLwaaL4y/HJBTZqwYYRDNiKyAO3KcumDFB0AN4/fnX4FPtbMHWPz2accDHIi
 eJPZLIpUpF82seYo55KJUq8dmOs3QLIFvzaExrp8a+UQtBfuBuSCQ76ExDNs+w0FPa
 PQ4e72nF5aV6ZXkWSEUxfYOQsdb/uggkQGKXzTZQfWp1T948sJ5QRlx+WljsoloFNj
 EX4oBbZQZDm92gDB3WDhvV/8Ho+abfbLhJWe/nrTd5TjMdoJ9e6s3iZkIzprvelKEY
 RRqqPncN75SHA==
To: Peter Todd <pete@petertodd.org>
From: darosior <darosior@protonmail.com>
Reply-To: darosior <darosior@protonmail.com>
Message-ID: <kJWi5A4sc0UEU4JrtSg3gbR_M1UTp15XW3Oj5B5cQZQvygFn9pIqrxVxCU0sFjG5L05fqDFH6nz2PnU0sE_zVNMGsCXzmtJeDAc1kEYmYKA=@protonmail.com>
In-Reply-To: <YhC6yjoe3bAfBS+W@petertodd.org>
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>
 <CAD5xwhi=sKckFZew75tZTogoeFABraWtJ6qMC+RgZjcirxYyZw@mail.gmail.com>
 <YhC6yjoe3bAfBS+W@petertodd.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Sat, 19 Feb 2022 18:10:47 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 lightning-dev <lightning-dev@lists.linuxfoundation.org>,
 Jeremy <jlrubin@mit.edu>
Subject: Re: [bitcoin-dev] [Lightning-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 17:20:27 -0000

> Necromancing might be a reasonable name for attacks that work by getting =
an
> out-of-date version of a tx mined.

It's not an "attack"? There is no such thing as an out-of-date transaction,=
 if
you signed and broadcasted it in the first place. You can't rely on the fac=
t that
a replacement transaction would somehow invalidate a previous version of it=
.

------- Original Message -------

Le samedi 19 f=C3=A9vrier 2022 =C3=A0 10:39 AM, Peter Todd <pete@petertodd.=
org> a =C3=A9crit :

> On Fri, Feb 18, 2022 at 04:38:27PM -0800, Jeremy Rubin wrote:
>
> > > As I said, it's a new kind of pinning attack, distinct from other typ=
es
> > >
> > > of pinning attack.
> >
> > I think pinning is "formally defined" as sequences of transactions whic=
h
> >
> > prevent or make it less likely for you to make any progress (in terms o=
f
> >
> > units of computation proceeding).
>
> Mentioning "computation" when talking about transactions is misleading:
>
> blockchain transactions have nothing to do with computation.
>
> > Something that only increases possibility to make progress cannot be
> >
> > pinning.
>
> It is incorrect to say that all use-cases have the property that any vers=
ion of
>
> a transaction being mined is progress.
>
> > If you want to call it something else, with a negative connotation, may=
be
> >
> > call it "necromancing" (bringing back txns that would otherwise be
> >
> > feerate/fee irrational).
>
> Necromancing might be a reasonable name for attacks that work by getting =
an
>
> out-of-date version of a tx mined.
>
> > In particular, for the use case you mentioned "Eg a third party could m=
ess
> >
> > up OpenTimestamps calendars at relatively low cost by delaying the mini=
ng
> >
> > of timestamp txs.", this is incorrect. A third party can only accelerat=
e
> >
> > the mining on the timestamp transactions, but they can accelerate the
> >
> > mining of any such timestamp transaction. If you have a single output c=
hain
> >
> > 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 th=
e
> >
> > 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.
>
> Your understanding of how OpenTimestamps calendars work appears to be
>
> incorrect. There is no chain of unconfirmed transactions. Rather, OTS cal=
endars
>
> use RBF to update the timestamp tx with a new merkle tip hash for to all
>
> outstanding per-second commitments once per new block. In high fee situat=
ions
>
> it's normal for there to be dozens of versions of that same tx, each with=
 a
>
> slightly higher feerate.
>
> OTS calendars can handle any of those versions getting mined. But older
>
> versions getting mined wastes money, as the remaining commitments still n=
eed to
>
> get mined in a subsequent transaction. Those remaining commitments are al=
so
>
> delayed by the time it takes for the next tx to get mined.
>
> There are many use-cases beyond OTS with this issue. For example, some en=
tities
>
> use "in-place" replacement for update low-time-preference settlement
>
> transactions by adding new txouts and updating existing ones. Older versi=
ons of
>
> those settlement transactions getting mined rather than the newer version
>
> wastes money and delays settlement for the exact same reason it does in O=
TS.
>
> If fee accounts or any similar mechanism get implemented, they absolutely
>
> should be opt-in. Obviously, using a currently non-standard nVersion bit =
is a
>
> possible approach. Conversely, with CPFP it may be desirable in the settl=
ement
>
> case to be able to prevent outputs from being spent in the same block. Ag=
ain,
>
> an nVersion bit is a possible approach.
>
> > By the way, you can already do out-of-band transaction fees to a very
> >
> > similar effect, google "BTC transaction accelerator". If the attack wer=
e at
> >
> > all valuable to perform, it could happen today.
>
> I just checked: all the BTC transaction accellerator services I could fin=
d look
>
> to be either scams, or very expensive. We need compelling reasons to make=
 this
>
> nuisance attack significantly cheaper.
>
> > 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.
>
> As I said above, no it doesn't.
>
> ----------------------------------
>
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
> Lightning-dev mailing list
>
> Lightning-dev@lists.linuxfoundation.org
>
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev