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
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
|
Return-Path: <fresheneesz@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 135B5C002F;
Wed, 19 Jan 2022 16:52:10 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id EE8B8607F0;
Wed, 19 Jan 2022 16:52:09 +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: smtp3.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp3.osuosl.org ([127.0.0.1])
by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id 9ig1Jsz4Pu3w; Wed, 19 Jan 2022 16:52:07 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ed1-x531.google.com (mail-ed1-x531.google.com
[IPv6:2a00:1450:4864:20::531])
by smtp3.osuosl.org (Postfix) with ESMTPS id 82A7A607EC;
Wed, 19 Jan 2022 16:52:07 +0000 (UTC)
Received: by mail-ed1-x531.google.com with SMTP id u18so891208edt.6;
Wed, 19 Jan 2022 08:52:07 -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=IusVIW61tTGUB/DUCECozLE34mOnlyKAC0GrGZwwjwU=;
b=NTwFidT6RYI3PQMD4P/OUYidwUiT6ktDefCRgrjWEW2RoV5zpvm1OSkxPY9ngjkVTv
s+F69IiJKOj/lis2mluAWfjiTlppAnAiLtcM3Z2aPCxIskn+DvWNJWQYX4oANIOUY27M
yyIiEG62vdi9+4wLza1PdUJIZet3di4m1bpO0THK+Q4rzfxPsf5ruEnh6K6xULApsyu/
YN5ljXo0O5cI74SNgq+CA0weBdhLrc/Lpd/9k3y1CNHIzYbiiTc7MXpUNKyEaM7apsfG
pIZfwsFe5R5JXmGY1YPcH2iNWYxSGBwdrXQMa2FaziywikcfCL53E46S0FNMGFPeOZUW
GhvA==
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=IusVIW61tTGUB/DUCECozLE34mOnlyKAC0GrGZwwjwU=;
b=XYWJz1auIA1irgO2CPHrIwoMJKVS40JQoV7f5fWIHhE7s3Fl6fOq24dLf3AAw3q+4w
nhcDYyj/UAIhCQBg0GzsRl3YZh6fW+i+4bGqFK+G84FH24qLsvDe9dnzDzazowAyuMRd
gbqm2G6uEXIzaiES6jyVauIi2pLVAedxaTJLcQyaXkrm0JCy56kYMVOD22Syy0zyCypp
5zEhxrDDEReoqXDgK1moljLfmsszF9NWTy2HGPx2qZxiwepHgBK42DRlIY60G/wq9yv0
vsFyu9pRL9pXoy82PSeZSMPSe2ZySiVJ9aE335b1ZIZS2lHVTIxqOo3JYoHececFJe7y
7eyw==
X-Gm-Message-State: AOAM5332nXJzwVjKMs4l6GspZKqKe9ujMINzv2JoTVpURqJC2fFWuxNT
q3yhARUvj/9AAPzKVcL1da9fBEnC0bUr1168SMHuOVmcXeI=
X-Google-Smtp-Source: ABdhPJyVLzEcG4ggiFRrzQJEqAzJwE+QJyE53CeZ50timc1o3JIEaH4n2FIj2h1VPSDD8q2BRexqs5vAn+w+PYdG6hc=
X-Received: by 2002:a17:906:2bcf:: with SMTP id
n15mr24201694ejg.184.1642611125426;
Wed, 19 Jan 2022 08:52:05 -0800 (PST)
MIME-Version: 1.0
References: <CAD5xwhik6jVQpP2_ss7d5o+pPLsqDCHuaXG41AMKHVYhZMXF1w@mail.gmail.com>
<CAGpPWDb6HckAhX6p-=cK3fQXyMqivd+xFtiYJ7hKR2k-MWqKJA@mail.gmail.com>
<CAD5xwhhuvHL2_-ZY1ygZ6WahRi9eg9rk2eHDUODNoJCQX6wL+A@mail.gmail.com>
<CAGpPWDaQAxEfyFs_g9p=PTUNAkSiQKwPiHJbBaLmzfNTjFeucA@mail.gmail.com>
<CAD5xwhjUkey+VD=u+69+5eirLCCoLgDgAR_4d20hwHo-eyZr6w@mail.gmail.com>
<CAGpPWDYxCGkpbiiHFgFrY3=oCwRBY7c_vLQfQg3a_Dwx7pEUTA@mail.gmail.com>
<CAD5xwhhbXZPg+rQjdaygv_6ZsNuuVpibu=LTZBNU4g_naBOWyw@mail.gmail.com>
In-Reply-To: <CAD5xwhhbXZPg+rQjdaygv_6ZsNuuVpibu=LTZBNU4g_naBOWyw@mail.gmail.com>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Wed, 19 Jan 2022 10:51:48 -0600
Message-ID: <CAGpPWDbPptac9UPM45_eWnmgDgeoyc=KxuQs1x7_vk37uarsLA@mail.gmail.com>
To: Jeremy <jlrubin@mit.edu>
Content-Type: multipart/alternative; boundary="000000000000a2a30405d5f23406"
X-Mailman-Approved-At: Wed, 19 Jan 2022 17:04:01 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
lightning-dev <lightning-dev@lists.linuxfoundation.org>
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: Wed, 19 Jan 2022 16:52:10 -0000
--000000000000a2a30405d5f23406
Content-Type: text/plain; charset="UTF-8"
Hmm, I don't know anything about SIGHASH_BUNDLE. The only references
online I can find are just mentions (mostly from you). What is
SIGHASH_BUNDLE?
> unless you're binding a WTXID
That could work, but it would exclude cases where you have a transaction
that has already been partially signed and someone wants to, say, only sign
that transaction if some 3rd party signs a transaction paying part of the
fee for it. Kind of a niche use case, but it would be nice to support it if
possible. If the transaction hasn't been signed at all yet, a new
transaction can just be created that includes the prospective fee-payer,
and if the transaction is fully signed then it has a WTXID to use.
> then you can have fee bumping cycles
What kind of cycles do you mean? You're saying these cycles would make it
less robust to reorgs?
> OP_VER
I assume you mean something other than pushing the version onto the stack
<https://bitcoin.stackexchange.com/questions/97258/given-op-ver-was-never-used-is-disabled-and-not-considered-useful-can-its-meani>?
Is that related to your fee account idea?
On Wed, Jan 19, 2022 at 1:32 AM Jeremy <jlrubin@mit.edu> wrote:
> Ah my bad i misread what you were saying as being about SIGHASH_BUNDLE
> like proposals.
>
> For what you're discussing, I previously proposed
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.html
> which is similar.
>
> The benefit of the OP_VER output is that SIGHASH_EXTERNAL has the issue
> that unless you're binding a WTXID (which is maybe too specific?) then you
> can have fee bumping cycles. Doing OP_VER output w/ TXID guarantees that
> you are acyclic.
>
> The difference between a fee account and this approach basically boils
> down to the impact on e.g. reorg stability, where the deposit/withdraw
> mechanism is a bit more "robust" for reorderings in reorgs than the in-band
> transaction approach, although they are very similar.
>
> --
> @JeremyRubin <https://twitter.com/JeremyRubin>
> <https://twitter.com/JeremyRubin>
>
>
> On Tue, Jan 18, 2022 at 8:53 PM Billy Tetrud <billy.tetrud@gmail.com>
> wrote:
>
>> > because you make transactions third party malleable it becomes
>> possible to bundle and unbundle transactions.
>>
>> What I was suggesting doesn't make it possible to malleate someone else's
>> transaction. I guess maybe my proposal of using a sighash flag might
>> have been unclear. Imagine it as a script opcode that just says "this
>> transaction must be mined with this other transaction" - the only
>> difference being that you can use any output with any encumberance as an
>> input for fee bumping. It doesn't prevent the original transaction from
>> being mined on its own. So adding junk inputs would be no more of a problem
>> than dust attacks already are. It would be used exactly like cpfp, except
>> it doesn't spend the parent.
>>
>> I don't think what I was suggesting is as different from your proposal.
>> All the problems of fee revenue optimization and feerate rules that you
>> mentioned seem like they'd also exist for your proposal, or for cpfp. Let
>> me know if I should clarify further.
>>
>> On Tue, Jan 18, 2022 at 8:51 PM Jeremy <jlrubin@mit.edu> wrote:
>>
>>> The issue with sighash flags is that because you make transactions third
>>> party malleable it becomes possible to bundle and unbundle transactions.
>>>
>>> This means there are circumstances where an attacker could e.g. see your
>>> txn, and then add a lot of junk change/inputs + 25 descendants and strongly
>>> anchor your transaction to the bottom of the mempool.
>>>
>>> because of rbf rules requiring more fee and feerate, this means you have
>>> to bump across the whole package and that can get really messy.
>>>
>>> more generally speaking, you could imagine a future where mempools track
>>> many alternative things that might want to be in a transaction.
>>>
>>> suppose there are N inputs each with a weight and an amount of fee being
>>> added and the sighash flags let me pick any subset of them. However, for a
>>> txn to be standard it must be < 100k bytes and for it to be consensus <
>>> 1mb. Now it is possible you have to solve a knapsack problem in order to
>>> rationally bundle this transaction out of all possibilities.
>>>
>>> This problem can get even thornier, suppose that the inputs I'm adding
>>> themselves are the outputs of another txn in the mempool, now i have to
>>> track and propagate the feerates of that child back up to the parent txn
>>> and track all these dependencies.
>>>
>>> perhaps with very careful engineering these issues can be tamed. however
>>> it seems with sponsors or fee accounts, by separating the pays-for from the
>>> participates-in concerns we can greatly simplify it to something like:
>>> compute effective feerate for a txn, including all sponsors that pay more
>>> than the feerate of the base txn. Mine that txn and it's subsidies using
>>> the normal algo. If you run out of space, all subsidies are same-sized so
>>> just take the ones that pay the highest amount up until the added marginal
>>> feerate is less than the next eligible txn.
>>>
>>>
>>> --
>>> @JeremyRubin <https://twitter.com/JeremyRubin>
>>> <https://twitter.com/JeremyRubin>
>>>
>>>
>>> On Tue, Jan 18, 2022 at 6:38 PM Billy Tetrud <billy.tetrud@gmail.com>
>>> wrote:
>>>
>>>> I see, its not primarily to make it cheaper to append fees, but also
>>>> allows appending fees in cases that aren't possible now. Is that right? I
>>>> can certainly see the benefit of a more general way to add a fee to any
>>>> transaction, regardless of whether you're related to that transaction or
>>>> not.
>>>>
>>>> How would you compare the pros and cons of your account-based approach
>>>> to something like a new sighash flag? Eg a sighash flag that says "I'm
>>>> signing this transaction, but the signature is only valid if mined in the
>>>> same block as transaction X (or maybe transactions LIST)". This could be
>>>> named SIGHASH_EXTERNAL. Doing this would be a lot more similar to other
>>>> bitcoin transactions, and no special account would need to be created. Any
>>>> transaction could specify this. At least that's the first thought I would
>>>> have in designing a way to arbitrarily bump fees. Have you compared your
>>>> solution to something more familiar like that?
>>>>
>>>> On Tue, Jan 18, 2022 at 11:43 AM Jeremy <jlrubin@mit.edu> wrote:
>>>>
>>>>> Can you clarify what you mean by "improve the situation"?
>>>>>
>>>>> There's a potential mild bytes savings, but the bigger deal is that
>>>>> the API should be much less vulnerable to pinning issues, fix dust leakage
>>>>> for eltoo like protocols, and just generally allow protocol designs to be
>>>>> fully abstracted from paying fees. You can't easily mathematically
>>>>> quantify API improvements like that.
>>>>> --
>>>>> @JeremyRubin <https://twitter.com/JeremyRubin>
>>>>> <https://twitter.com/JeremyRubin>
>>>>>
>>>>>
>>>>> On Tue, Jan 18, 2022 at 8:13 AM Billy Tetrud <billy.tetrud@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Do you have any back-of-the-napkin math on quantifying how much this
>>>>>> would improve the situation vs existing methods (eg cpfp)?
>>>>>>
>>>>>>
>>>>>>
>>>>>> On Sat, Jan 1, 2022 at 2:04 PM Jeremy via bitcoin-dev <
>>>>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>>>>
>>>>>>> Happy new years devs,
>>>>>>>
>>>>>>> I figured I would share some thoughts for conceptual review that
>>>>>>> have been bouncing around my head as an opportunity to clean up the fee
>>>>>>> paying semantics in bitcoin "for good". The design space is very wide on
>>>>>>> the approach I'll share, so below is just a sketch of how it could work
>>>>>>> which I'm sure could be improved greatly.
>>>>>>>
>>>>>>> Transaction fees are an integral part of bitcoin.
>>>>>>>
>>>>>>> However, due to quirks of Bitcoin's transaction design, fees are a
>>>>>>> part of the transactions that they occur in.
>>>>>>>
>>>>>>> While this works in a "Bitcoin 1.0" world, where all transactions
>>>>>>> are simple on-chain transfers, real world use of Bitcoin requires support
>>>>>>> for things like Fee Bumping stuck transactions, DoS resistant Payment
>>>>>>> Channels, and other long lived Smart Contracts that can't predict future
>>>>>>> fee rates. Having the fees paid in band makes writing these contracts much
>>>>>>> more difficult as you can't merely express the logic you want for the
>>>>>>> transaction, but also the fees.
>>>>>>>
>>>>>>> Previously, I proposed a special type of transaction called a
>>>>>>> "Sponsor" which has some special consensus + mempool rules to allow
>>>>>>> arbitrarily appending fees to a transaction to bump it up in the mempool.
>>>>>>>
>>>>>>> As an alternative, we could establish an account system in Bitcoin
>>>>>>> as an "extension block".
>>>>>>>
>>>>>>> *Here's how it might work:*
>>>>>>>
>>>>>>> 1. Define a special anyone can spend output type that is a "fee
>>>>>>> account" (e.g. segwit V2). Such outputs have a redeeming key and an amount
>>>>>>> associated with them, but are overall anyone can spend.
>>>>>>> 2. All deposits to these outputs get stored in a separate UTXO
>>>>>>> database for fee accounts
>>>>>>> 3. Fee accounts can sign only two kinds of transaction: A: a fee
>>>>>>> amount and a TXID (or Outpoint?); B: a withdraw amount, a fee, and
>>>>>>> an address
>>>>>>> 4. These transactions are committed in an extension block merkle
>>>>>>> tree. While the actual signature must cover the TXID/Outpoint, the
>>>>>>> committed data need only cover the index in the block of the transaction.
>>>>>>> The public key for account lookup can be recovered from the message +
>>>>>>> signature.
>>>>>>> 5. In any block, any of the fee account deposits can be: released
>>>>>>> into fees if there is a corresponding tx; consolidated together to reduce
>>>>>>> the number of utxos (this can be just an OP_TRUE no metadata needed); or
>>>>>>> released into fees *and paid back* into the requested withdrawal key
>>>>>>> (encumbering a 100 block timeout). Signatures must be unique in a block.
>>>>>>> 6. Mempool logic is updated to allow attaching of account fee spends
>>>>>>> to transactions, the mempool can restrict that an account is not allowed
>>>>>>> more spend more than it's balance.
>>>>>>>
>>>>>>> *But aren't accounts "bad"?*
>>>>>>>
>>>>>>> Yes, accounts are bad. But these accounts are not bad, because any
>>>>>>> funds withdrawn from the fee extension are fundamentally locked for 100
>>>>>>> blocks as a coinbase output, so there should be no issues with any series
>>>>>>> of reorgs. Further, since there is no "rich state" for these accounts, the
>>>>>>> state updates can always be applied in a conflict-free way in any order.
>>>>>>>
>>>>>>>
>>>>>>> *Improving the privacy of this design:*
>>>>>>>
>>>>>>> This design could likely be modified to implement something like
>>>>>>> Tornado.cash or something else so that the fee account paying can be
>>>>>>> unlinked from the transaction being paid for, improving privacy at the
>>>>>>> expense of being a bit more expensive.
>>>>>>>
>>>>>>> Other operations could be added to allow a trustless mixing to be
>>>>>>> done by miners automatically where groups of accounts with similar values
>>>>>>> are trustlessly split into a common denominator and change, and keys are
>>>>>>> derived via a verifiable stealth address like protocol (so fee balances can
>>>>>>> be discovered by tracing the updates posted). These updates could also be
>>>>>>> produced by individuals rather than miners, and miners could simply honor
>>>>>>> them with better privacy. While a miner generating an update would be able
>>>>>>> to deanonymize their mixes, if you have your account mixed several times by
>>>>>>> independent miners that could potentially add sufficient privacy.
>>>>>>>
>>>>>>> The LN can also be used with PTLCs to, in theory, have another
>>>>>>> individual paid to sponsor a transaction on your behalf only if they reveal
>>>>>>> a valid sig from their fee paying account, although under this model it's
>>>>>>> hard to ensure that the owner doesn't pay a fee and then 'cancel' by
>>>>>>> withdrawing the rest. However, this could be partly solved by using
>>>>>>> reputable fee accounts (reputation could be measured somewhat
>>>>>>> decentralized-ly by longevity of the account and transactions paid for
>>>>>>> historically).
>>>>>>>
>>>>>>> *Scalability*
>>>>>>>
>>>>>>> This design is fundamentally 'decent' for scalability because adding
>>>>>>> fees to a transaction does not require adding inputs or outputs and does
>>>>>>> not require tracking substantial amounts of new state.
>>>>>>>
>>>>>>> Paying someone else to pay for you via the LN also helps make this
>>>>>>> more efficient if the withdrawal issues can be fixed.
>>>>>>>
>>>>>>> *Lightning:*
>>>>>>>
>>>>>>> This type of design works really well for channels because the
>>>>>>> addition of fees to e.g. a channel state does not require any sort of
>>>>>>> pre-planning (e.g. anchors) or transaction flexibility (SIGHASH flags).
>>>>>>> This sort of design is naturally immune to pinning issues since you could
>>>>>>> offer to pay a fee for any TXID and the number of fee adding offers does
>>>>>>> not need to be restricted in the same way the descendant transactions would
>>>>>>> need to be.
>>>>>>>
>>>>>>> *Without a fork?*
>>>>>>>
>>>>>>> This type of design could be done as a federated network that bribes
>>>>>>> miners -- potentially even retroactively after a block is formed. That
>>>>>>> might be sufficient to prove the concept works before a consensus upgrade
>>>>>>> is deployed, but such an approach does mean there is a centralizing layer
>>>>>>> interfering with normal mining.
>>>>>>>
>>>>>>>
>>>>>>> Happy new year!!
>>>>>>>
>>>>>>> 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
>>>>>>>
>>>>>>
--000000000000a2a30405d5f23406
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">Hmm, I don't know anything about=C2=A0
SIGHASH_BUNDLE. The only references online I can find are just mentions (mo=
stly from you). What is=C2=A0
SIGHASH_BUNDLE?<div><br></div><div>> unless you're binding a WTXID</=
div><div><br></div><div>That could work, but it would exclude cases where y=
ou have a transaction that has already been partially signed and someone wa=
nts to, say, only sign that transaction if some 3rd party signs a transacti=
on paying part of the fee for it. Kind of a niche use case, but it would be=
nice to support it if possible. If the transaction hasn't been signed =
at all yet, a new transaction can just be created that includes the prospec=
tive fee-payer, and if the transaction is fully signed then it has a WTXID =
to use.</div><div><br></div><div>> then you can have fee bumping cycles<=
/div><div><br></div><div>What kind of cycles do you mean? You're saying=
these cycles would make it less robust to reorgs?</div><div><br></div><div=
>> OP_VER</div><div><br></div><div>I assume you mean something other tha=
n <a href=3D"https://bitcoin.stackexchange.com/questions/97258/given-op-ver=
-was-never-used-is-disabled-and-not-considered-useful-can-its-meani">pushin=
g the version onto the stack</a>? Is that related to your fee account idea?=
</div><div><br></div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" =
class=3D"gmail_attr">On Wed, Jan 19, 2022 at 1:32 AM Jeremy <<a href=3D"=
mailto:jlrubin@mit.edu">jlrubin@mit.edu</a>> wrote:<br></div><blockquote=
class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px so=
lid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail=
_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;c=
olor:rgb(0,0,0)"><span style=3D"font-family:Arial,Helvetica,sans-serif;colo=
r:rgb(34,34,34)">Ah my bad i misread what you were saying as being about SI=
GHASH_BUNDLE like proposals.</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-size:small">F=
or what you're discussing, I previously proposed=C2=A0<a href=3D"https:=
//lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-September/018168.htm=
l" target=3D"_blank">https://lists.linuxfoundation.org/pipermail/bitcoin-de=
v/2020-September/018168.html</a> which is similar.</div><div class=3D"gmail=
_default" style=3D"font-size:small"><br></div><div class=3D"gmail_default" =
style=3D"font-size:small">The benefit of the OP_VER output is that SIGHASH_=
EXTERNAL has the issue that unless you're binding a WTXID (which is may=
be too specific?) then you can have fee bumping cycles. Doing OP_VER output=
w/ TXID guarantees that you are acyclic.</div><div class=3D"gmail_default"=
style=3D"font-size:small"><br></div><div class=3D"gmail_default" style=3D"=
font-size:small">The difference between a fee account and this approach bas=
ically boils down to the impact on e.g. reorg stability, where the deposit/=
withdraw mechanism is a bit more "robust" for reorderings in reor=
gs than the in-band transaction approach, although they are very similar.</=
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,He=
lvetica,sans-serif;color:rgb(34,34,34)"><br></span></div><div class=3D"gmai=
l_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;col=
or:rgb(34,34,34)">--</span><br></div><div><div dir=3D"ltr"><div dir=3D"ltr"=
><a href=3D"https://twitter.com/JeremyRubin" target=3D"_blank">@JeremyRubin=
</a><a href=3D"https://twitter.com/JeremyRubin" target=3D"_blank"></a></div=
></div></div><br></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" clas=
s=3D"gmail_attr">On Tue, Jan 18, 2022 at 8:53 PM Billy Tetrud <<a href=
=3D"mailto:billy.tetrud@gmail.com" target=3D"_blank">billy.tetrud@gmail.com=
</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">=
<div dir=3D"ltr">>=C2=A0
<span style=3D"color:rgb(0,0,0);font-family:arial,helvetica,sans-serif">bec=
ause you make transactions third party malleable it becomes possible to bun=
dle and unbundle transactions.</span><div><span style=3D"color:rgb(0,0,0);f=
ont-family:arial,helvetica,sans-serif"><br></span></div><div><span style=3D=
"color:rgb(0,0,0);font-family:arial,helvetica,sans-serif">What I was sugges=
ting doesn't make it possible to malleate someone else's transactio=
n.=C2=A0</span><span style=3D"color:rgb(0,0,0);font-family:arial,helvetica,=
sans-serif">I guess maybe my proposal of using a sighash flag might have be=
en unclear. Imagine it as a script opcode that just says "this transac=
tion=C2=A0must be mined with this other transaction" - the only differ=
ence being that you can use any output with any encumberance=C2=A0as an inp=
ut for fee=C2=A0bumping. It doesn't prevent the original transaction fr=
om being mined on its own. So adding junk inputs would be no more of a prob=
lem than dust attacks already are. It would be used exactly like cpfp, exce=
pt it doesn't spend the parent.=C2=A0</span></div><div><span style=3D"c=
olor:rgb(0,0,0);font-family:arial,helvetica,sans-serif"><br></span></div><d=
iv><span style=3D"color:rgb(0,0,0);font-family:arial,helvetica,sans-serif">=
I don't think what I was suggesting is as different from your proposal.=
All the problems of fee revenue optimization and feerate rules that you me=
ntioned seem like they'd also exist for your proposal, or for cpfp. Let=
me know if I should clarify further.=C2=A0</span></div></div><br><div clas=
s=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Jan 18, 202=
2 at 8:51 PM Jeremy <<a href=3D"mailto:jlrubin@mit.edu" target=3D"_blank=
">jlrubin@mit.edu</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);p=
adding-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_default" style=3D"fon=
t-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">The i=
ssue with sighash flags is that because you make transactions third party m=
alleable it becomes possible to bundle and unbundle transactions.</div><div=
class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;fo=
nt-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" styl=
e=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0=
)">This means there are circumstances where an attacker could e.g. see your=
txn, and then add a lot of junk change/inputs=C2=A0+ 25 descendants and st=
rongly anchor your transaction to the bottom of the mempool.</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)">be=
cause of rbf rules requiring more fee and feerate, this means you have to b=
ump across the whole package and that can get really messy.</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)">mor=
e generally speaking, you could imagine a future where mempools track many =
alternative things that might want to be in a transaction.</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)">sup=
pose there are N inputs each with a weight and an amount of fee being added=
and the sighash flags let me pick any subset of them. However, for a txn t=
o be standard it must be < 100k bytes and for it to be consensus < 1m=
b. Now it is possible you have to solve a knapsack problem in order to rati=
onally bundle this transaction out of all possibilities.</div><div class=3D=
"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:s=
mall;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 p=
roblem can get even thornier, suppose that the inputs I'm adding themse=
lves are the outputs of another txn in the mempool, now i have to track and=
propagate the feerates of that child back up to the parent txn and track a=
ll these dependencies.</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)">perhaps with very careful engineering th=
ese issues can be tamed. however it seems with sponsors or fee accounts, by=
separating the pays-for from the participates-in concerns we can greatly s=
implify it to something like: compute effective feerate for a txn, includin=
g all sponsors that pay more than the feerate of the base txn. Mine that tx=
n and it's subsidies using the normal algo. If you run out of space, al=
l subsidies are same-sized so just take the ones that pay the highest amoun=
t up until the added marginal feerate is less than the next eligible txn.</=
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)"><br></div><div><div dir=3D"ltr"><div dir=3D"ltr">--<br><a href=
=3D"https://twitter.com/JeremyRubin" target=3D"_blank">@JeremyRubin</a><a h=
ref=3D"https://twitter.com/JeremyRubin" target=3D"_blank"></a></div></div><=
/div><br></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gma=
il_attr">On Tue, Jan 18, 2022 at 6:38 PM Billy Tetrud <<a href=3D"mailto=
:billy.tetrud@gmail.com" target=3D"_blank">billy.tetrud@gmail.com</a>> w=
rote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=
=3D"ltr">I see, its not primarily to make it cheaper to append fees, but al=
so allows appending fees in cases that aren't possible now. Is that rig=
ht? I can certainly see the benefit of a more general way to add a fee to a=
ny transaction, regardless of whether you're related to that transactio=
n or not.=C2=A0<div><br></div><div>How would you compare the pros and cons =
of your account-based approach to something like a new sighash flag? Eg a s=
ighash flag that says "I'm signing this transaction, but the signa=
ture is only valid if mined in the same block as transaction=C2=A0X (or may=
be transactions LIST)". This could be named SIGHASH_EXTERNAL. Doing th=
is would be a lot more similar to other bitcoin transactions, and no specia=
l account would need to be created. Any transaction could specify this. At =
least that's the first thought I would have in designing a way to arbit=
rarily bump fees. Have you compared your solution to something more familia=
r like that?</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr" cla=
ss=3D"gmail_attr">On Tue, Jan 18, 2022 at 11:43 AM Jeremy <<a href=3D"ma=
ilto:jlrubin@mit.edu" target=3D"_blank">jlrubin@mit.edu</a>> wrote:<br><=
/div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bo=
rder-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><di=
v class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;f=
ont-size:small;color:rgb(0,0,0)">Can you clarify what you mean by "imp=
rove the situation"?</div><div class=3D"gmail_default" style=3D"font-f=
amily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></di=
v><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-se=
rif;font-size:small;color:rgb(0,0,0)">There's a potential mild bytes sa=
vings, but the bigger deal is that the API should be much less vulnerable t=
o pinning issues, fix dust leakage for eltoo like protocols, and just gener=
ally allow protocol designs to be fully abstracted from paying fees. You ca=
n't easily mathematically quantify=C2=A0API improvements=C2=A0like that=
.</div><div><div dir=3D"ltr"><div dir=3D"ltr">--<br><a href=3D"https://twit=
ter.com/JeremyRubin" target=3D"_blank">@JeremyRubin</a><a href=3D"https://t=
witter.com/JeremyRubin" target=3D"_blank"></a></div></div></div><br></div><=
br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue,=
Jan 18, 2022 at 8:13 AM Billy Tetrud <<a href=3D"mailto:billy.tetrud@gm=
ail.com" target=3D"_blank">billy.tetrud@gmail.com</a>> wrote:<br></div><=
blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-l=
eft:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div>Do y=
ou have any back-of-the-napkin math on quantifying=C2=A0how much this would=
improve the situation vs existing methods (eg cpfp)?</div><div><br></div><=
div><span style=3D"color:rgb(0,0,0);font-family:arial,helvetica,sans-serif"=
></span></div><div><span style=3D"color:rgb(0,0,0);font-family:arial,helvet=
ica,sans-serif"><br></span></div></div><br><div class=3D"gmail_quote"><div =
dir=3D"ltr" class=3D"gmail_attr">On Sat, Jan 1, 2022 at 2:04 PM Jeremy via =
bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" ta=
rget=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br></d=
iv><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;bord=
er-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div =
class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;fon=
t-size:small;color:rgb(0,0,0)">Happy new years devs,</div><div class=3D"gma=
il_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-fam=
ily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">I figured =
I would share some thoughts for conceptual review that have been bouncing a=
round my head as an opportunity to clean up the fee paying semantics in bit=
coin "for good". The design space is very wide on the approach I&=
#39;ll share, so below is just a sketch of how it could work which I'm =
sure could be improved greatly.</div><div class=3D"gmail_default" style=3D"=
font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><b=
r></div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,s=
ans-serif;font-size:small;color:rgb(0,0,0)">Transaction fees are an integra=
l part of bitcoin.</div><div class=3D"gmail_default" style=3D"font-family:a=
rial,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;fon=
t-size:small;color:rgb(0,0,0)">However, due to quirks of Bitcoin's tran=
saction design, fees are a part of the transactions that they occur in.</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)">While this works in a "Bitcoin 1.0" world, where all tra=
nsactions are simple on-chain transfers, real world use of Bitcoin requires=
support for things like Fee Bumping stuck transactions, DoS resistant Paym=
ent Channels, and other long lived Smart Contracts that can't predict f=
uture fee rates. Having the fees paid in band makes writing these contracts=
much more difficult as you can't merely express the logic you want for=
the transaction, but also the fees.</div><div class=3D"gmail_default" styl=
e=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,helvet=
ica,sans-serif;font-size:small;color:rgb(0,0,0)">Previously, I proposed a s=
pecial type of transaction called a "Sponsor" which has some spec=
ial consensus=C2=A0+ mempool rules to allow arbitrarily appending fees to a=
transaction to bump it up in the mempool.</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)">As an alternative, w=
e could establish an account system in Bitcoin as an "extension block&=
quot;.</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)"><b>Here's how it might work:</b></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)">1. Defi=
ne a special anyone can spend output type that is a "fee account"=
(e.g. segwit V2). Such outputs have a redeeming key and an amount associat=
ed with them, but are overall anyone can spend.</div><div class=3D"gmail_de=
fault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;colo=
r:rgb(0,0,0)">2. All deposits to these outputs get stored in a separate UTX=
O database for fee accounts</div><div class=3D"gmail_default" style=3D"font=
-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">3. Fee=
accounts can sign only two kinds of transaction: A: a fee amount and a TXI=
D (or Outpoint?); B: a withdraw amount, a fee, and an=C2=A0address</div><di=
v class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;f=
ont-size:small;color:rgb(0,0,0)">4. These transactions are committed in an =
extension block merkle tree. While the actual signature must cover the TXID=
/Outpoint, the committed data need only cover the index in the block of the=
transaction. The public key for account lookup can be recovered from the m=
essage=C2=A0+ signature.</div><div class=3D"gmail_default" style=3D"font-fa=
mily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">5. In any=
block, any of the fee account deposits can be: released into fees if there=
is a corresponding tx; consolidated together to reduce the number of utxos=
(this can be just an OP_TRUE no metadata needed); or released into fees *a=
nd paid back* into the requested withdrawal key (encumbering a 100 block ti=
meout). Signatures must be unique in a block.</div><div class=3D"gmail_defa=
ult" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:=
rgb(0,0,0)">6. Mempool logic is updated to allow attaching of account fee s=
pends to transactions, the mempool can restrict that an account is not allo=
wed more spend more than it's balance.</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)"><b>But aren't ac=
counts "bad"?</b></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)">Yes, accounts are bad. But these ac=
counts are not bad, because any funds withdrawn from the fee extension are =
fundamentally locked for 100 blocks as a coinbase output, so there should b=
e no issues with any series of reorgs. Further, since there is no "ric=
h state" for these accounts, the state updates can always be applied i=
n a conflict-free way in any order.</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)"><b>Improving the privacy of this design:</b></div><div c=
lass=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)=
">This design could likely be modified to implement something like Tornado.=
cash or something else so that the fee account paying can be unlinked from =
the transaction being paid for, improving privacy at the expense of being a=
bit more expensive.</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)">Other operations could be added to allow a=
trustless mixing to be done by miners automatically where groups of accoun=
ts with similar values are trustlessly =C2=A0split into a common denominato=
r and change, and keys are derived via a verifiable stealth address like pr=
otocol (so fee balances can be discovered by tracing the updates posted). T=
hese updates could also be produced by individuals rather than miners, and =
miners could simply honor them with better privacy. While a miner generatin=
g an update would be able to deanonymize their mixes, if you have your acco=
unt mixed several times by independent miners that could potentially add su=
fficient privacy.</div><div class=3D"gmail_default" style=3D"font-family:ar=
ial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div c=
lass=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font=
-size:small;color:rgb(0,0,0)">The LN can also be used with PTLCs to, in the=
ory, have another individual paid to sponsor a transaction on your behalf o=
nly if they reveal a valid sig from their fee paying account, although unde=
r this model it's hard to ensure that the owner doesn't pay a fee a=
nd then 'cancel' by withdrawing the rest. However, this could be pa=
rtly solved by using reputable fee accounts (reputation could be measured s=
omewhat decentralized-ly by longevity of the account and transactions paid =
for historically).</div><div class=3D"gmail_default" style=3D"font-family:a=
rial,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;fon=
t-size:small;color:rgb(0,0,0)"><b>Scalability</b></div><div class=3D"gmail_=
default" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;co=
lor:rgb(0,0,0)"><b><br></b></div><div class=3D"gmail_default" style=3D"font=
-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">This d=
esign is fundamentally 'decent' for scalability because adding fees=
to a transaction does not require adding inputs or outputs and does not re=
quire tracking substantial amounts of new state.</div><div class=3D"gmail_d=
efault" style=3D"font-family:arial,helvetica,sans-serif;font-size:small;col=
or: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)">Paying someone=
else to pay for you via the LN also helps make this more efficient if the =
withdrawal issues can be fixed.</div><div class=3D"gmail_default" style=3D"=
font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><b=
r></div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,s=
ans-serif;font-size:small;color:rgb(0,0,0)"><b>Lightning:</b></div><div cla=
ss=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font-s=
ize:small;color:rgb(0,0,0)"><b><br></b></div><div class=3D"gmail_default" s=
tyle=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,=
0,0)">This type of design works really well for channels because the additi=
on of fees to e.g. a channel state does not require any sort of pre-plannin=
g (e.g. anchors) or transaction flexibility (SIGHASH flags). This sort of d=
esign is naturally immune to pinning issues since you could offer to pay a =
fee for any TXID and the number of fee adding offers does not need to be re=
stricted in the same way the descendant transactions would need to be.</div=
><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-ser=
if;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)"><b>Without a fork?</b></div><div class=3D"gmail_default" style=3D"f=
ont-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,sa=
ns-serif;font-size:small;color:rgb(0,0,0)">This type of design could be don=
e as a federated network that bribes miners -- potentially even retroactive=
ly after a block is formed. That might be sufficient to prove the concept w=
orks before a consensus upgrade is deployed, but such an approach does mean=
there is a centralizing layer interfering with normal mining.</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)=
"><br></div><div class=3D"gmail_default" style=3D"font-family:arial,helveti=
ca,sans-serif;font-size:small;color:rgb(0,0,0)">Happy new year!!</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)=
">Jeremy</div><br clear=3D"all"><div><div dir=3D"ltr"><div dir=3D"ltr">--<b=
r><a href=3D"https://twitter.com/JeremyRubin" target=3D"_blank">@JeremyRubi=
n</a><a href=3D"https://twitter.com/JeremyRubin" target=3D"_blank"></a></di=
v></div></div></div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>
</blockquote></div>
--000000000000a2a30405d5f23406--
|