Re: [bitcoin-dev] PathCoin

[AdamISZ via bitcoin-dev]

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 

Re: [bitcoin-dev] PathCoin

[Billy Tetrud via bitcoin-dev]

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

Re: [bitcoin-dev] PathCoin

[AdamISZ via bitcoin-dev]

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

Re: [bitcoin-dev] PathCoin

[Billy Tetrud via bitcoin-dev]

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

Re: [bitcoin-dev] PathCoin

[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] PathCoin

[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

[bitcoin-dev] PathCoin

[AdamISZ via bitcoin-dev]

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