AdamISZ [ARCHIVE] on Nostr: š Original date posted:2022-02-20 š Original message:An update, after some ...
š
Original date posted:2022-02-20
š Original message: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 can send, to A85, the set: adaptor sigma'_86 (that reveals t_86 if the real partial sig, sigma_86_86 were revealed), and their authorizations to spend it forwards (basically sigma_86_87, sigma_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 participant 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 etc etc) without anything but a transfer of info from Bob to Carol; nobody else 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, need to be running a hot wallet, because we're talking about the case of a user not holding any funds, just some pre-prepared signature data. If a request comes in to A86 to use it, it could accept and then just forget about this 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 outsourcing makes sense here: a recipient can only truly know that they can't receive the coin if they themselves are directly sending out the revocation data (adaptor, etc.). Perhaps arguable; if outsourced the scheme seems a lot more practical.
A failure of this mechanism due to offline-ness is unfortunate because we lose hopping functionality, but at least it's not a security risk. Maybe just 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-chain** (B1..B100 say), in a way that makes sense and is useful? I *think* it would require the 'baggage' of the ~ 1 MB of data from the A100 set's payment history be forwarded for each payment in the new group. (What's the real size? I think: max 100 adaptors, plus 100 scriptpubkeys (representing revocation), max 10K partial signatures but probably a lot less, so < 1MB from the 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* so nice, is that the original timelock carries over to the new group, who would have to use a shorter one ...
Not sure, but I might update and change the gist to include this new line of 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-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
š Original message: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 can send, to A85, the set: adaptor sigma'_86 (that reveals t_86 if the real partial sig, sigma_86_86 were revealed), and their authorizations to spend it forwards (basically sigma_86_87, sigma_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 participant 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 etc etc) without anything but a transfer of info from Bob to Carol; nobody else 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, need to be running a hot wallet, because we're talking about the case of a user not holding any funds, just some pre-prepared signature data. If a request comes in to A86 to use it, it could accept and then just forget about this 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 outsourcing makes sense here: a recipient can only truly know that they can't receive the coin if they themselves are directly sending out the revocation data (adaptor, etc.). Perhaps arguable; if outsourced the scheme seems a lot more practical.
A failure of this mechanism due to offline-ness is unfortunate because we lose hopping functionality, but at least it's not a security risk. Maybe just 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-chain** (B1..B100 say), in a way that makes sense and is useful? I *think* it would require the 'baggage' of the ~ 1 MB of data from the A100 set's payment history be forwarded for each payment in the new group. (What's the real size? I think: max 100 adaptors, plus 100 scriptpubkeys (representing revocation), max 10K partial signatures but probably a lot less, so < 1MB from the 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* so nice, is that the original timelock carries over to the new group, who would have to use a shorter one ...
Not sure, but I might update and change the gist to include this new line of 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-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