From: AdamISZ <AdamISZ@protonmail.com>
To: Billy Tetrud <billy.tetrud@gmail.com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] PathCoin
Date: Tue, 25 Jan 2022 12:50:32 +0000 [thread overview]
Message-ID: <By1G6iST5DCXZJVfEd3HzdPgU3e_NGoqvH-5UoqsOzY8qjiOmy5iHXiOwjXtm7Znq1Z6z-XOL0IPDSyQiLOZ6-lRQ-vi1I6Cba4aqywe8xw=@protonmail.com> (raw)
In-Reply-To: <CAGpPWDY3vZ2JOsa1UhoT-z8kfxqkVWcq1nyt9Ah5ye6HE_6gOQ@mail.gmail.com>
[-- 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 --]
next prev parent reply other threads:[~2022-01-25 12:50 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-24 14:43 [bitcoin-dev] PathCoin AdamISZ
2022-01-25 11:53 ` Billy Tetrud
2022-01-25 12:50 ` AdamISZ [this message]
2022-01-28 15:27 ` Billy Tetrud
2022-01-29 17:16 ` AdamISZ
2022-01-30 15:39 ` Billy Tetrud
2022-02-20 18:26 ` AdamISZ
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='By1G6iST5DCXZJVfEd3HzdPgU3e_NGoqvH-5UoqsOzY8qjiOmy5iHXiOwjXtm7Znq1Z6z-XOL0IPDSyQiLOZ6-lRQ-vi1I6Cba4aqywe8xw=@protonmail.com' \
--to=adamisz@protonmail.com \
--cc=billy.tetrud@gmail.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox