summaryrefslogtreecommitdiff
path: root/81/b13ed4d183629bd21fc0859882e0da03b52470
blob: 17f9ce7b4e0085e003fef6398db560af59f769db (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
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