summaryrefslogtreecommitdiff
path: root/77/cbe736df0448b1c5fdd1902fa9b7b8b65891f2
blob: 168e50bed902265eda2c23a25175f0f64db092b0 (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
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
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
Return-Path: <jeremy.l.rubin@gmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 7462CC0033;
 Sun, 20 Feb 2022 16:29:15 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp1.osuosl.org (Postfix) with ESMTP id 5C2DF813AD;
 Sun, 20 Feb 2022 16:29:15 +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 pNpfHVFpYXTY; Sun, 20 Feb 2022 16:29:14 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-lf1-x12d.google.com (mail-lf1-x12d.google.com
 [IPv6:2a00:1450:4864:20::12d])
 by smtp1.osuosl.org (Postfix) with ESMTPS id D666A81394;
 Sun, 20 Feb 2022 16:29:13 +0000 (UTC)
Received: by mail-lf1-x12d.google.com with SMTP id b9so14359461lfv.7;
 Sun, 20 Feb 2022 08:29:13 -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=c8TxWfd+wCUpl+uV2MO90xsSO+q9c9QXSPv06gz56dw=;
 b=hLSMMSU/u88EXst1WpXTRS+ICikiITKb823cbd1AxLJItLvyStR91s7zVRo95wLwj2
 ilFSQyKnQ3K20nafYCcXNX+yneZGC7S/EnNpScJSh3hGKppeVBLbk3kqFXRc++LiuJws
 kZXM1ahWJohq9HOabmJbsTyXooh+aRPhAOIVKUcq93sHfolbhBY150wm3S1EnFih6pQB
 8+jRPvGl/XZmiM9UVz0LEXpYx/ALaDVx5nIdNTWymdCO1VgPwy8AXXeCvs0KljolMLUh
 1CMH2NE7YLRlNNHyIOBhlZjTAA06c56QlU6SNAr49Y2s2M6T1uyG0o2XpDTf88SzYsvx
 V6XA==
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=c8TxWfd+wCUpl+uV2MO90xsSO+q9c9QXSPv06gz56dw=;
 b=tbXmYP8YXLr4VUUwHOaCs/1+xuiVztTNytaxkn1qRLVax3RtFJNj6u2+9gCRFRra0s
 CY64uMvWsc7sqIJV9JQcklU+tDM6OFgBv2om0qQRng0HpfiMd40vkGrq/eeb1srqpRgY
 bzAxYdKtFwckR7aSxNX3IS1/xrZBXVmDWlWwB2AziymyIuS5KjqUkzphTb6XTtE2Uhk3
 9C4hdny66Wwr0ebpndwOYPfQ92HFW6/EPzWwaYSARtFGeixkEeU/TOgwjBrKoGkqzXkz
 Ux+Fzp0G8pZ1T0wrvvM6YTyxZGHW1I/jqfJeYYb2VEZbKKXCeeNqpezRXrhYyLPpbMZh
 qjeQ==
X-Gm-Message-State: AOAM53246G6r9Sx/E+BROui6soZlvF0Lj3MJkCpgJu4w8njbkNI93Wb/
 MRApUnDFh6HuJ9XtO3QyUPekRNzW14MiHNbnTWc=
X-Google-Smtp-Source: ABdhPJxwD/wPUJByTgafgWGqZshOaqp5sbry+BRMDkXgO93PhrP8Iu6iumR7dHwiixawcauokllWTa0OfBR0b3REzuo=
X-Received: by 2002:a05:6512:1322:b0:443:161a:c693 with SMTP id
 x34-20020a056512132200b00443161ac693mr11364531lfu.363.1645374551515; Sun, 20
 Feb 2022 08:29:11 -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>
 <CAD5xwhi=sKckFZew75tZTogoeFABraWtJ6qMC+RgZjcirxYyZw@mail.gmail.com>
 <YhC6yjoe3bAfBS+W@petertodd.org>
In-Reply-To: <YhC6yjoe3bAfBS+W@petertodd.org>
From: Jeremy Rubin <jeremy.l.rubin@gmail.com>
Date: Sun, 20 Feb 2022 08:29:00 -0800
Message-ID: <CAD5xwhjR06Lp3ka-MqZQE64tfE5uDQB6TrMh06khjYrDzuT95g@mail.gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary="000000000000aa684205d8759d3c"
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: Sun, 20 Feb 2022 16:29:15 -0000

--000000000000aa684205d8759d3c
Content-Type: text/plain; charset="UTF-8"

--
@JeremyRubin <https://twitter.com/JeremyRubin>


On Sat, Feb 19, 2022 at 1:39 AM Peter Todd <pete@petertodd.org> wrote:

> 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 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).
>
> Mentioning "computation" when talking about transactions is misleading:
> blockchain transactions have nothing to do with computation.
>

