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
750
751
752
753
754
755
756
757
758
759
760
761
762
763
|
Return-Path: <fresheneesz@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
by lists.linuxfoundation.org (Postfix) with ESMTP id 89419C000B
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 19 Feb 2022 07:22:11 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id 7EB7A41D97
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 19 Feb 2022 07:22:11 +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 8I4TDRaV9nPx
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 19 Feb 2022 07:22:09 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com
[IPv6:2a00:1450:4864:20::62c])
by smtp4.osuosl.org (Postfix) with ESMTPS id 37BE241D95
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 19 Feb 2022 07:22:08 +0000 (UTC)
Received: by mail-ej1-x62c.google.com with SMTP id qk11so20100713ejb.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 18 Feb 2022 23:22:08 -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=Fihirt1IkfWR7VnDYQ7IWrSaSqWdVOc1HVOFVnnH1RU=;
b=X7IgmJJTeQ38qV2Gcz1UwI+/ErFOQZF/G7bl8waakViUualJwHFDYG0GZoOZycIcd/
k4ekSdaA5l+SsDrttqsg0CugV37xt5d7qgOVGYI0M/PNXinMQyQEjRGR+HcxfbgMbHad
wPxA1rvh0fAAivqaqf58xAT0IlQmx1FENAz501ZG+nO7jkSfSWYXVh5f6uGqkrV0ZlxM
SgsE4EXq00od0j9YSudrHxJ0F5T4In+P1vgzPJgbNHyyZFthhDaDaTstd8e6vEbZZH9d
lWO+WsX0o3j7lmx+BqgiJCWP+C3zY5ihBTdmWkJSwwxlyxJEgXB8rYMhSoOEpvbsFXOz
KS8A==
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=Fihirt1IkfWR7VnDYQ7IWrSaSqWdVOc1HVOFVnnH1RU=;
b=UHSKyLfdZy5sXTjxccbnh5Ex9zrfWufErEZJb0cRDijkGzDPE94XAtqIeaXzli4xcV
AjXq1UseIrkKHjGy2zlUUflMWsaV5CAldpRMGu67b6fBfyXAkGEvFwC1oB1uJtuCrnOj
NVrGKoVpXGYOh5m33JQWLmVfaVkR7AKqqSJyEKbI1YXnqjSjRV/Dy7ZyRQYSW+l6R8Cq
NZXFgngRXx3idnjtU+Pq/KqulxNDts7tPmcHylHZkngbL+6uZf5x2/kT5bjvOiRTvYF+
qOTOvVbK06GhfVMEt/jVToUvC25Sd3B0GvgOoBFVx0X54ycEVd0thio4VLG6F0vEhNOp
2AkQ==
X-Gm-Message-State: AOAM532nB/N+4RYrPpwkuIKpOD2Kgf8qbVlzePYEVV+/bgoUdawPZTpQ
K+jX4biEeykuuLD5CB5SJ8aV6ByQxD/vhcIrVwc=
X-Google-Smtp-Source: ABdhPJwboylRS4AGKhce2EyRmh+WN9KQK7nIln0WjBdm7tbwtbO6sP+AdBQDCf+OaVH0XgDbX8jgiujrVePJIYannWk=
X-Received: by 2002:a17:906:130a:b0:6b7:5e48:350a with SMTP id
w10-20020a170906130a00b006b75e48350amr8944460ejb.184.1645255326755; Fri, 18
Feb 2022 23:22:06 -0800 (PST)
MIME-Version: 1.0
References: <6nZ-SkxvJLrOCOIdUtLOsdnl94DoX_NHY0uwZ7sw78t24FQ33QJlJU95W7Sk1ja5EFic5a3yql14MLmSAYFZvLGBS4lDUJfr8ut9hdB7GD4=@protonmail.com>
<CALZpt+Ee9kuVjpXYgOb_7dB7Yr8HYmicdRhfgXsQkey2szNDHg@mail.gmail.com>
<0mhhHzTun8dpIcLda1CLFihMsgLoWQUEE8woKUKhf_UHYps2w7jVzbJAUJ302kQEB1ZdvMfakP9IBUHLM8bGns-pg0NHmpuak3yjpphjJnw=@protonmail.com>
<CAD5xwhh9JHE0QAfRMeKs7w=L-GB5DaEomsQ0aH4ibSDi9Oe8Rg@mail.gmail.com>
<CAB3F3Dt6znirMfe4C6ASh6OvS_qR7XLx1fQ4O5ZCwbxhcNKsNg@mail.gmail.com>
In-Reply-To: <CAB3F3Dt6znirMfe4C6ASh6OvS_qR7XLx1fQ4O5ZCwbxhcNKsNg@mail.gmail.com>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Sat, 19 Feb 2022 01:21:56 -0600
Message-ID: <CAGpPWDYUJ66oA2gzjXYk2fvRaRMZeY4wCyS0KmimXtid03ahCw@mail.gmail.com>
To: Greg Sanders <gsanders87@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000050ef9105d859db1c"
X-Mailman-Approved-At: Sat, 19 Feb 2022 08:10:25 +0000
Subject: Re: [bitcoin-dev] `OP_EVICT`: An Alternative to
`OP_TAPLEAFUPDATEVERIFY`
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sat, 19 Feb 2022 07:22:11 -0000
--00000000000050ef9105d859db1c
Content-Type: text/plain; charset="UTF-8"
> "fully" punitive channels also make large value channels more dangerous
from the perspective of bugs causing old states to be published
Wouldn't it be ideal to have the penalty be to pay for a single extra
transaction fee? That way there is a penalty so cheating attempts aren't
free (for someone who wants to close a channel anyway) and yet a single fee
isn't going to be much of a concern in the accidental publishing case. It
still perplexes me why eltoo chose no penalty at all vs a small penalty
like that.
On Fri, Feb 18, 2022, 19:46 Greg Sanders via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> > One point of discomfort I have with Eltoo that I think is not
> universal, but is shared by some others, is that non-punitive channels may
> not be good for high-value channels as you do want, especially in a
> congested blockspace world, punishments to incentivize correct behavior
> (otherwise cheating may look like a free option).
>
> Without derailing the conversation too far, "fully" punitive channels also
> make large value channels more dangerous from the perspective of bugs
> causing old states to be published. High value channels you'll need to have
> very high uptime. If you're available, your counterparty is incentivized to
> do a mutual close to reduce fees and remove timelocks on outputs. I think
> these tradeoffs will result in both types existing for N==2.
>
> On Sat, Feb 19, 2022 at 8:56 AM Jeremy Rubin via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> This is a fascinating post and I'm still chewing on it.
>>
>> Chiming in with two points:
>>
>> Point 1, note with respect to evictions, revivals, CTV, TLUV:
>>
>> CTV enables 1 person to be evicted in O(log N) or one person to leave in
>> O(log N). TLUV enables 1 person to leave in O(1) O(log N) transactions, but
>> evictions take (AFAICT?) O(N) O(log N) transactions because the un-live
>> party stays in the pool. Hence OP_EVICT helps also make it so you can kick
>> someone out, rather than all having to leave, which is an improvement.
>>
>> CTV rejoins work as follows:
>>
>> suppose you have a pool with 1 failure, you need to do log N txns to
>> evict the failure, which creates R * log_R(N) outputs, which can then do a
>> transaction to rejoin.
>>
>> For example, suppose I had 64 people in a radix 4 tree. you'd have at the
>> top level 4 groups of 16, then 4 groups of 4 people, and then 1 to 4 txns.
>> Kicking 1 person out would make you do 3 txns, and create 12 outputs total.
>> A transaction spending the 11 outputs that are live would capture 63 people
>> back into the tree, and with CISA would not be terribly expensive. To be a
>> bit more economical, you might prefer to just join the 3 outputs with 16
>> people in it, and yield 48 people in one pool. Alternatively, you can
>> lazily re-join if fees make it worth it/piggybacking another transaction,
>> or operate independently or try to find new, better, peers.
>>
>> Overall this is the type of application that necessitates *exact* byte
>> counting. Oftentimes things with CTV seem inefficient, but when you crunch
>> the numbers it turns out not to be so terrible. OP_EVICT seems promising in
>> this regard compared to TLUV or accumulators.
>>
>> Another option is to randomize the CTV trees with multiple outputs per
>> party (radix Q), then you need to do Q times the evictions, but you end up
>> with sub-pools that contain more people/fractional liquidity (this might
>> happen naturally if CTV Pools have channels in them, so it's good to model).
>>
>>
>> Point 2, on Eltoo:
>>
>> One point of discomfort I have with Eltoo that I think is not universal,
>> but is shared by some others, is that non-punitive channels may not be good
>> for high-value channels as you do want, especially in a congested
>> blockspace world, punishments to incentivize correct behavior (otherwise
>> cheating may look like a free option).
>>
>> Thus I'm reluctant to fully embrace designs which do not permit nested
>> traditional punitive channels in favor of Eltoo, when Eltoo might not have
>> product-market-fit for higher valued channels.
>>
>> If someone had a punitive-eltoo variant that would ameliorate this
>> concern almost entirely.
>>
>> Cheers,
>>
>> Jeremy
>>
>>
>>
>> --
>> @JeremyRubin <https://twitter.com/JeremyRubin>
>>
>> On Fri, Feb 18, 2022 at 3:40 PM ZmnSCPxj via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> Good morning ariard,
>>>
>>>
>>> > > A statechain is really just a CoinPool hosted inside a
>>> > > Decker-Wattenhofer or Decker-Russell-Osuntokun construction.
>>> >
>>> > Note, to the best of my knowledge, how to use LN-Penalty in the
>>> context of multi-party construction is still an unsolved issue. If an
>>> invalidated state is published on-chain, how do you guarantee that the
>>> punished output value is distributed "fairly" among the "honest" set of
>>> users ? At least
>>> > where fairness is defined as a reasonable proportion of the balances
>>> they owned in the latest state.
>>>
>>> LN-Penalty I believe is what I call Poon-Dryja?
>>>
>>> Both Decker-Wattenhofer (has no common colloquial name) and
>>> Decker-Russell-Osuntokun ("eltoo") are safe with N > 2.
>>> The former has bad locktime tradeoffs in the unilateral close case, and
>>> the latter requires `SIGHASH_NOINPUT`/`SIGHASH_ANYPREVOUT`.
>>>
>>>
>>> > > In principle, a set of promised outputs, if the owners of those
>>> > > outputs are peers, does not have *any* inherent order.
>>> > > Thus, I started to think about a commitment scheme that does not
>>> > > impose any ordering during commitment.
>>> >
>>> > I think we should dissociate a) *outputs publication ordering* from
>>> the b) *spends paths ordering* itself. Even if to each spend path a output
>>> publication is attached, the ordering constraint might not present the same
>>> complexity.
>>> >
>>> > Under this distinction, are you sure that TLUV imposes an ordering on
>>> the output publication ?
>>>
>>> Yes, because TLUV is based on tapleaf revelation.
>>> Each participant gets its own unique tapleaf that lets that participant
>>> get evicted.
>>>
>>> In Taproot, the recommendation is to sort the hashes of each tapleaf
>>> before arranging them into a MAST that the Taproot address then commits to.
>>> This sort-by-hash *is* the arbitrary ordering I refer to when I say that
>>> TLUV imposes an arbitrary ordering.
>>> (actually the only requirement is that pairs of scripts are
>>> sorted-by-hash, but it is just easier to sort the whole array by hash.)
>>>
>>> To reveal a single participant in a TLUV-based CoinPool, you need to
>>> reveal O(log N) hashes.
>>> It is the O(log N) space consumption I want to avoid with `OP_EVICT`,
>>> and I believe the reason for that O(log N) revelation is due precisely to
>>> the arbitrary but necessary ordering.
>>>
>>> > > With `OP_TLUV`, however, it is possible to create an "N-of-N With
>>> > > Eviction" construction.
>>> > > When a participant in the N-of-N is offline, but the remaining
>>> > > participants want to advance the state of the construction, they
>>> > > instead evict the offline participant, creating a smaller N-of-N
>>> > > where *all* participants are online, and continue operating.
>>> >
>>> > I think we should dissociate two types of pool spends : a) eviction by
>>> the pool unanimity in case of irresponsive participants and b) unilateral
>>> withdrawal by a participant because of the liquidity allocation policy. I
>>> think the distinction is worthy, as the pool participant should be stable
>>> and the eviction not abused.
>>> >
>>> > I'm not sure if TLUV enables b), at least without transforming the
>>> unilateral withdrawal into an eviction. To ensure the TLUV operation is
>>> correct (spent leaf is removed, withdrawing participant point removed,
>>> etc), the script content must be inspected by *all* the participant.
>>> However, I believe
>>> > knowledge of this content effectively allows you to play it out
>>> against the pool at any time ? It's likely solvable at the price of a
>>> CHECKSIG.
>>>
>>> Indeed, that distinction is important.
>>> `OP_TLUV` (and `OP_EVICT`, which is just a redesigned `OP_TLUV`)
>>> supports (a) but not (b).
>>>
>>> > `OP_EVICT`
>>> > ----------
>>> >
>>> > > * If it is `1` that simply means "use the Taproot internal
>>> > > pubkey", as is usual for `OP_CHECKSIG`.
>>> >
>>> > IIUC, this assumes the deployment of BIP118, where if the public key
>>> is a single byte 0x01, the internal pubkey is used
>>> > for verification.
>>>
>>> I thought it was part of Taproot?
>>>
>>> >
>>> > > * Output indices must not be duplicated, and indicated
>>> > > outputs must be SegWit v1 ("Taproot") outputs.
>>> >
>>> > I think public key duplication must not be verified. If a duplicated
>>> public key is present, the point is subtracted twice from the internal
>>> pubkey and therefore the aggregated
>>> > key remains unknown ? So it sounds to me safe against replay attacks.
>>>
>>> Ah, right.
>>>
>>> > > * The public key is the input point (i.e. stack top)
>>> > > **MINUS** all the public keys of the indicated outputs.
>>> >
>>> > Can you prevent eviction abuse where one counterparty threatens to
>>> evict everyone as all the output signatures are known among participants
>>> and free to sum ? (at least not considering fees)
>>>
>>> No, I considered onchain fees as the only mechanism to avoid eviction
>>> abuse.
>>> The individual-evict signatures commit to fixed quantities.
>>> The remaining change is then the only fund that can pay for onchain
>>> fees, so a single party evicting everyone else has to pay for the eviction
>>> of everyone else.
>>>
>>>
>>> > > Suppose however that B is offline.
>>> > > Then A, C, and D then decide to evict B.
>>> > > To do so, they create a transaction that has an output
>>> > > with "B := 6", and they reveal the `OP_EVICT` Tapscript
>>> > > as well as sign(b, "B := 6").
>>> > > This lets them change state and spend their funds without
>>> > > B being online.
>>> > > And B remains secure, as they cannot evict B except using
>>> > > the pre-signed output, which B certifies as their expected
>>> > > promised output.
>>> >
>>> > I think in the context of (off-chain) payment pool, OP_EVICT requires
>>> participant cooperation *after* the state update to allow a single
>>> participant to withdraw her funds.
>>>
>>> How so?
>>>
>>> A single participant withdrawing their funds unilaterally can do so by
>>> evicting everyone else (and paying for those evictions, as sort of a
>>> "nuisance fee").
>>> The signatures for each per-participant-eviction can be exchanged before
>>> the signature exchange for the Decker-Wattenhofer or
>>> Decker-Russell-Osuntokun.
>>>
>>>
>>> > > The combined fund cannot be spent except if all participants
>>> > > agree.
>>> >
>>> > If all participants agree minus the evicted ones, correct ? The output
>>> promises signatures are shared at state setup, therefore no additional
>>> contribution from the evicted participant (I think).
>>>
>>> Yes.
>>>
>>> >
>>> > > To prevent signature replay, each update of an updateable
>>> > > scheme like CoinPool et al should use a different pubkey
>>> > > for each participant for each state.
>>> >
>>> > I'm not even sure if it's required with OP_EVICT, as the publication
>>> of the promised output are ultimately restrained by a signature of the
>>> updated internal pubkey, this set of signers verify that promised output N
>>> does bind to the published state N ?
>>>
>>> If the internal pubkey is reused (for example, if all participants are
>>> online and want to change state cooperatively) then the component keys need
>>> to be re-tweaked each time.
>>>
>>> The tweaking can be done with non-hardened derivation.
>>>
>>>
>>> > > Its advantage is reduced number of eviction transactions,
>>> > > as multiple evictions, plus the revival of the CoinPool,
>>> > > can be put in a single transaction.
>>> > > It has the disadvantage relative to `OP_TLUV` of requiring
>>> > > point operations.
>>> > > I have not explored completely, but my instinct suggests
>>> > > that `OP_TLUV` use may require at least one signature
>>> > > validation anyway.
>>> >
>>> > I believe you can slightly modify TLUV to make it functional for
>>> CoinPool revival, where you want to prevent equivocation among the
>>> remaining set of signers. Though, I'm leaning to agree that you may require
>>> at least one signature validation (first to restrain spend authorization
>>> inside the pool participants, second to attach fees at broadcast-time).
>>>
>>> Yes, TLUV does have that advantage relative to CTV, and `OP_EVICT` is
>>> "just" a redesigned `OP_TLUV`.
>>>
>>> In particular, I first developed my thoughts on revivable constructs
>>> with eviction of participants here:
>>> https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-February/003479.html
>>>
>>>
>>> Regards,
>>> ZmnSCPxj
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--00000000000050ef9105d859db1c
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto">>=C2=A0<span style=3D"font-family:arial,helvetica,sans=
-serif;font-size:12.8px">"fully" punitive channels also make larg=
e value channels more dangerous from the perspective of bugs causing old=C2=
=A0states to be published</span><div dir=3D"auto"><span style=3D"font-famil=
y:arial,helvetica,sans-serif;font-size:12.8px"><br></span></div><div dir=3D=
"auto"><span style=3D"font-family:arial,helvetica,sans-serif;font-size:12.8=
px">Wouldn't it be ideal to have the penalty be to pay for a single ext=
ra transaction fee? That way there is a penalty so cheating attempts aren&#=
39;t free (for someone who wants to close a channel anyway) and yet a singl=
e fee isn't going to be much of a concern in the accidental publishing =
case. It still perplexes me why eltoo chose no penalty at all vs a small pe=
nalty like that.</span></div></div><br><div class=3D"gmail_quote"><div dir=
=3D"ltr" class=3D"gmail_attr">On Fri, Feb 18, 2022, 19:46 Greg Sanders via =
bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bi=
tcoin-dev@lists.linuxfoundation.org</a>> wrote:<br></div><blockquote cla=
ss=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;pa=
dding-left:1ex"><div dir=3D"ltr">>=C2=A0<span style=3D"color:rgb(0,0,0);=
font-family:arial,helvetica,sans-serif">One point of discomfort I have with=
Eltoo that I think is not universal, but is shared by some others, is that=
non-punitive channels may not be good for high-value channels as you do wa=
nt, especially in a congested blockspace world, punishments to incentivize =
correct behavior (otherwise cheating may look like a free option).</span><d=
iv class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;=
color:rgb(0,0,0)"><br></div><div class=3D"gmail_default" style=3D"font-fami=
ly:arial,helvetica,sans-serif;color:rgb(0,0,0)">Without derailing=C2=A0the =
conversation too far, "fully" punitive channels also make large v=
alue channels more dangerous from the perspective of bugs causing old=C2=A0=
states to be published. High value channels you'll need to have very hi=
gh uptime. If you're available, your counterparty is incentivized to do=
a mutual close to reduce fees and remove timelocks on=C2=A0outputs. I thin=
k these tradeoffs will result in both types existing for N=3D=3D2.</div></d=
iv><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On =
Sat, Feb 19, 2022 at 8:56 AM Jeremy Rubin via bitcoin-dev <<a href=3D"ma=
ilto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" rel=3D"norefe=
rrer">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br></div><blockq=
uote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1p=
x solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"><div dir=3D"ltr=
"><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-se=
rif;font-size:small;color:rgb(0,0,0)">This is a fascinating post and I'=
m still chewing on it.</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)">Chiming in with two points:</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)=
">Point 1, note with respect to evictions, revivals, CTV, TLUV:</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)=
">CTV enables 1 person to be evicted in O(log N) or one person to leave in =
O(log N). TLUV enables 1 person to leave in O(1) O(log N) transactions, but=
evictions take (AFAICT?) O(N) O(log N) transactions because the un-live pa=
rty stays in the pool. Hence OP_EVICT helps also make it so you can kick so=
meone out, rather than all having to leave, which is an improvement.</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)">CTV rejoins work as follows:</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)">suppose you have a pool wit=
h 1 failure, you need to do log N txns to evict the failure, which creates =
R * log_R(N) outputs, which can then do a transaction to rejoin.</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)=
">For example, suppose I had 64 people in a radix 4 tree. you'd have at=
the top level 4 groups of 16, then 4 groups of 4 people, and then 1 to 4 t=
xns. Kicking 1 person out would make you do 3 txns, and create 12 outputs t=
otal. A transaction spending the 11 outputs that are live would capture 63 =
people back into the tree, and with CISA would not be terribly expensive. T=
o be a bit more economical, you might prefer to just join the 3 outputs wit=
h 16 people in it, and yield 48 people in one pool. Alternatively, you can =
lazily re-join if fees make it worth it/piggybacking another transaction, o=
r operate independently or try to find new, better, peers.</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)">Ove=
rall this is the type of application that necessitates *exact* byte countin=
g. Oftentimes things with CTV seem inefficient, but when you crunch the num=
bers=C2=A0it turns out not to be so terrible. OP_EVICT seems promising in t=
his regard compared to TLUV or accumulators.</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 class=3D"gmail_default" style=3D"font-family:aria=
l,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Another option is =
to randomize the CTV trees with multiple outputs per party (radix Q), then =
you need to do Q times the evictions, but you end up with sub-pools that co=
ntain more people/fractional liquidity (this might happen naturally if CTV =
Pools have channels in them, so it's good to model).</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)"><br></=
div><div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-=
serif;font-size:small;color:rgb(0,0,0)">Point 2, on Eltoo:</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)">One=
point of discomfort I have with Eltoo that I think is not universal, but i=
s shared by some others, is that non-punitive channels may not be good for =
high-value channels as you do want, especially in a congested blockspace wo=
rld, punishments to incentivize correct behavior (otherwise cheating may lo=
ok like a free option).</div><div class=3D"gmail_default" style=3D"font-fam=
ily: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-seri=
f;font-size:small;color:rgb(0,0,0)">Thus I'm reluctant to fully embrace=
designs which do not permit nested traditional punitive channels in favor =
of Eltoo, when Eltoo might not have product-market-fit for higher valued ch=
annels.</div><div class=3D"gmail_default" style=3D"font-family:arial,helvet=
ica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div class=3D"gm=
ail_default" style=3D"font-family:arial,helvetica,sans-serif;font-size:smal=
l;color:rgb(0,0,0)">If someone had a punitive-eltoo variant that would amel=
iorate this concern almost entirely.</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)">Cheers,</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)">Jeremy=
</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)"><br></div><br clear=3D"all"><div><div dir=3D"ltr"><div dir=3D"=
ltr">--<br><a href=3D"https://twitter.com/JeremyRubin" target=3D"_blank" re=
l=3D"noreferrer">@JeremyRubin</a><br></div></div></div></div><br><div class=
=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Fri, Feb 18, 2022=
at 3:40 PM ZmnSCPxj via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@list=
s.linuxfoundation.org" target=3D"_blank" rel=3D"noreferrer">bitcoin-dev@lis=
ts.linuxfoundation.org</a>> wrote:<br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex">Good morning ariard,<br>
<br>
<br>
> > A statechain is really just a CoinPool hosted inside a<br>
> > =C2=A0Decker-Wattenhofer or Decker-Russell-Osuntokun construction=
.<br>
><br>
> Note, to the best of my knowledge, how to use LN-Penalty in the contex=
t of multi-party construction is still an unsolved issue. If an invalidated=
state is published on-chain, how do you guarantee that the punished output=
value is distributed "fairly" among the "honest" set o=
f users ? At least<br>
> where fairness is defined as a reasonable proportion of the balances t=
hey owned in the latest state.<br>
<br>
LN-Penalty I believe is what I call Poon-Dryja?<br>
<br>
Both Decker-Wattenhofer (has no common colloquial name) and Decker-Russell-=
Osuntokun ("eltoo") are safe with N > 2.<br>
The former has bad locktime tradeoffs in the unilateral close case, and the=
latter requires `SIGHASH_NOINPUT`/`SIGHASH_ANYPREVOUT`.<br>
<br>
<br>
> > In principle, a set of promised outputs, if the owners of those<b=
r>
> > outputs are peers, does not have *any* inherent order.<br>
> > Thus, I started to think about a commitment scheme that does not<=
br>
> > impose any ordering during commitment.<br>
><br>
> I think we should dissociate a) *outputs publication ordering* from th=
e b) *spends paths ordering* itself. Even if to each spend path a output pu=
blication is attached, the ordering constraint might not present the same c=
omplexity.<br>
><br>
> Under this distinction, are you sure that TLUV imposes an ordering on =
the output publication ?<br>
<br>
Yes, because TLUV is based on tapleaf revelation.<br>
Each participant gets its own unique tapleaf that lets that participant get=
evicted.<br>
<br>
In Taproot, the recommendation is to sort the hashes of each tapleaf before=
arranging them into a MAST that the Taproot address then commits to.<br>
This sort-by-hash *is* the arbitrary ordering I refer to when I say that TL=
UV imposes an arbitrary ordering.<br>
(actually the only requirement is that pairs of scripts are sorted-by-hash,=
but it is just easier to sort the whole array by hash.)<br>
<br>
To reveal a single participant in a TLUV-based CoinPool, you need to reveal=
O(log N) hashes.<br>
It is the O(log N) space consumption I want to avoid with `OP_EVICT`, and I=
believe the reason for that O(log N) revelation is due precisely to the ar=
bitrary but necessary ordering.<br>
<br>
> > With `OP_TLUV`, however, it is possible to create an "N-of-N=
With<br>
> > Eviction" construction.<br>
> > When a participant in the N-of-N is offline, but the remaining<br=
>
> > participants want to advance the state of the construction, they<=
br>
> > instead evict the offline participant, creating a smaller N-of-N<=
br>
> > where *all* participants are online, and continue operating.<br>
><br>
> I think we should dissociate two types of pool spends : a) eviction by=
the pool unanimity in case of irresponsive participants and b) unilateral =
withdrawal by a participant because of the liquidity allocation policy. I t=
hink the distinction is worthy, as the pool participant should be stable an=
d the eviction not abused.<br>
><br>
> I'm not sure if TLUV enables b), at least without transforming the=
unilateral withdrawal into an eviction. To ensure the TLUV operation is co=
rrect=C2=A0 (spent leaf is removed, withdrawing participant point removed, =
etc), the script content must be inspected by *all* the participant. Howeve=
r, I believe<br>
> knowledge of this content effectively allows you to play it out agains=
t the pool at any time ? It's likely solvable at the price of a CHECKSI=
G.<br>
<br>
Indeed, that distinction is important.<br>
`OP_TLUV` (and `OP_EVICT`, which is just a redesigned `OP_TLUV`) supports (=
a) but not (b).<br>
<br>
> `OP_EVICT`<br>
> ----------<br>
><br>
> > =C2=A0* If it is `1` that simply means "use the Taproot inte=
rnal<br>
> > =C2=A0 =C2=A0pubkey", as is usual for `OP_CHECKSIG`.<br>
><br>
> IIUC, this assumes the deployment of BIP118, where if the=C2=A0 public=
key is a single byte 0x01, the internal pubkey is used<br>
> for verification.<br>
<br>
I thought it was part of Taproot?<br>
<br>
><br>
> > =C2=A0* Output indices must not be duplicated, and indicated<br>
> > =C2=A0 =C2=A0outputs must be SegWit v1 ("Taproot") outp=
uts.<br>
><br>
> I think public key duplication must not be verified. If a duplicated p=
ublic key is present, the point is subtracted twice from the internal pubke=
y and therefore the aggregated<br>
> key remains unknown ? So it sounds to me safe against replay attacks.<=
br>
<br>
Ah, right.<br>
<br>
> > =C2=A0* The public key is the input point (i.e. stack top)<br>
> > =C2=A0 =C2=A0**MINUS** all the public keys of the indicated outpu=
ts.<br>
><br>
> Can you prevent eviction abuse where one counterparty threatens to evi=
ct everyone as all the output signatures are known among participants and f=
ree to sum ? (at least not considering fees)<br>
<br>
No, I considered onchain fees as the only mechanism to avoid eviction abuse=
.<br>
The individual-evict signatures commit to fixed quantities.<br>
The remaining change is then the only fund that can pay for onchain fees, s=
o a single party evicting everyone else has to pay for the eviction of ever=
yone else.<br>
<br>
<br>
> > Suppose however that B is offline.<br>
> > Then A, C, and D then decide to evict B.<br>
> > To do so, they create a transaction that has an output<br>
> > with "B :=3D 6", and they reveal the `OP_EVICT` Tapscri=
pt<br>
> > as well as sign(b, "B :=3D 6").<br>
> > This lets them change state and spend their funds without<br>
> > B being online.<br>
> > And B remains secure, as they cannot evict B except using<br>
> > the pre-signed output, which B certifies as their expected<br>
> > promised output.<br>
><br>
> I think in the context of (off-chain) payment pool, OP_EVICT requires =
participant cooperation *after* the state update to allow a single particip=
ant to withdraw her funds.<br>
<br>
How so?<br>
<br>
A single participant withdrawing their funds unilaterally can do so by evic=
ting everyone else (and paying for those evictions, as sort of a "nuis=
ance fee").<br>
The signatures for each per-participant-eviction can be exchanged before th=
e signature exchange for the Decker-Wattenhofer or Decker-Russell-Osuntokun=
.<br>
<br>
<br>
> > The combined fund cannot be spent except if all participants<br>
> > agree.<br>
><br>
> If all participants agree minus the evicted ones, correct ? The output=
promises signatures are shared at state setup, therefore no additional con=
tribution from the evicted participant (I think).<br>
<br>
Yes.<br>
<br>
><br>
> > To prevent signature replay, each update of an updateable<br>
> > scheme like CoinPool et al should use a different pubkey<br>
> > for each participant for each state.<br>
><br>
> I'm not even sure if it's required with OP_EVICT, as the publi=
cation of the promised output are ultimately restrained by a signature of t=
he updated internal pubkey, this set of signers verify that promised output=
N does bind to the published state N ?<br>
<br>
If the internal pubkey is reused (for example, if all participants are onli=
ne and want to change state cooperatively) then the component keys need to =
be re-tweaked each time.<br>
<br>
The tweaking can be done with non-hardened derivation.<br>
<br>
<br>
> > Its advantage is reduced number of eviction transactions,<br>
> > as multiple evictions, plus the revival of the CoinPool,<br>
> > can be put in a single transaction.<br>
> > It has the disadvantage relative to `OP_TLUV` of requiring<br>
> > point operations.<br>
> > I have not explored completely, but my instinct suggests<br>
> > that `OP_TLUV` use may require at least one signature<br>
> > validation anyway.<br>
><br>
> I believe you can slightly modify TLUV to make it functional for CoinP=
ool revival, where you want to prevent equivocation among the remaining set=
of signers. Though, I'm leaning to agree that you may require at least=
one signature validation=C2=A0 (first to restrain spend authorization insi=
de the pool participants, second to attach fees at broadcast-time).<br>
<br>
Yes, TLUV does have that advantage relative to CTV, and `OP_EVICT` is "=
;just" a redesigned `OP_TLUV`.<br>
<br>
In particular, I first developed my thoughts on revivable constructs with e=
viction of participants here: <a href=3D"https://lists.linuxfoundation.org/=
pipermail/lightning-dev/2022-February/003479.html" rel=3D"noreferrer norefe=
rrer" target=3D"_blank">https://lists.linuxfoundation.org/pipermail/lightni=
ng-dev/2022-February/003479.html</a><br>
<br>
<br>
Regards,<br>
ZmnSCPxj<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" =
rel=3D"noreferrer">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>
</div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" =
rel=3D"noreferrer">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>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" =
rel=3D"noreferrer">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>
--00000000000050ef9105d859db1c--
|