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
|
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 3B5A1C000B
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 30 Jan 2022 15:39:26 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id 1CC92405E7
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 30 Jan 2022 15:39:26 +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 oMNPbLsL7h0u
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 30 Jan 2022 15:39:24 +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 EF6494035E
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 30 Jan 2022 15:39:23 +0000 (UTC)
Received: by mail-ed1-x529.google.com with SMTP id p12so21979966edq.9
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 30 Jan 2022 07:39:23 -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=buNvdMGxCPY+O4xzpdl6XV3/X472PtX5tiZaOLRFJXA=;
b=hfRbXubLNje6kgXDAQD/m+aWQy3fpzeUGlZK2ReigdutIpvBdQnSpbJ7OPRwV1kBcO
vKGW59vo1+Of0Mbvod7OnnZBn4eqRdbTax6qxlSxPx7yIb4ZxIRDtgq2huPN/yZZUzu0
WlTnHFrZzO5pyHjgfn88A1rwNArI0BXn+4aGsu/m3ZLIzrQfltc1KSp1GI2AINzQjCb4
QmnWh2yEQ3LwG6pC8M3SmoJ9pYTTNdcrrPAgPvHTJHdR/cbAZ8oj8ah6AkwFkJYLdoQD
1e5QaPk9GMv4XbDB49MA7/9RsuZpft/RPLs/ghfE9tnKd5y87ampUlD0K8afh2F0wIGI
EBdQ==
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=buNvdMGxCPY+O4xzpdl6XV3/X472PtX5tiZaOLRFJXA=;
b=BWoOw3fvg3duMZ6Lnaf2zcSSqHoBW2PBrMuPYQsJk8iXxBDWKdDYvudoOrGaP37VVO
eBw0qHVnHWnf1GUXuv9VnpMFYd4oftJK2lXYbRWygyRy3ZnwVkqhe+HhHbo1WIzFIWP/
ElBUH/YbmHDAAflHViC0njrjkv4yy8ojcr/Ddm5yZN4EyYJH74f+gWa8q16zhOlmkn2P
SujxdtiKcYg22aQ9bhx5c84fV64FXNzYicnI5VScIhW31XoKmyXWG2D/rHI5KwtqTIaz
Lvy0qWCwG1CprQyiEaRFA8SpDWAgPLXtlCRulM9S6X/MdcYOCHww+b4ZwYCOfgPjFlTa
KCVA==
X-Gm-Message-State: AOAM530u+X+d4fafYFnGaQmn2m4FnxVTVSvaUNdMw3atq0RfV+L5UcaS
qjwtByeuAVQcjGfKBFVv5NpjtNIQMPCB76mVAzE=
X-Google-Smtp-Source: ABdhPJx7YwDE5/k7z5HPkOG+9s3mFQEnDwgeYYYkhQpnIdvWKcqB5Gq7n9hamOWHPByATX40yPslrqiGb+DWvIpAqLM=
X-Received: by 2002:a50:ed06:: with SMTP id j6mr17318660eds.16.1643557161798;
Sun, 30 Jan 2022 07:39:21 -0800 (PST)
MIME-Version: 1.0
References: <jMANAdspMdPb1ZCFttQ3tGmkZ0oYojLY5Oz1d8ZSNl3JhZeDuT1xK0vxTu8uyHcgPXWsM_6XNb3R9tVD3_Yez88pviFrCaNt7LPqdWVBWus=@protonmail.com>
<CAGpPWDY3vZ2JOsa1UhoT-z8kfxqkVWcq1nyt9Ah5ye6HE_6gOQ@mail.gmail.com>
<By1G6iST5DCXZJVfEd3HzdPgU3e_NGoqvH-5UoqsOzY8qjiOmy5iHXiOwjXtm7Znq1Z6z-XOL0IPDSyQiLOZ6-lRQ-vi1I6Cba4aqywe8xw=@protonmail.com>
<CAGpPWDa=YBMrkuUHD0ogS3uxWq0g4LZubm=g9yQVuEffudsJhA@mail.gmail.com>
<3WOWxS-cioUIMYPIALmyVGumxk23bRnFn4ps8pr4DjMCi462UMmidiVZnWQBf4h9JVfQHggKKOMIJ1wxq8b19_5XsZ0hl2jzRlHNfXtpAi8=@protonmail.com>
In-Reply-To: <3WOWxS-cioUIMYPIALmyVGumxk23bRnFn4ps8pr4DjMCi462UMmidiVZnWQBf4h9JVfQHggKKOMIJ1wxq8b19_5XsZ0hl2jzRlHNfXtpAi8=@protonmail.com>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Sun, 30 Jan 2022 09:39:04 -0600
Message-ID: <CAGpPWDbjD8KDr1CcnPT6pa4=BnNV7Cfxe-Hwgpvb5=RX_GEuqA@mail.gmail.com>
To: AdamISZ <AdamISZ@protonmail.com>
Content-Type: multipart/alternative; boundary="000000000000cc100b05d6ce781f"
X-Mailman-Approved-At: Sun, 30 Jan 2022 15:41:42 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] PathCoin
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sun, 30 Jan 2022 15:39:26 -0000
--000000000000cc100b05d6ce781f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
> if you have a counterparty who is malicious and they *take action* to
steal, then they can present you with two alternatives
Generally I don't think this is the case. In this case, these are
time-sensitive operations. There is no time to negotiate after the
malicious party has taken action. The software would have already taken
counteraction. Negotiation would have to happen before broadcast.
> I've always felt strongly that they do not ultimately work
So you don't have any specific reasoning you can give for that gut feeling?
I'm not pushing for burn mechanisms, but trying to understand why you're
dismissing them.
On Sat, Jan 29, 2022 at 11:16 AM AdamISZ <AdamISZ@protonmail.com> wrote:
> > Justice. Also, there's no incentive for the honest party to not punish
> - presumably their software would automatically punish, and why go throug=
h
> any effort to stop it? A 1 cent bribe certainly wouldn't be enough. Maybe=
a
> $10 bribe might get someone somewhere to install hacked up software to be
> able to fulfill such a bribe, but even then i think it would be a rare
> person that would stoop to that. Were it to become a true negotiation, th=
e
> cheater has more to lose, and therefore the bribee has a lot of leverage.
>
> Justice isn't a strong enough incentive, it's too context-dependent, and
> in particular it's not something you could rely on if there is any
> financial incentive pushing the other way. Especially the ordering of
> events: if you have a counterparty who is malicious and they *take action=
*
> to steal, then they can present you with two alternatives one of which is
> more favourable than the other, if there is a bribe. It isn't *just* abou=
t
> logic I think, though the logic definitely matters.
>
> These arguments about whether we could use 'mutually assured destruction'
> approaches (burn in particular) to make contract enforcement work have be=
en
> ongoing amongst Bitcoin enthusiasts for a decade, I've always felt strong=
ly
> that they do not ultimately work and haven't seen anything to change my
> mind (I seem to remember convincing Manfred Karrer not to use it in
> Bitsquare in 2014/15, but there've been many other examples of people
> proposing it and it never really getting traction).
>
> > One thing I thought of regarding path coin, if there's ever a situation
> where there are multiple choices in path, whatever punishment there is
> probably needs to be able to handle the multiple of the number of paths.
>
> Right, I briefly alluded to setting up with multiple paths - general idea
> is instead of only a->b->c->d->e it's possible to setup the n-ary tree, s=
o
> a can go to all of b,c,d,e etc., but the problem is the factorial blowup
> that you get even if you restrict to no-revisiting (or exponential
> otherwise). For the toy example of 5 participants though, it is entirely
> possible to build the matrix as illustrated in the gist, but it's an N^2
> matrix duplicated for every change in the path, here's the simplest
> possible extension of the base case:
>
> path 1: A B* C* D* E*
> path 2: A B C* D* E*
> path 3: A B C* D* E*
> path 4: A B C D* E*
> path 5: A B C D E
> path 6: A C* B* D* E*
> path 7: A C B* D* E*
> path 8: A C B D* E*
> path 9: A C B D E*
> path 10: A C B D E
>
> The * would indicate pre-signs (and this whole list is branches in the
> taproot output of the pathcoin); this setup *only* allows one alternate
> path (second C instead of second B) for the coin.
>
> If A chooses to pay B (not C), then: instead of only giving B an adaptor
> on path1 and signatures on paths 2,3,4,5, A would also have to give B
> adaptors on paths 6-10 as well. So it's easy to see that if you kept addi=
ng
> branches for every possible spending path A->E with no revisits you have
> like n^2(n-1)! (maybe not exactly; something very similar).
> (Notice: though there are multiple paths via which A can cheat, they all
> reveal the same adaptor secret (and they're all the same coin) leading to
> the same forfeit of fidelity bond, see gist for the nice way you can alwa=
ys
> have it so that a single fidelity bond goes to the honest owner).
>
> All of this is predicated on the idea that the participants do *not*
> coordinate at all after the initial setup; only a data transfer from paye=
r
> to payee. A pretty massive restriction, of course.
>
> Sent with ProtonMail <https://protonmail.com/> Secure Email.
>
> =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original =
Message =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90
> On Friday, January 28th, 2022 at 15:27, Billy Tetrud via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> > what is the incentive for the honest party to punish?
>
> Justice. Also, there's no incentive for the honest party to not punish -
> presumably their software would automatically punish, and why go through
> any effort to stop it? A 1 cent bribe certainly wouldn't be enough. Maybe=
a
> $10 bribe might get someone somewhere to install hacked up software to be
> able to fulfill such a bribe, but even then i think it would be a rare
> person that would stoop to that. Were it to become a true negotiation, th=
e
> cheater has more to lose, and therefore the bribee has a lot of leverage.
>
> > my strong intuition is that it will never be properly stable.
>
> I'm curious what you mean by "stable". You had mentioned the game theory
> is "fragile" and I'm wondering if there's more to this than just "what
> incentive does the honest party have to burn?"
>
> To be clear, I'm not advocating for Sabu and I haven't done any deep
> thinking about burn based incentives.
>
> One thing I thought of regarding path coin, if there's ever a situation
> where there are multiple choices in path, whatever punishment there is
> probably needs to be able to handle the multiple of the number of paths.
> The only way around this i can imagine is to have some method of
> coordination between payees, eg a place where a payee records their payme=
nt
> such that a payee who has been double spent on to become aware they've be=
en
> double spent on and initiate the punishment. But once you have that
> coordination mechanism it starts not looking more like an on chain
> transaction.
>
> On Tue, Jan 25, 2022, 06:50 AdamISZ <AdamISZ@protonmail.com> wrote:
>
>> Hi Billy,
>> I read through the description. I think systems like this *mostly* fail
>> due to game theory.
>>
>> With punishment-by-burn you have various issues that make it to my mind
>> pretty unstable, too unstable to use for any serious system. To be fair,
>> this isn't cut-and-dried. So let me unpack:
>>
>> (I briefly touched on why I dismissed penalties via burn in my gist,
>> section: "Not feeling the burn".)
>>
>> There is a distinction between penalty via burn to unspendable output an=
d
>> penalty via burn to miner fees. The latter has an obvious problem: if yo=
ur
>> counterparties collude with (or are) miners, they may not actually be
>> penalized at all (now to be clear, that is a problematic attack ex nihil=
o:
>> nobody usually can be sure who's mining the next block, but markets have=
a
>> way of solving and coordinating such things: see e.g. the various MEV
>> discussions and initiatives in Ethereum for an example of that).
>>
>> But the former (provable burn) is still imo extremely unstable: if the
>> penalty tx destroys all the money, what is the incentive for the honest
>> party to punish? In such a scenario even a one cent donation from the
>> attacker to the victim might prevent the penalty from happening.
>> You can combine 'destruction of most, or some, of the funds' with a
>> smaller payout to the aggrieved party, but then again you have to factor=
in
>> the possibility of bribes. The Sabu post you linked describes it as: "Th=
ere
>> are precise and delicate formulas for calculating the amount of loss of =
the
>> issuer and the creditor, which ensures that just and true act in both
>> parties are cost-effective in all situations." I agree it's delicate, bu=
t
>> after having spent time looking into these things, my strong intuition i=
s
>> that it will never be properly stable.
>>
>> In the PathCoin description I am specifically looking for a trustless
>> system, with this finesse: we still count it as trustless even though we
>> are using penalties as disincentive, because the penalty *consists of a
>> payment directly from the attacker to the attacked, and that payment is
>> larger than the amount stolen*. I claim that that *is* stable.
>>
>> Notice that Lightning has the same model (in LN-Penalty), as long as
>> 'claiming the whole channel capacity' is enough to be larger than what i=
s
>> stolen (see: channel reserves etc.).
>>
>>
>> Sent with ProtonMail <https://protonmail.com/> Secure Email.
>>
>>
>> =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90 Original=
Message =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90
>> On Tuesday, January 25th, 2022 at 11:53, Billy Tetrud via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> There was a protocol someone mentioned a while back called Sabu that had
>> the same goals. As i recall, it had some pretty promising constructs, bu=
t
>> would have a critical vulnerability that could be exploited by miners. T=
his
>> is the write up:
>>
>>
>> https://raymo-49157.medium.com/time-to-boost-bitcoin-circulation-million=
-transactions-per-second-and-privacy-1eef8568d180
>>
>> Perhaps some of the techniques there could be combined with your ideas t=
o
>> get closer to a solution.
>>
>> On Mon, Jan 24, 2022, 08:51 AdamISZ via bitcoin-dev <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> Hello list,
>>>
>>> I took the time to write up this rather out-there idea:
>>>
>>> Imagine you wanted to send a coin just like email, i.e. just transfer
>>> data to the counterparty.
>>>
>>> Clearly this is in general entirely impossible; but with what
>>> restrictions and assumptions could you create a toy version of it?
>>>
>>> See this gist for a detailed build up of the idea:
>>>
>>> https://gist.github.com/AdamISZ/b462838cbc8cc06aae0c15610502e4da
>>>
>>> Basically: using signature adaptors and CTV or a similar covenant, you
>>> could create a fully trustless transfer of control of a utxo from one p=
arty
>>> to another with no interaction with the rest of the group, at the time =
of
>>> transfer (modulo of course lots and lots of one-time setup).
>>>
>>> The limitations are extreme and as you'd imagine. In the gist I feel
>>> like I got round one of them, but not the others.
>>>
>>> (I very briefly mention comparison to e.g. statechains or payment pools=
;
>>> they are making other tradeoffs against the 'digital cash' type of goal=
.
>>> There is no claim that this 'pathcoin' idea is even viable yet, let alo=
ne
>>> better than those ideas).
>>>
>>> Publishing this because I feel like it's the kind of thing imaginative
>>> minds like the ones here, may be able to develop further. Possibly!
>>>
>>>
>>> waxwing / AdamISZ
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
>>
>
--000000000000cc100b05d6ce781f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div><span style=3D"font-family:arial;font-size:14px"=
>>=C2=A0</span><span style=3D"font-family:arial;font-size:14px">if you h=
ave a counterparty who is malicious and they *take action* to steal, then t=
hey can present you with two alternatives</span><span style=3D"font-family:=
arial;font-size:14px">=C2=A0</span><span style=3D"font-family:arial;font-si=
ze:14px"><br></span></div><div><span style=3D"font-family:arial;font-size:1=
4px"><br></span></div><div><span style=3D"font-family:arial;font-size:14px"=
>Generally I don't think=C2=A0this is the=C2=A0case.=C2=A0</span>
<span style=3D"font-family:arial;font-size:14px">In this case, these are ti=
me-sensitive operations.</span>=C2=A0<span style=3D"font-family:arial;font-=
size:14px">There is no time to negotiate after the malicious party has take=
n action. The software would have already taken counteraction. Negotiation =
would have to happen before broadcast.</span></div></div><div><br></div>>=
;=C2=A0
<span style=3D"font-family:arial;font-size:14px">I've always felt stron=
gly that they do not ultimately work=C2=A0</span><div><span style=3D"font-f=
amily:arial;font-size:14px"><br></span></div><div><font face=3D"arial"><spa=
n style=3D"font-size:14px">So you don't have any specific reasoning you=
can give for that gut feeling? I'm not pushing=C2=A0for burn mechanism=
s, but trying to understand why you're dismissing them.</span></font></=
div><div><span style=3D"font-family:arial;font-size:14px"><br></span></div>=
<div><span style=3D"font-family:arial;font-size:14px"><br></span></div></di=
v><br><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On S=
at, Jan 29, 2022 at 11:16 AM AdamISZ <<a href=3D"mailto:AdamISZ@protonma=
il.com" target=3D"_blank">AdamISZ@protonmail.com</a>> wrote:<br></div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-le=
ft:1px solid rgb(204,204,204);padding-left:1ex"><div style=3D"font-family:a=
rial;font-size:14px"><div style=3D"font-family:arial;font-size:14px">> <=
span style=3D"font-family:arial"><span><span style=3D"font-size:14px">Justi=
ce. Also, there's no incentive for the honest party to not punish - pre=
sumably their software would automatically punish, and why go through any e=
ffort to stop it? A 1 cent bribe certainly wouldn't be enough. Maybe a =
$10 bribe might get someone somewhere to install hacked up software to be a=
ble to fulfill such a bribe, but even then i think it would be a rare perso=
n that would stoop to that. Were it to become a true negotiation, the cheat=
er has more to lose, and therefore the bribee has a lot of leverage.</span>=
</span></span><br></div><div style=3D"font-family:arial;font-size:14px"><br=
></div><div style=3D"font-family:arial;font-size:14px">Justice isn't a =
strong enough incentive, it's too context-dependent, and in particular =
it's not something you could rely on if there is any financial incentiv=
e pushing the other way. Especially the ordering of events: if you have a c=
ounterparty who is malicious and they *take action* to steal, then they can=
present you with two alternatives one of which is more favourable than the=
other, if there is a bribe. It isn't *just* about logic I think, thoug=
h the logic definitely matters.<br></div><div style=3D"font-family:arial;fo=
nt-size:14px"><br></div><div style=3D"font-family:arial;font-size:14px">The=
se arguments about whether we could use 'mutually assured destruction&#=
39; approaches (burn in particular) to make contract enforcement work have =
been ongoing amongst Bitcoin enthusiasts for a decade, I've always felt=
strongly that they do not ultimately work and haven't seen anything to=
change my mind (I seem to remember convincing Manfred Karrer not to use it=
in Bitsquare in 2014/15, but there've been many other examples of peop=
le proposing it and it never really getting traction).<br></div><div style=
=3D"font-family:arial;font-size:14px"><br></div><div style=3D"font-family:a=
rial;font-size:14px">> <span style=3D"font-family:arial"><span><span sty=
le=3D"font-size:14px">One thing I thought of regarding path coin, if there&=
#39;s ever a situation where there are multiple choices in path, whatever p=
unishment there is probably needs to be able to handle the multiple of the =
number of paths.</span></span></span><br></div><div style=3D"font-family:ar=
ial;font-size:14px"><br></div><div style=3D"font-family:arial;font-size:14p=
x"><span style=3D"font-family:arial"><span><span style=3D"font-size:14px">R=
ight, I briefly alluded to setting up with multiple paths - general idea is=
instead of only a->b->c->d->e it's possible to setup the n=
-ary tree, so a can go to all of b,c,d,e etc., but the problem is the facto=
rial blowup that you get even if you restrict to no-revisiting (or exponent=
ial otherwise). For the toy example of 5 participants though, it is entirel=
y possible to build the matrix as illustrated in the gist, but it's an =
N^2 matrix duplicated for every change in the path, here's the simplest=
possible extension of the base case:</span></span></span><br></div><div st=
yle=3D"font-family:arial;font-size:14px"><br></div><div style=3D"font-famil=
y:arial;font-size:14px"><span style=3D"font-family:arial"><span><span style=
=3D"font-size:14px">path 1:=C2=A0 A=C2=A0 B* C* D* E*</span></span></span><=
br></div><div style=3D"font-family:arial;font-size:14px"><span style=3D"fon=
t-family:arial"><span><span style=3D"font-size:14px">path 2:=C2=A0 A=C2=A0 =
B=C2=A0 C* D* E*</span></span></span></div><div style=3D"font-family:arial;=
font-size:14px"><span style=3D"font-family:arial"><span><span style=3D"font=
-size:14px">path 3:=C2=A0 A=C2=A0 B=C2=A0 C* D* E*</span></span></span></di=
v><div style=3D"font-family:arial;font-size:14px"><span style=3D"font-famil=
y:arial"><span><span style=3D"font-size:14px">path 4:=C2=A0 A=C2=A0 B=C2=A0=
C=C2=A0 D* E*</span></span></span></div><div style=3D"font-family:arial;fo=
nt-size:14px"><span style=3D"font-family:arial"><span><span style=3D"font-s=
ize:14px">path 5:=C2=A0 A=C2=A0 B=C2=A0 C=C2=A0 D=C2=A0 E</span></span></sp=
an></div><div style=3D"font-family:arial;font-size:14px"><span style=3D"fon=
t-family:arial"><span><span style=3D"font-size:14px">path 6:=C2=A0 A=C2=A0 =
C* B* D* E*</span></span></span></div><div style=3D"font-family:arial;font-=
size:14px"><span style=3D"font-family:arial"><span><span style=3D"font-size=
:14px">path 7:=C2=A0 A=C2=A0 C=C2=A0 B* D* E*</span></span></span></div><di=
v style=3D"font-family:arial;font-size:14px"><span style=3D"font-family:ari=
al"><span><span style=3D"font-size:14px">path 8:=C2=A0 A=C2=A0 C=C2=A0 B=C2=
=A0 D* E*</span></span></span></div><div style=3D"font-family:arial;font-si=
ze:14px"><span style=3D"font-family:arial"><span><span style=3D"font-size:1=
4px">path 9:=C2=A0 A=C2=A0 C=C2=A0 B=C2=A0 D=C2=A0 E*</span></span></span><=
/div><div style=3D"font-family:arial;font-size:14px"><span style=3D"font-fa=
mily:arial"><span><span style=3D"font-size:14px">path 10: A=C2=A0 C=C2=A0 B=
=C2=A0 D=C2=A0 E</span></span></span></div><div style=3D"font-family:arial;=
font-size:14px"><br></div><div style=3D"font-family:arial;font-size:14px">T=
he * would indicate pre-signs (and this whole list is branches in the tapro=
ot output of the pathcoin); this setup *only* allows one alternate path (se=
cond C instead of second B) for the coin.<br></div><div style=3D"font-famil=
y:arial;font-size:14px"><br></div><div style=3D"font-family:arial;font-size=
:14px">If A chooses to pay B (not C), then: instead of only giving B an ada=
ptor on path1 and signatures on paths 2,3,4,5, A would also have to give B =
adaptors on paths 6-10 as well. So it's easy to see that if you kept ad=
ding branches for every possible spending path A->E with no revisits you=
have like n^2(n-1)! (maybe not exactly; something very similar).<br></div>=
<div style=3D"font-family:arial;font-size:14px">(Notice: though there are m=
ultiple paths via which A can cheat, they all reveal the same adaptor secre=
t (and they're all the same coin) leading to the same forfeit of fideli=
ty bond, see gist for the nice way you can always have it so that a single =
fidelity bond goes to the honest owner).<br></div><div style=3D"font-family=
:arial;font-size:14px"><br></div><div style=3D"font-family:arial;font-size:=
14px">All of this is predicated on the idea that the participants do *not* =
coordinate at all after the initial setup; only a data transfer from payer =
to payee. A pretty massive restriction, of course.<br></div><div style=3D"f=
ont-family:arial;font-size:14px"><br></div><div style=3D"font-family:arial;=
font-size:14px"><div></div><div>Sent with <a href=3D"https://protonmail.com=
/" rel=3D"noopener noreferrer" target=3D"_blank">ProtonMail</a> Secure Emai=
l.</div></div><div style=3D"font-family:arial;font-size:14px"><br></div></d=
iv><div><div>=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=
=90 Original Message =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=
=E2=80=90<br></div><div> On Friday, January 28th, 2022 at 15:27, Billy Tetr=
ud via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.=
org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:=
<br></div><div> <br></div><blockquote type=3D"cite"><div dir=3D"auto"><div>=
> <span><span style=3D"font-family:arial"><span style=3D"font-size:14px"=
>what is the incentive for the honest party to punish? </span></span></span=
><br></div><div dir=3D"auto"><span><span style=3D"font-family:arial"><span =
style=3D"font-size:14px"></span></span></span><br></div><div dir=3D"auto"><=
span style=3D"font-family:arial"><span><span style=3D"font-size:14px">Justi=
ce. Also, there's no incentive for the honest party to not punish - pre=
sumably their software would automatically punish, and why go through any e=
ffort to stop it? A 1 cent bribe certainly wouldn't be enough. Maybe a =
$10 bribe might get someone somewhere to install hacked up software to be a=
ble to fulfill such a bribe, but even then i think it would be a rare perso=
n that would stoop to that. Were it to become a true negotiation, the cheat=
er has more to lose, and therefore the bribee has a lot of leverage.</span>=
</span></span><br></div><div dir=3D"auto"><span style=3D"font-family:arial"=
><span><span style=3D"font-size:14px"></span></span></span><br></div><div d=
ir=3D"auto"><span style=3D"font-family:arial"><span><span style=3D"font-siz=
e:14px">> my strong intuition is that it will never be properly stable.<=
/span></span></span><br></div><div dir=3D"auto"><span style=3D"font-family:=
arial"><span><span style=3D"font-size:14px"></span></span></span><br></div>=
<div dir=3D"auto"><span style=3D"font-family:arial"><span><span style=3D"fo=
nt-size:14px">I'm curious what you mean by "stable". You had =
mentioned the game theory is "fragile" and I'm wondering if t=
here's more to this than just "what incentive does the honest part=
y have to burn?"</span></span></span><br></div><div dir=3D"auto"><span=
style=3D"font-family:arial"><span><span style=3D"font-size:14px"></span></=
span></span><br></div><div dir=3D"auto"><span style=3D"font-family:arial"><=
span><span style=3D"font-size:14px">To be clear, I'm not advocating for=
Sabu and I haven't done any deep thinking about burn based incentives.=
</span></span></span><br></div><div dir=3D"auto"><span style=3D"font-family=
:arial"><span><span style=3D"font-size:14px"></span></span></span><br></div=
><div dir=3D"auto"><span style=3D"font-family:arial"><span><span style=3D"f=
ont-size:14px">One thing I thought of regarding path coin, if there's e=
ver a situation where there are multiple choices in path, whatever punishme=
nt there is probably needs to be able to handle the multiple of the number =
of paths. The only way around this i can imagine is to have some method of =
coordination between payees, eg a place where a payee records their payment=
such that a payee who has been double spent on to become aware they've=
been double spent on and initiate the punishment. But once you have that c=
oordination mechanism it starts not looking more like an on chain transacti=
on.</span></span></span><br></div></div><div><br></div><div class=3D"gmail_=
quote"><div dir=3D"ltr" class=3D"gmail_attr">On Tue, Jan 25, 2022, 06:50 Ad=
amISZ <<a rel=3D"noopener noreferrer" href=3D"mailto:AdamISZ@protonmail.=
com" target=3D"_blank">AdamISZ@protonmail.com</a>> wrote:<br></div><bloc=
kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:=
1px solid rgb(204,204,204);padding-left:1ex"><div style=3D"font-family:aria=
l;font-size:14px"><div style=3D"font-family:arial;font-size:14px">Hi Billy,=
<br></div><div style=3D"font-family:arial;font-size:14px">I read through th=
e description. I think systems like this *mostly* fail due to game theory.<=
br></div><div style=3D"font-family:arial;font-size:14px"><br></div><div sty=
le=3D"font-family:arial;font-size:14px">With punishment-by-burn you have va=
rious issues that make it to my mind pretty unstable, too unstable to use f=
or any serious system. To be fair, this isn't cut-and-dried. So let me =
unpack:<br></div><div style=3D"font-family:arial;font-size:14px"><br></div>=
<div style=3D"font-family:arial;font-size:14px">(I briefly touched on why I=
dismissed penalties via burn in my gist, section: "Not feeling the bu=
rn".)<br></div><div style=3D"font-family:arial;font-size:14px"><br></d=
iv><div style=3D"font-family:arial;font-size:14px">There is a distinction b=
etween penalty via burn to unspendable output and penalty via burn to miner=
fees. The latter has an obvious problem: if your counterparties collude wi=
th (or are) miners, they may not actually be penalized at all (now to be cl=
ear, that is a problematic attack ex nihilo: nobody usually can be sure who=
's mining the next block, but markets have a way of solving and coordin=
ating such things: see e.g. the various MEV discussions and initiatives in =
Ethereum for an example of that).<br></div><div style=3D"font-family:arial;=
font-size:14px"><br></div><div style=3D"font-family:arial;font-size:14px">B=
ut the former (provable burn) is still imo extremely unstable: if the penal=
ty tx destroys all the money, what is the incentive for the honest party to=
punish? In such a scenario even a one cent donation from the attacker to t=
he victim might prevent the penalty from happening.<br></div><div style=3D"=
font-family:arial;font-size:14px">You can combine 'destruction of most,=
or some, of the funds' with a smaller payout to the aggrieved party, b=
ut then again you have to factor in the possibility of bribes. The Sabu pos=
t you linked describes it as: "There are precise and delicate formulas=
for calculating the amount of
loss of the issuer and the creditor, which ensures that just and true
act in both parties are cost-effective in all situations." I agree it&=
#39;s delicate, but after having spent time looking into these things, my s=
trong intuition is that it will never be properly stable.<br></div><div sty=
le=3D"font-family:arial;font-size:14px"><br></div><div style=3D"font-family=
:arial;font-size:14px">In the PathCoin description I am specifically lookin=
g for a trustless system, with this finesse: we still count it as trustless=
even though we are using penalties as disincentive, because the penalty *c=
onsists of a payment directly from the attacker to the attacked, and that p=
ayment is larger than the amount stolen*. I claim that that *is* stable.<br=
></div><div style=3D"font-family:arial;font-size:14px"><br></div><div style=
=3D"font-family:arial;font-size:14px">Notice that Lightning has the same mo=
del (in LN-Penalty), as long as 'claiming the whole channel capacity=
9; is enough to be larger than what is stolen (see: channel reserves etc.).=
<br></div><div style=3D"font-family:arial;font-size:14px"><br></div><div st=
yle=3D"font-family:arial;font-size:14px"><div><br></div><div>Sent with <a h=
ref=3D"https://protonmail.com/" rel=3D"noopener noreferrer" target=3D"_blan=
k">ProtonMail</a> Secure Email.<br></div></div><div style=3D"font-family:ar=
ial;font-size:14px"><br></div></div><div style=3D"font-family:arial;font-si=
ze:14px"><br></div><div><div>=E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=80=90=
=E2=80=90=E2=80=90 Original Message =E2=80=90=E2=80=90=E2=80=90=E2=80=90=E2=
=80=90=E2=80=90=E2=80=90<br></div><div>On Tuesday, January 25th, 2022 at 11=
:53, Billy Tetrud via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.l=
inuxfoundation.org" rel=3D"noopener noreferrer" target=3D"_blank">bitcoin-d=
ev@lists.linuxfoundation.org</a>> wrote:<br></div><div><br></div><blockq=
uote type=3D"cite"><div dir=3D"auto"><div>There was a protocol someone ment=
ioned a while back called Sabu that had the same goals. As i recall, it had=
some pretty promising constructs, but would have a critical vulnerability =
that could be exploited by miners. This is the write up:<br></div><div dir=
=3D"auto"><br></div><div dir=3D"auto"><a rel=3D"noopener noreferrer" href=
=3D"https://raymo-49157.medium.com/time-to-boost-bitcoin-circulation-millio=
n-transactions-per-second-and-privacy-1eef8568d180" target=3D"_blank">https=
://raymo-49157.medium.com/time-to-boost-bitcoin-circulation-million-transac=
tions-per-second-and-privacy-1eef8568d180</a><br></div><div dir=3D"auto"><b=
r></div><div dir=3D"auto">Perhaps some of the techniques there could be com=
bined with your ideas to get closer to a solution.<br></div></div><div><br>=
</div><div class=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On M=
on, Jan 24, 2022, 08:51 AdamISZ via bitcoin-dev <<a rel=3D"noopener nore=
ferrer" href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br></div><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px=
solid rgb(204,204,204);padding-left:1ex"><div>Hello list,<br></div><div><b=
r></div><div>I took the time to write up this rather out-there idea:<br></d=
iv><div><br></div><div>Imagine you wanted to send a coin just like email, i=
.e. just transfer data to the counterparty.<br></div><div><br></div><div>Cl=
early this is in general entirely impossible; but with what restrictions an=
d assumptions could you create a toy version of it?<br></div><div><br></div=
><div>See this gist for a detailed build up of the idea:<br></div><div><br>=
</div><div><a href=3D"https://gist.github.com/AdamISZ/b462838cbc8cc06aae0c1=
5610502e4da" rel=3D"noopener noreferrer" target=3D"_blank">https://gist.git=
hub.com/AdamISZ/b462838cbc8cc06aae0c15610502e4da</a><br></div><div><br></di=
v><div>Basically: using signature adaptors and CTV or a similar covenant, y=
ou could create a fully trustless transfer of control of a utxo from one pa=
rty to another with no interaction with the rest of the group, at the time =
of transfer (modulo of course lots and lots of one-time setup).<br></div><d=
iv><br></div><div>The limitations are extreme and as you'd imagine. In =
the gist I feel like I got round one of them, but not the others.<br></div>=
<div><br></div><div>(I very briefly mention comparison to e.g. statechains =
or payment pools; they are making other tradeoffs against the 'digital =
cash' type of goal. There is no claim that this 'pathcoin' idea=
is even viable yet, let alone better than those ideas).<br></div><div><br>=
</div><div>Publishing this because I feel like it's the kind of thing i=
maginative minds like the ones here, may be able to develop further. Possib=
ly!<br></div><div><br></div><div><br></div><div>waxwing / AdamISZ<br></div>=
<div>_______________________________________________<br></div><div>bitcoin-=
dev mailing list<br></div><div><a href=3D"mailto:bitcoin-dev@lists.linuxfou=
ndation.org" rel=3D"noopener noreferrer" target=3D"_blank">bitcoin-dev@list=
s.linuxfoundation.org</a><br></div><div><a href=3D"https://lists.linuxfound=
ation.org/mailman/listinfo/bitcoin-dev" rel=3D"noopener noreferrer" target=
=3D"_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev<=
/a><br></div></blockquote></div></blockquote></div><div style=3D"font-famil=
y:arial;font-size:14px"><br></div></blockquote></div></blockquote></div><di=
v style=3D"font-family:arial;font-size:14px"><br></div></blockquote></div>
--000000000000cc100b05d6ce781f--
|