It is in fact computation. Branding it as "misleading" is misleading... The
relevant literature is https://en.wikipedia.org/wiki/Non-blocking_algorithm,
sponsors helps get rid of deadlocking so that any thread can be guaranteed
to make progress. E.g., this is critical in Eltoo, which is effectively a
coordinated multi-party computation on-chain to compute the highest
sequence number known by any worker.

That transactions are blobs of "verification" (which is also itself a
computation) less so than dynamic computations is irrelevant to the fact
that series of transactions do represent computations.



> > 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
> version of
> a transaction being mined is progress.
>

It is progress, tautologically. Progress is formally definable as a
transaction of any kind getting mined. Pinning prevents progress by an
adversarial worker. Sponsoring enables progress, but it may not be your
preferred interleaving. That's OK, but it's inaccurate to say it is not
progress.

Your understanding of how OpenTimestamps calendars work appears to be
> incorrect. There is no chain of unconfirmed transactions. Rather, OTS
> calendars
> 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
> situations
> it's normal for there to be dozens of versions of that same tx, each with a
> slightly higher feerate.
>

I didn't claim there to be a chain of unconfirmed, I claimed that there
could be single output chain that you're RBF'ing one step per block.

E.g., it could be something like

A_0 -> {A_1 w/ CSV 1 block, OP_RETURN {blah, foo}}
A_1 -> {A_2 w/ CSV 1 block, OP_RETURN {bar}}

such that A_i provably can't have an unconfirmed descendant. The notion
would be that you're replacing one with another. E.g., if you're updating
the calendar like:


Version 0: A_0 -> {A_1 w/ CSV 1 block, OP_RETURN {blah, foo}}
Version 1: A_0 -> {A_1 w/ CSV 1 block, OP_RETURN {blah, foo, bar}}
Version 2: A_0 -> {A_1 w/ CSV 1 block, OP_RETURN {blah, foo, bar, delta}}

and version 1 gets mined, then in A_1's spend you simply shift delta to
that (next) calendar.

A_1 -> {A_2 w/ CSV 1 block, OP_RETURN {delta}}

Thus my claim that someone sponsoring a old version only can delay by 1
block the calendar commit.





> OTS calendars can handle any of those versions getting mined. But older
> versions getting mined wastes money, as the remaining commitments still
> need to
> get mined in a subsequent transaction. Those remaining commitments are also
> 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
> entities
> use "in-place" replacement for update low-time-preference settlement
> transactions by adding new txouts and updating existing ones. Older
> versions of
> those settlement transactions getting mined rather than the newer version
> wastes money and delays settlement for the exact same reason it does in
> OTS.
>
>
> > 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.
>
>
It does save money since you had to pay to RBF, the N+1st txn will be
paying higher fee than the Nth. So if someone else sponsors an earlier
version, then you save whatever feerate/fee bumps you would have paid and
the funds are again in your change output (or something). You can apply
those change output savings to your next batch, which can include any
entries that have been dropped .

