diff options
| author | Billy Tetrud <billy.tetrud@gmail.com> | 2022-01-30 09:39:04 -0600 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2022-01-30 15:39:26 +0000 |
| commit | 2842142588acd8c8bb0ae5958f69f2573bfb5e6d (patch) | |
| tree | fe877e3d5d3aee43d5151dbae953a4dbb11e4045 /0c/9312a9909d710f45fbdc38197674ad042ad872 | |
| parent | d90e751b5b1558f67bed7317cf2624666d1bf090 (diff) | |
| download | pi-bitcoindev-2842142588acd8c8bb0ae5958f69f2573bfb5e6d.tar.gz pi-bitcoindev-2842142588acd8c8bb0ae5958f69f2573bfb5e6d.zip | |
Re: [bitcoin-dev] PathCoin
Diffstat (limited to '0c/9312a9909d710f45fbdc38197674ad042ad872')
| -rw-r--r-- | 0c/9312a9909d710f45fbdc38197674ad042ad872 | 632 |
1 files changed, 632 insertions, 0 deletions
diff --git a/0c/9312a9909d710f45fbdc38197674ad042ad872 b/0c/9312a9909d710f45fbdc38197674ad042ad872 new file mode 100644 index 000000000..13f9d5bf0 --- /dev/null +++ b/0c/9312a9909d710f45fbdc38197674ad042ad872 @@ -0,0 +1,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-- + |