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
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
|
Return-Path: <fresheneesz@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137])
by lists.linuxfoundation.org (Postfix) with ESMTP id 10A4CC001A
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 26 Feb 2022 05:36:13 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id EC859408DA
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 26 Feb 2022 05:36:12 +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: smtp4.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=gmail.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 25jSUaHiGmGr
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 26 Feb 2022 05:36:11 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com
[IPv6:2a00:1450:4864:20::529])
by smtp4.osuosl.org (Postfix) with ESMTPS id DE0A9408B4
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 26 Feb 2022 05:36:10 +0000 (UTC)
Received: by mail-ed1-x529.google.com with SMTP id z22so10146538edd.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 25 Feb 2022 21:36:10 -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;
bh=6Sc+U9wnFh7r0r+MjyMfJD5rjwUQZshb1DPI2NVj8s0=;
b=YhhqfOzdsfQMrsDWI7OeujxQYXHzzvUvwhQSjkJ9Km/GtcGYeSZFQ4X9i5GhyerUfd
lXKL/IjrE6V0z7TxNw2caRt5jlDF7eZL7jgff9nuufj9y5WR27fS6rIYxtyyqjVXIOXX
2cO/U/cwOIESPyG3oqAcSMXc7p1PEKVDA1aa0RKro0joe7v9WniYwAzp2wuFcotglD+V
/ev6BcDQyb6oATWhOC41+a2yH28JjOg9+do0QWnJjbdK+7EwAMPZzSFmn9z1TF+tQDL+
cycF0b3teKJShOarxxIACib6bSKY6ElF+3/WnO4E639WKUjNO72/HjbpuG60gIRz1FVz
uXGg==
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;
bh=6Sc+U9wnFh7r0r+MjyMfJD5rjwUQZshb1DPI2NVj8s0=;
b=HdBrqkcBfn1llwkg0mNmkHUMxhbejSKFNpsFvubH1Ldrvl8ZM5W7QTwccoF3yepsm8
qqz1xib1Ki73xJdON0iER7/xsCdoP6vqYhkuqfxAuoBYrP5pn8fl8HKXiCUsXRo9/tXD
VuOHVTwmSsD9q4lbHBaItcZ4PstT9TpArScl9X433UY932TQeETQgtzjuqqXuyZoLSiN
0okUJ5yBMuYEIDqP3ew2tg+78yBCDl3tJw3Vbo6lLUeZgGdIvC+ULpPGxOjCV3L/wnXr
V1dOqQWtFxBY6omZLN5UxOyGmfQlmVGH64BZaYaGuNRHMA2euhaGVtwXmZiGa6GycVw6
T9iw==
X-Gm-Message-State: AOAM533nq9R3af6VTqvLYhpjZRbGEInJ6gZATVfRwH6nX4DKxE0R44ta
6T2OLm8rFvTi8ttPDgkaCDjA8HPB8YXmd5rCqS8ihNkU
X-Google-Smtp-Source: ABdhPJyUffYY98GdnB0sytSAK33OAMy4JmsWmfhrInq+bY+an+kELIJCqIznGBYaukympN9LzvlYMaeyYWXMPLkEm2g=
X-Received: by 2002:a05:6402:35c7:b0:412:f150:420e with SMTP id
z7-20020a05640235c700b00412f150420emr10151597edc.63.1645853768695; Fri, 25
Feb 2022 21:36:08 -0800 (PST)
MIME-Version: 1.0
References: <CAD5xwhjuHxdruCtOtHcSAc8EtW0O4HSLFdfPU1x8Y7Xa7LCnHQ@mail.gmail.com>
In-Reply-To: <CAD5xwhjuHxdruCtOtHcSAc8EtW0O4HSLFdfPU1x8Y7Xa7LCnHQ@mail.gmail.com>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Fri, 25 Feb 2022 23:35:51 -0600
Message-ID: <CAGpPWDbWKH56wad_JqDpWPmXA5Fh=JHDb+mN1owyTUKFdGf2Hw@mail.gmail.com>
To: Jeremy <jlrubin@mit.edu>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000003c42c305d8e5315f"
X-Mailman-Approved-At: Sat, 26 Feb 2022 08:34:24 +0000
Subject: Re: [bitcoin-dev] Documenting the lifetime of a transaction during
mempool congestion from the perspective of a rational user
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, 26 Feb 2022 05:36:13 -0000
--0000000000003c42c305d8e5315f
Content-Type: text/plain; charset="UTF-8"
The crux of the type of situation you're talking about is where a source
that might revert their payment by rbf double spending sends you money. You
mentioned this situation is "not unlikely". What kind of prevalence does
this happen with today?
Also my question is, if you've been paid by someone like this, what right
do you really have to this money? Is the other side buying something from
you? No one should be considering something actually bought unless it's got
sufficient confirmations. Anyone following that rule isn't losing anything
by simply waiting for the transaction to confirm. If the transaction is
double spent, who cares?
This seems like a situation where adding software and ui complexity is not
worth it to reach the maximization you're talking about. It feels more like
opportunistic stealing than actual commerce. Maybe it would be a social
good to prevent attempted scammers from scamming people, but the only
people who would be affected are 0 conf people. And that problem can be
solved much more easily and generally (eg by clear messaging around
transaction finalization) than by complicating coin selection.
On Thu, Jan 13, 2022, 15:07 Jeremy via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Devs,
>
> This email is primarily about existing wallet behaviors and user
> preferences, and not about CTV. However, towards the end I will describe
> the relevance of CTV, but the email is worth reading even if you have no
> interest in CTV as the problems described exist today.
>
> One point of confusion I've seen while discussing CTV based congestion
> control is that it requires a bunch of new wallet software.
>
> Most of the software requirements that would make CTV work well are things
> that either already exist in Bitcoin Core, or are 'bugs' (where bug is
> defined as deviation from rational utility maximizing behavior) that should
> be fixed *whether or not CTV exists.*
>
> In this post, I am going to walk through what I expect rational behavior
> to be for a not unlikely circumstance.
>
> First, let's define what rational behavior for a wallet is. A rational
> wallet should have a few goals:
>
> 1) Maximize 'fully trusted' balance (fully confirmed + unconfirmed change
> outputs from our own txns)
> 2) Process payments requested by the owner within the "urgency budget"
> requested by the user.
> 3) Maximize "privacy" (this is a vague goal, so we'll largely ignore it
> here.).
>
> Rational wallet behavior may not be possible without metadata. For
> example, a rational wallet might prompt the user for things like "how much
> do you trust the sender of this payment to not RBF this transaction?", or
> "how much do you trust this sender to not double spend you?". For example,
> a self-transfer from cold wallet to hot wallet could have a trust score of
> 1, whereas a payment from an anonymous source would have a trust score of
> 0. Exchanges where you have a legal agreement to not RBF might sit
> somewhere in between. Other pieces of exogenous information that could
> inform wallet behavior include "has hashrate decreased recently, making
> longer reorgs likely".
>
> In the model above, a user does not request transactions, they request
> payments. The rational wallet serves as an agent to assist the user in
> completing these payments. For example, if I have a wallet with a single
> unconfirmed output, and I spend from it to pay Alice, if the unconfirmed
> gets replaced, my wallet should track that it was replaced and prompt me to
> re-sign a new transaction. Rational wallets that maximize balance should be
> careful to ensure that replaced payments are exclusive, guaranteed either
> through sufficient confirmations or 'impossibility proofs' by reusing an
> input (preventing double-send behavior).
>
> -----------------------------
>
> Now that we've sketched out a basic framework for what a rational wallet
> should be doing, we can describe what the process of receiving a payment is.
>
> Suppose I have a wallet with a bevy of fully confirmed coins such that for
> my future payments I am sufficiently funded.
>
> Then, I receive a payment from a highly trusted source (e.g., self
> transfer) that is unconfirmed.
>
> I then seek to make an outgoing payment. I should have no preference
> towards or against spending the unconfirmed transfer, I should simply
> account for it's cost in coin selection of CPFP-ing the parent transaction.
> If fees are presently historically low, I may have a preference to spend it
> so as to not have a higher fee later (consolidation).
>
> Later, I receive payment from an untrusted source (e.g., an anonymous
> donation to me). I have no reason to trust this won't be double spent.
> Perhaps I can even observe that this output has been RBF'd many times
> previously. I do not count on this money arriving. The feerate on the
> transaction suggests it won't be confirmed immediately.
>
> In order to maximize balance, I should prioritize spending from this
> output (even if I don't have a payment I desire to make) in order to CPFP
> it to the top of the mempool and guarantee I am paid. This is inherently
> "free" since my cost to CPFP would be checked to be lower than the funds I
> am receiving, and I have no expected value to receive the payment if it is
> not confirmed. If I do have a transaction I desire to do, I should
> prioritize spending this output at that time. If not, I would do a CPFP
> just in favor of balance maximizing. Perhaps I can piggyback something
> useful, like speculatively opening a lightning channel.
>
> If I just self-spend to CPFP, it is very simple since the only party set
> up for disappointment is myself (note: I patched the behavior in this case
> to accurately *not* count this as a trusted balance in
> https://github.com/bitcoin/bitcoin/pull/16766, since a parent could
> disrupt this). However, if I try to make a payment, my wallet agent must
> somehow prompt me to re-sign or automatically sign an alternative payment
> once it is proven (e.g. 6 blocks) I won't receive the output, or to re-sign
> on a mutually exclusive output (e.g., fee bumping RBF) such that issuing
> two payments will not causes a double-send error. This adds complexity to
> both the user story and logic, but is still rational.
>
> Now, suppose that I receive a new payment from a **trusted** source that
> is a part of a "long chain". A long chain is a series of transactions that
> are all unconfirmed in the mempool. This long-chain is in the bottom of the
> mempool, and is not expected to confirm any time soon.
>
> My wallet should be configured such that it saves not only all ancestors
> of the transaction paying me, but also all descendants of the root
> unconfirmed transaction paying me. If I do not save all ancestor
> transactions, then it would be impossible for me to claim this payment at a
> future date, and would violate balance maximization. But why save
> descendants, if they do not concern me? Descendant transactions are
> critical for balance maximization. Someone else's spend of an output is a
> "free" CPFP subsidy for driving my transaction to completion (perhaps
> "descendants that increase the feerate of any parent" is the correct thing
> to save). Therefore if I want to maximize balance, I would rather keep
> these transactions around should I ever need to rebroadcast the
> transactions as it should be cheaper than having to CPFP by myself.
>
> Now, suppose that I receive a similar payment in a longchain from a series
> of untrusted sources. The same arguments apply, but now I may have even
> higher incentive to prioritize spending this coin since, if sender's trust
> scores are independent, my total trust in that payment is decomposed
> worst-case geometrically. It may not be a good assumption that trust scores
> are independent, since a long chain might be generated as e.g. a series of
> batch payments from one service provider.
>
> Briefly mentioned above is rebroadcasting. This is sort of an orthogonal
> behavior to the above, but it is "simple" to explain. Wallet agents should
> retransmit txns to the network if they believe other nodes are not aware of
> them and they are likely to go into a block. This encapsulates personal
> transactions as well as arbitrary transactions from third parties. There
> are many privacy implications of rebroadcasting that are out of scope for
> this post.
>
> -----------------
>
> All of the behaviors documented above are things that should happen today
> if you would like to have a rational wallet that maximizes your balance and
> makes payments.
>
> The reasons we don't do some of these things are, as far as I can tell:
>
> 1) Engineering Complexity
> 2) UX Complexity (simpler to make unconfirmed outputs "unspendable" to
> minimize transaction reissuing)
> 3) Mempool backlog is low, things are confirmed quickly if a sender pays a
> relatively low fee
>
> Certain wallets already have parts of this functionality baked in to an
> extent. For example, in Lightning Channels, you will drive payments to
> completion to prevent HTLC timeouts during contested closes (HTLCs == low
> trust score payments).
>
> Should Bitcoin see development of a more robust fee market, it is highly
> likely the rational behaviors described above would be emergent among all
> bitcoin wallets (who would want to use a Bitcoin wallet that gets you less
> money over time?). This email is not just a "Bitcoin Core" thing, hence not
> being an issue on Bitcoin Core where there are currently deviations from
> the above behaviors.
>
> -----------------
>
> What's CTV got to do with it?
>
> A common critique of congestion control using CTV is that it complicates
> wallet behavior because congestion control is designed to be useful in the
> circumstances above. CTV and congestion control do not cause these
> conditions. These conditions already exist whether or not we have
> congestion control.
>
> Where congestion control helps is that, in a world with a full mempool,
> you have fewer payments that are *actually* unconfirmed because exchanges
> that batch can fully confirm a constant sized root transaction and the
> sub-trees of transactions locked in by CTV can be treated as fully trusted.
> This helps reduce the need for the (rational) behavior of CPFP bumping your
> own payments on receipt from lower trust senders. Further, the expansion of
> the transaction tree can be done by other users receiving, so you have an
> incentive to wait for funds to mature as someone else might pay for
> expansion. These two factors mean that CTV congestion control can exert a
> dramatic back pressure on transaction urgency by unbundling the blockspace
> demand for spending and receiving coins. There are other synergies -- such
> as non-interactive channel opens -- that further improve the amount of
> reduction of time-preference in full on-chain resolution.
>
> I hope this email helps clarify why CTV Congestion Control isn't
> particularly creating a wallet architecture problem, it's helping to solve
> an existing one.
>
> Best,
>
> Jeremy
>
>
>
> --
> @JeremyRubin <https://twitter.com/JeremyRubin>
> <https://twitter.com/JeremyRubin>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--0000000000003c42c305d8e5315f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div dir=3D"auto">The crux of the type of situation you=
9;re talking about is where a source that might revert their payment by rbf=
double spending sends you money. You mentioned this situation is "not=
unlikely". What kind of prevalence does this happen with today?<div d=
ir=3D"auto"><br></div><div dir=3D"auto">Also my question is, if you've =
been paid by someone like this, what right do you really have to this money=
? Is the other side buying something from you? No one should be considering=
something actually bought unless it's got sufficient confirmations. An=
yone following that rule isn't losing anything by simply waiting for th=
e transaction to confirm. If the transaction is double spent, who cares?=C2=
=A0</div><div dir=3D"auto"><br></div><div dir=3D"auto">This seems like a si=
tuation where adding software and ui complexity is not worth it to reach th=
e maximization you're talking about. It feels more like opportunistic s=
tealing than actual commerce. Maybe it would be a social good to prevent at=
tempted scammers from scamming people, but the only people who would be aff=
ected are 0 conf people. And that problem can be solved much more easily an=
d generally (eg by clear messaging around transaction finalization) than by=
complicating coin selection.=C2=A0=C2=A0</div></div></div><br><div class=
=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Jan 13, 2022=
, 15:07 Jeremy via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linu=
xfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a=
>> wrote:<br></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"><di=
v dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,helve=
tica,sans-serif;font-size:small;color:rgb(0,0,0)">Devs,</div><div class=3D"=
gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:sm=
all;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)">This em=
ail is primarily about existing wallet behaviors and user preferences, and =
not about CTV. However, towards the end I will describe the relevance of CT=
V, but the email is worth reading even if you have no interest in CTV as th=
e problems described exist today.</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)">One point of confusion I=
9;ve seen while discussing CTV based congestion control is that it requires=
a bunch of new wallet software.</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;font-size:small;color:rgb(0,0,0)">Most of the software requireme=
nts that would make CTV work well are things that either already exist in B=
itcoin Core, or are 'bugs' (where bug is defined as deviation from =
rational utility maximizing behavior) that should be fixed <i>whether or no=
t CTV exists.</i></div><div class=3D"gmail_default" style=3D"font-family:ar=
ial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><i><br></i></div=
><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-ser=
if;font-size:small;color:rgb(0,0,0)">In this post, I am going to walk throu=
gh what I expect rational behavior to be for a not unlikely circumstance.</=
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_defau=
lt" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:r=
gb(0,0,0)">First, let's define what rational behavior for a wallet is. =
A rational wallet should have a few goals:</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;font-size:small;color:rgb(0,0,0)">1) Maximize 'ful=
ly trusted' balance (fully confirmed=C2=A0+ unconfirmed change outputs =
from our own txns)</div><div class=3D"gmail_default" style=3D"font-family:a=
rial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">2) Process paym=
ents requested by the owner within the "urgency budget" requested=
by the user.</div><div class=3D"gmail_default" style=3D"font-family:arial,=
helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">3) Maximize "pr=
ivacy" (this is a vague goal, so we'll largely ignore it here.).</=
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_defau=
lt" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:r=
gb(0,0,0)">Rational wallet behavior may not be possible without metadata. F=
or example, a rational wallet might prompt the user for things like "h=
ow much do you trust the sender of this payment to not RBF this transaction=
?", or "how much do you trust this sender to not double=C2=A0spen=
d you?". For example, a self-transfer from cold wallet to hot wallet c=
ould have a trust score of 1, whereas a payment from an anonymous source wo=
uld have a trust score of 0. Exchanges where you have a legal agreement to =
not RBF might sit somewhere in between. Other pieces of exogenous informati=
on that could inform wallet behavior include "has hashrate decreased r=
ecently, making longer reorgs likely".</div><div class=3D"gmail_defaul=
t" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rg=
b(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)">In the model above,=
a user does not request transactions, they request payments. The rational =
wallet serves as an agent to assist the user in completing these payments. =
For example, if I have a wallet with a single unconfirmed output, and I spe=
nd from it to pay Alice, if the unconfirmed gets replaced, my wallet should=
track that it was replaced and prompt me to re-sign a new transaction. Rat=
ional wallets that maximize balance should be careful to ensure that replac=
ed payments are exclusive, guaranteed either through sufficient confirmatio=
ns or 'impossibility proofs' by reusing an input (preventing double=
-send behavior).</div><div class=3D"gmail_default" style=3D"font-family:ari=
al,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div cl=
ass=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-=
size:small;color:rgb(0,0,0)">-----------------------------</div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"f=
ont-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Now=
that we've sketched out a basic framework for what a rational wallet s=
hould be doing, we can describe what the process of receiving a payment is.=
</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,san=
s-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_def=
ault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color=
:rgb(0,0,0)">Suppose I have a wallet with a bevy of fully confirmed coins s=
uch that for my future payments I am sufficiently funded.</div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"f=
ont-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">The=
n, I receive a payment from a highly trusted source (e.g., self transfer) t=
hat is unconfirmed.</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)">I then seek to make an outgoing payment. I =
should have no preference towards or against spending the unconfirmed trans=
fer, I should simply account for it's cost in coin selection of CPFP-in=
g the parent transaction. If fees are presently historically low, I may hav=
e a preference to spend it so as to not have a higher fee later (consolidat=
ion).</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetic=
a,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmai=
l_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;=
color:rgb(0,0,0)">Later, I receive=C2=A0payment from an untrusted source (e=
.g., an anonymous donation to me). I have no reason to trust this won't=
be double spent. Perhaps I can even observe that this output has been RBF&=
#39;d many times previously. I do not count on this money arriving. The fee=
rate on the transaction suggests it won't be confirmed immediately.</di=
v><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-se=
rif;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)">In order to maximize balance, I should prioritize spending from th=
is output (even if I don't have a payment I desire to make) in order to=
CPFP it to the top of the mempool and guarantee I am paid. This is inheren=
tly "free" since my cost to CPFP would be checked to be lower tha=
n the funds I am receiving, and I have no expected value to receive the pay=
ment if it is not confirmed. If I do have a transaction I desire to do, I s=
hould prioritize spending this output at that time. If not, I would do a CP=
FP just in favor of balance maximizing. Perhaps I can piggyback something u=
seful, like speculatively opening a lightning channel.</div><div class=3D"g=
mail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:sma=
ll;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"font-f=
amily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">If I jus=
t self-spend to CPFP, it is very simple since the only party set up for dis=
appointment is myself (note: I patched the behavior in this case to accurat=
ely *not* count this as a trusted balance in=C2=A0<a href=3D"https://github=
.com/bitcoin/bitcoin/pull/16766" rel=3D"noreferrer" target=3D"_blank">https=
://github.com/bitcoin/bitcoin/pull/16766</a>, since a parent could disrupt =
this). However, if I try to make a payment, my wallet agent must somehow pr=
ompt me to re-sign or automatically sign an alternative payment once it is =
proven (e.g. 6 blocks) I won't receive the output, or to re-sign on a m=
utually exclusive output (e.g., fee bumping RBF) such that issuing two paym=
ents will not causes a double-send error. This adds complexity to both the =
user story and logic, but is still rational.=C2=A0</div><div class=3D"gmail=
_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;c=
olor:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"font-famil=
y:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Now, suppose=
that I receive a new payment from =C2=A0a *<b>trusted</b>* source that is =
a part of a "long chain". A long chain is a series of transaction=
s that are all unconfirmed in the mempool. This long-chain is in the bottom=
of the mempool, and is not expected to confirm any time soon.</div><div cl=
ass=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;font-size:small;color:rgb(0,0,0)=
">My wallet should be configured such that it saves not only all ancestors =
of the transaction paying me, but also all descendants of the root unconfir=
med transaction paying me. If I do not save all ancestor transactions, then=
it would be impossible for me to claim this payment at a future date, and =
would violate balance maximization. But why save descendants, if they do no=
t concern me? Descendant transactions are critical for balance maximization=
. Someone else's spend of an output is a "free" CPFP subsidy =
for driving my transaction to completion (perhaps "descendants that in=
crease the feerate of any parent" is the correct thing to save). There=
fore if I want to maximize balance, I would rather keep these transactions =
around should I ever need to rebroadcast the transactions as it should be c=
heaper than having to CPFP by myself.</div><div class=3D"gmail_default" sty=
le=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,helve=
tica,sans-serif;font-size:small;color:rgb(0,0,0)">Now, suppose that I recei=
ve a similar payment in a longchain from a series of untrusted sources. The=
same arguments apply, but now I may have even higher incentive to prioriti=
ze spending this coin since, if sender's trust scores are independent, =
my total trust in that payment is decomposed worst-case geometrically. It m=
ay not be a good assumption that trust scores are independent, since a long=
chain might be generated as e.g. a series of batch payments from one servi=
ce provider.</div><div class=3D"gmail_default" style=3D"font-family:arial,h=
elvetica,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-siz=
e:small;color:rgb(0,0,0)">Briefly mentioned above is rebroadcasting. This i=
s sort of an orthogonal behavior to the above, but it is "simple"=
to explain. Wallet agents should retransmit txns to the network if they be=
lieve other nodes are not aware of them and they are likely to go into a bl=
ock. This encapsulates personal transactions as well as arbitrary transacti=
ons from third parties. There are many privacy implications of rebroadcasti=
ng that are out of scope for this post.</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>=
<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)">All of the behaviors documented above are things that should happen =
today if you would like to have a rational wallet that maximizes your balan=
ce and makes payments.</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)">The reasons we don't do some of thes=
e things are, as far as I can tell:</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)">1) Engineering Complexity</=
div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-=
serif;font-size:small;color:rgb(0,0,0)">2) UX Complexity (simpler to make u=
nconfirmed outputs "unspendable" to minimize transaction reissuin=
g)</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,s=
ans-serif;font-size:small;color:rgb(0,0,0)">3) Mempool backlog is low, thin=
gs are confirmed quickly if a sender pays a relatively low fee</div><div cl=
ass=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;font-size:small;color:rgb(0,0,0)=
">Certain wallets already have parts of this functionality baked in to an e=
xtent. For example, in Lightning Channels, you will drive payments to compl=
etion to prevent HTLC timeouts during contested closes (HTLCs =3D=3D low tr=
ust score payments).</div><div class=3D"gmail_default" style=3D"font-family=
:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><di=
v class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;f=
ont-size:small;color:rgb(0,0,0)">Should Bitcoin see development of a more r=
obust fee market, it is highly likely the rational behaviors described abov=
e would be emergent among all bitcoin wallets (who would want to use a Bitc=
oin wallet that gets you less money over time?). This email is not just a &=
quot;Bitcoin Core" thing, hence not being an issue on Bitcoin Core whe=
re there are currently deviations from the above behaviors.</div><div class=
=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-siz=
e:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"f=
ont-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">---=
--------------</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 clas=
s=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-si=
ze:small;color:rgb(0,0,0)">What's CTV got to do with it?</div><div clas=
s=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-si=
ze: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 =
common critique of congestion control using CTV is that it complicates wall=
et behavior because congestion control is designed to be useful in the circ=
umstances above. CTV and congestion control do not cause these conditions. =
These conditions already exist whether or not we have congestion control.</=
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_defau=
lt" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:r=
gb(0,0,0)">Where congestion control helps is that, in a world with a full m=
empool, you have fewer payments that are *actually* unconfirmed because exc=
hanges that batch can fully confirm a constant sized root transaction and t=
he sub-trees of transactions locked in by CTV can be treated as fully trust=
ed. This helps reduce the need for the (rational) behavior of CPFP bumping =
your own payments on receipt from lower trust senders. Further, the expansi=
on of the transaction tree can be done by other users receiving, so you hav=
e an incentive to wait for funds to mature as someone else might pay for ex=
pansion. These two factors mean that CTV congestion control can exert a dra=
matic back pressure on transaction urgency by unbundling the blockspace dem=
and for spending and receiving coins. There are other synergies -- such as =
non-interactive channel opens -- that further improve the amount of reducti=
on of time-preference in full on-chain resolution.</div><div class=3D"gmail=
_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;c=
olor:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"font-famil=
y:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">I hope this =
email helps clarify why CTV Congestion Control isn't particularly creat=
ing a wallet architecture problem, it's helping to solve an existing on=
e.</div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,s=
ans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_d=
efault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;col=
or:rgb(0,0,0)">Best,</div><div class=3D"gmail_default" style=3D"font-family=
:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><di=
v class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;f=
ont-size:small;color:rgb(0,0,0)">Jeremy</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)"><br></div><br clear=3D"=
all"><div><div dir=3D"ltr"><div dir=3D"ltr">--<br><a href=3D"https://twitte=
r.com/JeremyRubin" rel=3D"noreferrer" target=3D"_blank">@JeremyRubin</a><a =
href=3D"https://twitter.com/JeremyRubin" rel=3D"noreferrer" target=3D"_blan=
k"></a></div></div></div></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"noreferrer"=
target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>
--0000000000003c42c305d8e5315f--
|