Re: [bitcoin-dev] PathCoin

2022-01-25 Thread Billy Tetrud via bitcoin-dev
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
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] PathCoin

2022-01-25 Thread AdamISZ via bitcoin-dev
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 
 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 
>  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___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


Re: [bitcoin-dev] [dlc-dev] CTV dramatically improves DLCs

2022-01-25 Thread Jonas Nick via bitcoin-dev

Thank you, that's an interesting application of OP_CTV.

Perhaps worth pointing out that this does not require OP_CTV but could also be
enabled by other covenant constructions. For example, it seems like
ANYPREVOUT-based covenants provide similar benefits. The script of the Taproot
leaves could be set to

  CHECKSIGVERIFY  CHECKSIGVERIFY

where  is an ANYPREVOUTANYSCRIPT signature of the CET for public key P = G.
When using nonce R = G, signature creation has negligible computational cost (s
= 1 + H(R, P, m)). A downside compared to CTV is the additional overhead of 64
witness bytes ().
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev