AdamISZ [ARCHIVE] on Nostr: š Original date posted:2022-01-29 š Original message:> Justice. Also, there's ...
š
Original date posted:2022-01-29
š Original message:> 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 at 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 at 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 at 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 at 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 at lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220129/ad458d2e/attachment-0001.html>;
š Original message:> 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 at 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 at 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 at 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 at 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 at lists.linuxfoundation.org
>>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220129/ad458d2e/attachment-0001.html>;