diff options
| author | AdamISZ <AdamISZ@protonmail.com> | 2022-02-20 18:26:30 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2022-02-20 18:26:40 +0000 |
| commit | 278290df768ebafc375f01bd99fd49915fd178fe (patch) | |
| tree | 216f0fdff902fcc89eb3e9f6561f547354f6f947 | |
| parent | 4a74221ac2b59b795019e383e089224f68d2df96 (diff) | |
| download | pi-bitcoindev-278290df768ebafc375f01bd99fd49915fd178fe.tar.gz pi-bitcoindev-278290df768ebafc375f01bd99fd49915fd178fe.zip | |
Re: [bitcoin-dev] PathCoin
| -rw-r--r-- | 81/b13ed4d183629bd21fc0859882e0da03b52470 | 245 |
1 files changed, 245 insertions, 0 deletions
diff --git a/81/b13ed4d183629bd21fc0859882e0da03b52470 b/81/b13ed4d183629bd21fc0859882e0da03b52470 new file mode 100644 index 000000000..17f9ce7b4 --- /dev/null +++ b/81/b13ed4d183629bd21fc0859882e0da03b52470 @@ -0,0 +1,245 @@ +Return-Path: <AdamISZ@protonmail.com> +Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) + by lists.linuxfoundation.org (Postfix) with ESMTP id 99112C0011 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 20 Feb 2022 18:26:40 +0000 (UTC) +Received: from localhost (localhost [127.0.0.1]) + by smtp2.osuosl.org (Postfix) with ESMTP id 86A7C4049B + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 20 Feb 2022 18:26:40 +0000 (UTC) +X-Virus-Scanned: amavisd-new at osuosl.org +X-Spam-Flag: NO +X-Spam-Score: -2.102 +X-Spam-Level: +X-Spam-Status: No, score=-2.102 tagged_above=-999 required=5 + tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, + DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, + RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] + autolearn=ham autolearn_force=no +Authentication-Results: smtp2.osuosl.org (amavisd-new); + dkim=pass (2048-bit key) header.d=protonmail.com +Received: from smtp2.osuosl.org ([127.0.0.1]) + by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) + with ESMTP id z3wFbgGTipI4 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 20 Feb 2022 18:26:38 +0000 (UTC) +X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 +Received: from mail-40131.protonmail.ch (mail-40131.protonmail.ch + [185.70.40.131]) + by smtp2.osuosl.org (Postfix) with ESMTPS id 657D94031C + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 20 Feb 2022 18:26:37 +0000 (UTC) +Date: Sun, 20 Feb 2022 18:26:30 +0000 +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; + s=protonmail3; t=1645381593; + bh=PCnH0chrngh4UefrV9mIzNATNB4su2Q3vV28/r7kbhI=; + h=Date:To:From:Reply-To:Subject:Message-ID:In-Reply-To:References: + From:To:Cc:Date:Subject:Reply-To:Feedback-ID:Message-ID; + b=ci6glV+CeXKjHXTID64D86aUq3E9YgbK8V9euwnxNcbMTC/TgL85AnRKVR/NNYbdL + SPGEtcYccOYySQGVzUJUo0IvRmbxYLjApTrYJC8NmoYgoTC1foB7uk/IfMKgbtSMuy + PCaApN8eU0M1QVDZSJB1ypbro5Iguz+dKH5yqFlEFKUs1PJUYkmGTOfbSnNDFVt6Km + tKGASP1dBb+/6aQpCaw4RPMtg2C7Wn2QYY1CHCLkEo+M2oPfypcbBx1BMrUuSKw9aP + fqowbl2UT9P7vc9XF7M1NoiRqa5Y2lnMqf71EteKM3+o8cLXnCkjJP3jU1s8Owrhn5 + OFoXDXHKgFELQ== +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 +X-Mailman-Approved-At: Sun, 20 Feb 2022 18:38:54 +0000 +Subject: Re: [bitcoin-dev] PathCoin +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.15 +Precedence: list +List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Sun, 20 Feb 2022 18:26:40 -0000 + +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 + |