Date: Sun, 20 Feb 2022 18:26:30 +0000
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: AdamISZ <AdamISZ@protonmail.com>
Reply-To: AdamISZ <AdamISZ@protonmail.com>
Message-ID: <LrR7Dy8D4Wy7OmF7g4k1VwqyPiRZIEBBmn_oYL8IxfsPQq23mRqiP-LwrSHif9aFkpN_M8H5NNfrI3ONTKDjBk4kolznvEHKkpObdx1iFus=@protonmail.com>
In-Reply-To: <jMANAdspMdPb1ZCFttQ3tGmkZ0oYojLY5Oz1d8ZSNl3JhZeDuT1xK0vxTu8uyHcgPXWsM_6XNb3R9tVD3_Yez88pviFrCaNt7LPqdWVBWus=@protonmail.com>
References: <jMANAdspMdPb1ZCFttQ3tGmkZ0oYojLY5Oz1d8ZSNl3JhZeDuT1xK0vxTu8uyHcgPXWsM_6XNb3R9tVD3_Yez88pviFrCaNt7LPqdWVBWus=@protonmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] PathCoin
Precedence: list

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 fideli=
ty bond requirement entirely with an eltoo/D-R-O type mechanism, assuming A=
POAS.
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 mec=
hanisms we can just do a very large multiparty channel no? And not have thi=
s severe utxo denomination issue, nor fixed paths? All true, so that's prob=
ably way more interesting, but in this, we're looking for one property in p=
articular - ability to pass coins without *anyone* needing to sign with a h=
ot wallet - let alone *everyone* needing to sign.)

1. No fidelity bond:

The first of these two is more technically hairy, but, setting the stage ag=
ain:

Say 100 keyholders in initial setup, A1 .. A100 (larger numbers this time t=
o keep scale more realistically in mind). A1 funds a script U which is a mu=
sig key prepared for this as N of N between these 100.

As before, they need 100 separate tapscript leafs (in case we need differen=
t keysets for each, but I think we don't and it's inefficient, h/t Jeremy R=
ubin for pointing that out) or more simply, 100 separate Musig2 protocol ru=
ns, 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 partia=
ls. Who shares what is shown in the tables in the gist linked below (i.e. t=
his is not changing that part of the mechanism) (there would be around 5000=
 signature partials shared in the setup). As before, adaptors for individua=
l 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 do=
es this adaptor, verifiably, enforce, if the "wrong" signature is used? Sug=
gestion 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 verifia=
bly connected to T_x, will allow the coin spent from U to be passed directl=
y back into U. Using APOAS for the signatures, as with eltoo, would mean th=
at the existing prepared set of signatures for the initial funding of U, st=
ill applies. I wave hands here about btc amount being fixed, and fees - I p=
resume 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 similarl=
y use a state number enforcing ordering (and hence APOAS). The valid-by-pro=
tocol current owner of the pathcoin would still be the only one able to suc=
cessfully 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 ou=
tline, it trades off: timelocked ownership of the pathcoin (previously time=
locked 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 impr=
actical at any scale. So it's barely a tradeoff and seems a huge win, if fu=
nctional.

Important caveat: though it would remove the collateral-posting requirement=
, it wouldn't remove the timelock aspect: so we're still only able to opera=
te 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: F=
or a fixed path of 100 users we would clearly get far too little utility fr=
om a fixed path between them. The factorial blowup has been noted many time=
s. What isn't yet clear to me is: if you had fairly long paths like this an=
d were able to jump over, i.e. in A, B, C, D, E, A could pay anyone, B coul=
d pay (C, D, E), C could pay (D, E) etc., if this extra flexibility were co=
mbined with cleverly arranged lists of other paths, might we have a somewha=
t 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 t=
o make the payment, i.e. A86 can voluntarily revoke their right to this pat=
hcoin, as they never owned it - they can send, to A85, the set: adaptor sig=
ma'_86 (that reveals t_86 if the real partial sig, sigma_86_86 were reveale=
d), and their authorizations to spend it forwards (basically sigma_86_87, s=
igma_86_88 .. sigma_86_100), and A85 can combine that with the rest of the =
set needed to pass on to A87. The recipient, A87, needn't even know which p=
articipant earlier in the path, sent to them (at least, I think so, but if =
that's not true it doesn't make it useless).

The problem here is obvious: we were hoping that Bob could pay Carol (and e=
tc etc) without anything but a transfer of info from Bob to Carol; nobody e=
lse should have to be involved. But I think we could at least conceive that=
 software running this protocol could stay online - it wouldn't, notice, ne=
ed to be running a hot wallet, because we're talking about the case of a us=
er not holding any funds, just some pre-prepared signature data. If a reque=
st comes in to A86 to use it, it could accept and then just forget about th=
is particular pathcoin (one would imagine it maintaining state for many of =
them at once, of course). I'd note that unfortunately I don't think outsour=
cing makes sense here: a recipient can only truly know that they can't rece=
ive the coin if they themselves are directly sending out the revocation dat=
a (adaptor, etc.). Perhaps arguable; if outsourced the scheme seems a lot m=
ore practical.

A failure of this mechanism due to offline-ness is unfortunate because we l=
ose hopping functionality, but at least it's not a security risk. Maybe jus=
t try another pathcoin.

3.? Moving to new keyholders?

But there wasn't a 3 :) I'm just not sure about this, but is there a way to=
 have one recipient in A1..A100 send out to a new pathcoin group **off-chai=
n** (B1..B100 say), in a way that makes sense and is useful? I *think* it w=
ould require the 'baggage' of the ~ 1 MB of data from the A100 set's paymen=
t history be forwarded for each payment in the new group. (What's the real =
size? I think: max 100 adaptors, plus 100 scriptpubkeys (representing revoc=
ation), max 10K partial signatures but probably a lot less, so < 1MB from t=
he whole thing I believe). Also nice is that the monitoring on chain of the=
 whole A history is just one utxo, the one that funded U initially. *Not* s=
o nice, is that the original timelock carries over to the new group, who wo=
uld have to use a shorter one ...

Not sure, but I might update and change the gist to include this new line o=
f thinking, in particular in (1) above .. at least if it makes sense :)

Regards,
waxwing / AdamISZ


Sent with ProtonMail Secure Email.

------- Original Message -------

On Monday, January 24th, 2022 at 14:43, AdamISZ via bitcoin-dev <bitcoin-de=
v@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 dat=
a to the counterparty.
>
> Clearly this is in general entirely impossible; but with what restriction=
s 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 co=
uld create a fully trustless transfer of control of a utxo from one party t=
o another with no interaction with the rest of the group, at the time of tr=
ansfer (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. Th=
ere is no claim that this 'pathcoin' idea is even viable yet, let alone bet=
ter than those ideas).
>
> Publishing this because I feel like it's the kind of thing imaginative mi=
nds 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