--000000000000aa684205d8759d3c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><div><div dir=3D"ltr" class=3D"gmail_sign=
ature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr">--<br><a href=3D=
"https://twitter.com/JeremyRubin" target=3D"_blank">@JeremyRubin</a><br></d=
iv></div></div><br></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" cl=
ass=3D"gmail_attr">On Sat, Feb 19, 2022 at 1:39 AM Peter Todd &lt;<a href=
=3D"mailto:pete@petertodd.org">pete@petertodd.org</a>&gt; wrote:<br></div><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);pa=
dding-left:1ex">On Fri, Feb 18, 2022 at 04:38:27PM -0800, Jeremy Rubin wrot=
e:<br>
&gt; &gt; As I said, it&#39;s a new kind of pinning attack, distinct from o=
ther types<br>
&gt; of pinning attack.<br>
&gt; <br>
&gt; I think pinning is &quot;formally defined&quot; as sequences of transa=
ctions which<br>
&gt; prevent or make it less likely for you to make any progress (in terms =
of<br>
&gt; units of computation proceeding).<br>
<br>
Mentioning &quot;computation&quot; when talking about transactions is misle=
ading:<br>
blockchain transactions have nothing to do with computation.<br></blockquot=
e><div><br></div><div><div class=3D"gmail_default" style=3D"font-family:ari=
al,helvetica,sans-serif;color:rgb(0,0,0)">It is in fact computation. Brandi=
ng it as &quot;misleading&quot; is misleading... The relevant literature is=
=C2=A0<a href=3D"https://en.wikipedia.org/wiki/Non-blocking_algorithm">http=
s://en.wikipedia.org/wiki/Non-blocking_algorithm</a>, sponsors helps get ri=
d of deadlocking so that any thread can be guaranteed to make progress. E.g=
., this is critical in Eltoo, which is effectively a coordinated multi-part=
y computation on-chain to compute the highest sequence number known by any =
worker.</div><div><div dir=3D"ltr" class=3D"gmail_signature"><div dir=3D"lt=
r"></div></div></div></div><div><br></div><div><div class=3D"gmail_default"=
 style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(=
0,0,0)">That transactions are blobs of &quot;verification&quot; (which is a=
lso itself a computation) less so than dynamic computations is irrelevant t=
o the fact that series of transactions do represent computations.</div><br>=
</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0p=
x 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-c=
olor:rgb(204,204,204);padding-left:1ex">
&gt; Something that only increases possibility to make progress cannot be<b=
r>
&gt; pinning.<br>
<br>
It is incorrect to say that all use-cases have the property that any versio=
n of<br>
a transaction being mined is progress.<br></blockquote><div><br></div><div>=
<div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-seri=
f;font-size:small;color:rgb(0,0,0)">It is progress, tautologically. Progres=
s is formally definable as a transaction of any kind getting mined. Pinning=
 prevents progress by an adversarial worker. Sponsoring enables progress, b=
ut it may not be your preferred interleaving. That&#39;s OK, but it&#39;s i=
naccurate to say it is not progress.</div></div><div class=3D"gmail_default=
" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb=
(0,0,0)"><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0p=
x 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color=
:rgb(204,204,204);padding-left:1ex">
Your understanding of how OpenTimestamps calendars work appears to be<br>
incorrect. There is no chain of unconfirmed transactions. Rather, OTS calen=
dars<br>
use RBF to _update_ the timestamp tx with a new merkle tip hash for to all<=
br>
outstanding per-second commitments once per new block. In high fee situatio=
ns<br>
it&#39;s normal for there to be dozens of versions of that same tx, each wi=
th a<br>
slightly higher feerate.<br></blockquote><div><br></div><div class=3D"gmail=
_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;c=
olor:rgb(0,0,0)">I didn&#39;t claim there to be a chain of unconfirmed, I c=
laimed that there could be single output chain that you&#39;re RBF&#39;ing =
one step per block.</div><div class=3D"gmail_default" style=3D"font-family:=
arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div=
 class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;fo=
