path: root/81/b13ed4d183629bd21fc0859882e0da03b52470

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