From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 99112C0011 for ; 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 ; 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 ; 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 ; 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 From: AdamISZ Reply-To: AdamISZ Message-ID: In-Reply-To: References: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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