[bitcoin-dev] PathCoin

[bitcoin-dev] PathCoin

[AdamISZ]

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 party 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 alone 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

Re: [bitcoin-dev] PathCoin

[Billy Tetrud]

[-- Attachment #1: Type: text/plain, Size: 2027 bytes --]

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, but
would have a critical vulnerability that could be exploited by miners. This
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 to
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 party
> 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 alone
> 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
>

[-- Attachment #2: Type: text/html, Size: 2964 bytes --]

Re: [bitcoin-dev] PathCoin

[AdamISZ]

[-- Attachment #1: Type: text/plain, Size: 4546 bytes --]

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 and penalty via burn to miner fees. The latter has an obvious problem: if your counterparties collude with (or are) miners, they may not actually be penalized at all (now to be clear, 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 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: "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's delicate, but after having spent time looking into these things, my strong intuition is 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 is stolen (see: channel reserves etc.).

Sent with [ProtonMail](https://protonmail.com/) Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
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, but would have a critical vulnerability that could be exploited by miners. This 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 to 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 party 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 alone 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

[-- Attachment #2: Type: text/html, Size: 7433 bytes --]

Re: [bitcoin-dev] PathCoin

[Billy Tetrud]

[-- Attachment #1: Type: text/plain, Size: 6412 bytes --]

> 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, the
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 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
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 and
> penalty via burn to miner fees. The latter has an obvious problem: if your
> counterparties collude with (or are) miners, they may not actually be
> penalized at all (now to be clear, 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 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: "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's delicate, but
> after having spent time looking into these things, my strong intuition is
> 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 is
> stolen (see: channel reserves etc.).
>
> Sent with ProtonMail <https://protonmail.com/> Secure Email.
>
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> 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, but
> would have a critical vulnerability that could be exploited by miners. This
> 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 to
> 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 party
>> 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 alone
>> 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
>>
>
>

[-- Attachment #2: Type: text/html, Size: 10208 bytes --]

Re: [bitcoin-dev] PathCoin

[AdamISZ]

[-- Attachment #1: Type: text/plain, Size: 10007 bytes --]

> 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, the 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* about 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 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 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, so 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 adding 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 always 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 payer to payee. A pretty massive restriction, of course.

Sent with [ProtonMail](https://protonmail.com/) Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
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, the 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 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 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 and penalty via burn to miner fees. The latter has an obvious problem: if your counterparties collude with (or are) miners, they may not actually be penalized at all (now to be clear, 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 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: "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's delicate, but after having spent time looking into these things, my strong intuition is 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 is stolen (see: channel reserves etc.).
>>
>> Sent with [ProtonMail](https://protonmail.com/) Secure Email.
>>
>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>> 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, but would have a critical vulnerability that could be exploited by miners. This 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 to 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 party 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 alone 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

[-- Attachment #2: Type: text/html, Size: 18542 bytes --]

Re: [bitcoin-dev] PathCoin

[Billy Tetrud]

[-- Attachment #1: Type: text/plain, Size: 11273 bytes --]

> 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 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, the
> 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* about
> 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 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 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, so
> 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 adding
> 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 always
> 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 payer
> to payee. A pretty massive restriction, of course.
>
> Sent with ProtonMail <https://protonmail.com/> Secure Email.
>
> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
> 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, the
> 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 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
> 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 and
>> penalty via burn to miner fees. The latter has an obvious problem: if your
>> counterparties collude with (or are) miners, they may not actually be
>> penalized at all (now to be clear, 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 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: "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's delicate, but
>> after having spent time looking into these things, my strong intuition is
>> 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 is
>> stolen (see: channel reserves etc.).
>>
>>
>> Sent with ProtonMail <https://protonmail.com/> Secure Email.
>>
>>
>> ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
>> 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, but
>> would have a critical vulnerability that could be exploited by miners. This
>> 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 to
>> 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 party
>>> 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 alone
>>> 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
>>>
>>
>>
>

[-- Attachment #2: Type: text/html, Size: 19426 bytes --]

Re: [bitcoin-dev] PathCoin

[AdamISZ]

An update, after some feedback, and me using the odd hour here and there to try to push this idea forward a bit:

1. I think (though I'm not 100% certain) that you can get rid of the fidelity bond requirement entirely with an eltoo/D-R-O type mechanism, assuming APOAS.
2. With a relaxation of online-ness requirement (see below) I think you can jump steps in the path.

(Before I get into all this you might reasonably ask - well, with eltoo mechanisms we can just do a very large multiparty channel no? And not have this severe utxo denomination issue, nor fixed paths? All true, so that's probably way more interesting, but in this, we're looking for one property in particular - ability to pass coins without *anyone* needing to sign with a hot wallet - let alone *everyone* needing to sign.)

1. No fidelity bond:

The first of these two is more technically hairy, but, setting the stage again:

Say 100 keyholders in initial setup, A1 .. A100 (larger numbers this time to keep scale more realistically in mind). A1 funds a script U which is a musig key prepared for this as N of N between these 100.

As before, they need 100 separate tapscript leafs (in case we need different keysets for each, but I think we don't and it's inefficient, h/t Jeremy Rubin for pointing that out) or more simply, 100 separate Musig2 protocol runs, in each one they are signing a tx to each of them individually, but not completing the run, i.e. only certain parties share their signature partials. Who shares what is shown in the tables in the gist linked below (i.e. this is not changing that part of the mechanism) (there would be around 5000 signature partials shared in the setup). As before, adaptors for individual partial sigs will be shared by A1, A2 etc when the pass on the coin from An to An+1.

But the difference now is that they do not post a fidelity bond. So what does this adaptor, verifiably, enforce, if the "wrong" signature is used? Suggestion here is: the destination each party A_x is signing the coin over is not just exclusive ownership, but (A_x + TL OR CTV(back to script U) + T_x). Translating the rough pseudo-script: if A_x has transferred the coin but then 'illegally' broadcasts, they, having revealed the adaptor t_x verifiably connected to T_x, will allow the coin spent from U to be passed directly back into U. Using APOAS for the signatures, as with eltoo, would mean that the existing prepared set of signatures for the initial funding of U, still applies. I wave hands here about btc amount being fixed, and fees - I presume that SIGHASH_SINGLE, as in the eltoo paper (or?), handles all that - and there may need to be finesse there to create economic disincentive to wrongly publish.
Going further with the eltoo mechanism - for this to work we would similarly use a state number enforcing ordering (and hence APOAS). The valid-by-protocol current owner of the pathcoin would still be the only one able to successfully spend it after the miscreant action led to no successful theft. I presume the same nLockTime trick works.

I may have got some or all of that wrong, but if it's correct in general outline, it trades off: timelocked ownership of the pathcoin (previously timelocked ownership of the fidelity bond), but it means you don't have to post collateral upfront, which was *one* factor that made the thing hugely impractical at any scale. So it's barely a tradeoff and seems a huge win, if functional.

Important caveat: though it would remove the collateral-posting requirement, it wouldn't remove the timelock aspect: so we're still only able to operate this in a pre-agreed time window.

2. Jumping over hops:

This is more of an actual tradeoff, but I can imagine it being necessary: For a fixed path of 100 users we would clearly get far too little utility from a fixed path between them. The factorial blowup has been noted many times. What isn't yet clear to me is: if you had fairly long paths like this and were able to jump over, i.e. in A, B, C, D, E, A could pay anyone, B could pay (C, D, E), C could pay (D, E) etc., if this extra flexibility were combined with cleverly arranged lists of other paths, might we have a somewhat useful system? Let me suggest a way that it's *kind of possible* to do it, and leave the combinatorial discussion for later:

Nothing fancy: just notice, let's say A87 wants to receive the coin from a pseudonymous user AX who is not specifying their position in the ordering (but they have to be X < 87): what A87 needs is a full set of revocations of all owners before 87, along with a pre-authorization of all receivers post-87. In some logical sense that is "coming from" A86, because A86 has to be included in that set, but it needn't literally be A86 doing the paying, I'd claim: suppose it's actually A85. A85 only needs to get A86's agreement to make the payment, i.e. A86 can voluntarily revoke their right to this pathcoin, as they never owned it - they can send, to A85, the set: adaptor sigma'_86 (that reveals t_86 if the real partial sig, sigma_86_86 were revealed), and their authorizations to spend it forwards (basically sigma_86_87, sigma_86_88 .. sigma_86_100), and A85 can combine that with the rest of the set needed to pass on to A87. The recipient, A87, needn't even know which participant earlier in the path, sent to them (at least, I think so, but if that's not true it doesn't make it useless).

The problem here is obvious: we were hoping that Bob could pay Carol (and etc etc) without anything but a transfer of info from Bob to Carol; nobody else should have to be involved. But I think we could at least conceive that software running this protocol could stay online - it wouldn't, notice, need to be running a hot wallet, because we're talking about the case of a user not holding any funds, just some pre-prepared signature data. If a request comes in to A86 to use it, it could accept and then just forget about this particular pathcoin (one would imagine it maintaining state for many of them at once, of course). I'd note that unfortunately I don't think outsourcing makes sense here: a recipient can only truly know that they can't receive the coin if they themselves are directly sending out the revocation data (adaptor, etc.). Perhaps arguable; if outsourced the scheme seems a lot more practical.

A failure of this mechanism due to offline-ness is unfortunate because we lose hopping functionality, but at least it's not a security risk. Maybe just try another pathcoin.

3.? Moving to new keyholders?

But there wasn't a 3 :) I'm just not sure about this, but is there a way to have one recipient in A1..A100 send out to a new pathcoin group **off-chain** (B1..B100 say), in a way that makes sense and is useful? I *think* it would require the 'baggage' of the ~ 1 MB of data from the A100 set's payment history be forwarded for each payment in the new group. (What's the real size? I think: max 100 adaptors, plus 100 scriptpubkeys (representing revocation), max 10K partial signatures but probably a lot less, so < 1MB from the whole thing I believe). Also nice is that the monitoring on chain of the whole A history is just one utxo, the one that funded U initially. *Not* so nice, is that the original timelock carries over to the new group, who would have to use a shorter one ...

Not sure, but I might update and change the gist to include this new line of thinking, in particular in (1) above .. at least if it makes sense :)

Regards,
waxwing / AdamISZ


Sent with ProtonMail Secure Email.

------- Original Message -------

On Monday, January 24th, 2022 at 14:43, 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 party 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 alone 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