AdamISZ [ARCHIVE] on Nostr: 📅 Original date posted:2022-01-25 📝 Original message:Hi Billy, I read through ...
📅 Original date posted:2022-01-25
📝 Original message: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/20220125/e672234b/attachment.html>;
📝 Original message: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/20220125/e672234b/attachment.html>;