nt-size:small;color:rgb(0,0,0)">E.g., it could be something like</div><div =
class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;fon=
t-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)=
">A_0 -&gt; {A_1 w/ CSV 1 block, OP_RETURN {blah, foo}}</div><div class=3D"=
gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:sm=
all;color:rgb(0,0,0)">A_1 -&gt; {A_2 w/ CSV 1 block, OP_RETURN {bar}}</div>=
<div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-seri=
f;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" =
style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0=
,0,0)">such that A_i provably can&#39;t have an unconfirmed descendant. The=
 notion would be that you&#39;re replacing one with another. E.g., if you&#=
39;re updating the calendar like:</div><div class=3D"gmail_default" style=
=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)=
"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,helveti=
ca,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gma=
il_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small=
;color:rgb(0,0,0)"><div class=3D"gmail_default">Version 0: A_0 -&gt; {A_1 w=
/ CSV 1 block, OP_RETURN {blah, foo}}</div><div class=3D"gmail_default">Ver=
sion 1: A_0 -&gt; {A_1 w/ CSV 1 block, OP_RETURN {blah, foo, bar}}</div><di=
v class=3D"gmail_default">Version 2: A_0 -&gt; {A_1 w/ CSV 1 block, OP_RETU=
RN {blah, foo, bar, delta}}</div><br class=3D"gmail-Apple-interchange-newli=
ne"></div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica=
,sans-serif;font-size:small;color:rgb(0,0,0)">and version 1 gets mined, the=
n in A_1&#39;s spend you simply shift delta to that (next) calendar.</div><=
div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif=
;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" s=
tyle=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,=
0,0)"><div class=3D"gmail_default">A_1 -&gt; {A_2 w/ CSV 1 block, OP_RETURN=
 {delta}}</div><br class=3D"gmail-Apple-interchange-newline"></div><div cla=
ss=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-s=
ize:small;color:rgb(0,0,0)">Thus my claim that someone sponsoring a old ver=
sion only can delay by 1 block the calendar commit.</div><div class=3D"gmai=
l_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;=
color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"font-fami=
ly:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><=
div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif=
;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" s=
tyle=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,=
0,0)"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,hel=
vetica,sans-serif;font-size:small;color:rgb(0,0,0)"></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;bo=
rder-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
<br>
OTS calendars can handle any of those versions getting mined. But older<br>
versions getting mined wastes money, as the remaining commitments still nee=
d to<br>
get mined in a subsequent transaction. Those remaining commitments are also=
<br>
delayed by the time it takes for the next tx to get mined.<br>
<br>
There are many use-cases beyond OTS with this issue. For example, some enti=
ties<br>
use &quot;in-place&quot; replacement for update low-time-preference settlem=
ent<br>
transactions by adding new txouts and updating existing ones. Older version=
s of<br>
those settlement transactions getting mined rather than the newer version<b=
r>
wastes money and delays settlement for the exact same reason it does in OTS=
.<br><br>
<br>
&gt; Lastly, if you do get &quot;necromanced&quot; on an earlier RBF&#39;d =
transaction by a<br>
&gt; third party for OTS, you should be relatively happy because it cost yo=
u<br>
&gt; less fees overall, since the undoing of your later RBF surely returned=
 some<br>
&gt; satoshis to your wallet.<br>
<br>
As I said above, no it doesn&#39;t.<br><br></blockquote><div><br></div><div=
 class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;fo=
nt-size:small;color:rgb(0,0,0)">It does save money since you had to pay to =
RBF, the N+1st txn will be paying higher fee than the Nth. So if someone el=
se sponsors an earlier version, then you save whatever feerate/fee bumps yo=
u would have paid and the funds are again in your change output (or somethi=
ng). You can apply those change output savings to your next batch, which ca=
n include any entries that have been dropped .</div></div></div>

--000000000000aa684205d8759d3c--