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
|
Return-Path: <AdamISZ@protonmail.com>
Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138])
by lists.linuxfoundation.org (Postfix) with ESMTP id DAC3DC0032
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 4 Nov 2023 16:17:00 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp1.osuosl.org (Postfix) with ESMTP id A30AD8223C
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 4 Nov 2023 16:17:00 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org A30AD8223C
Authentication-Results: smtp1.osuosl.org;
dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com
header.a=rsa-sha256 header.s=protonmail3 header.b=CJlLaJ8a
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.099
X-Spam-Level:
X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5
tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Received: from smtp1.osuosl.org ([127.0.0.1])
by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id nd6CwTDHka5W
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 4 Nov 2023 16:16:59 +0000 (UTC)
Received: from mail-0301.mail-europe.com (mail-0301.mail-europe.com
[188.165.51.139])
by smtp1.osuosl.org (Postfix) with ESMTPS id 42F388221A
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 4 Nov 2023 16:16:59 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 42F388221A
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
s=protonmail3; t=1699114612; x=1699373812;
bh=CDDBufXldDef4+KyjkMkiG7yaO2GV1fjWD32/H0u3R0=;
h=Date:To:From:Subject:Message-ID:Feedback-ID:From:To:Cc:Date:
Subject:Reply-To:Feedback-ID:Message-ID:BIMI-Selector;
b=CJlLaJ8a5asHmgYUzJlYxSL6Yrww/WPPVJ4M2VLD1s4yUydBc1moHl69gSZQTahtu
wb1dbdnMeDa+G4IHz611PYUxjR7TwsljKDZT1aokX8BnBRQlA2vpfmKUPfCOiKIdLK
pQc2BDHAzHYi8xI69+byrSOnwpf2Lma/FLAjv9CLU/WXM7deMIvbecXbh8R1ZhSCt9
eoqOIdQUovoUx6hQgqWpaUZpZ2naEiLfVpORqfc635iQHpRHAqjm77caALZOpmGXbW
nYW3f0FnSd1Eemf5xGw4DtKawfLig5ReZf6mCWUfcrfHeesbJJ1+liwSemDmqXnefu
7zjhUX5CjzTrQ==
Date: Sat, 04 Nov 2023 16:16:35 +0000
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
From: AdamISZ <AdamISZ@protonmail.com>
Message-ID: <BKDrklvNfkEmjjzz3M7CmLf74VFA2jYD-c0ozX27QfPAYMpLSAN2chSPfCRiotf8QhiPao6TWzYB-CX-3Xiqk4quAPcFfUsMLKG9gV5W8oQ=@protonmail.com>
Feedback-ID: 11565511:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Sat, 04 Nov 2023 17:22:46 +0000
Subject: [bitcoin-dev] Cold channels and PathCoin redux
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: Sat, 04 Nov 2023 16:17:01 -0000
Hi list,
I've recently spent a lot of time thinking about "PathCoin" ([1] - but I wo=
uldn't recommend reading that *first*, for reasons that will become clear).=
[3]
I realized that my earlier conceptions were way too specific and there is a=
wide range of possibilities for transferring coins in this way. One in par=
ticular, really stood out, what I'm calling here "Cold channels" - the TLDR=
if you don't want to read the post is, "payment channels where there is no=
hot wallet requirement and payments to offline (store-and-forward e.g.) wo=
rk, but the tradeoff is that you can only pay the whole channel capacity, i=
.e. fixed denomination". (note that that TLDR did *not* talk about routing,=
only a variant of a bidi payment channel).
I also would apologize in advance if, as very likely, much of what I'm sayi=
ng here is well known. But it's better explain in detail, just in case:
CTLCs
=3D=3D=3D=3D=3D=3D
First I want to focus on this primitive:
(A and CLTV) OR ( S_A and CTV)
Here A is a pubkey for signing (OP_CHECKSIG style, say), and S_A is just an=
image of a secret that A holds (as is well known, locking to *just* a prei=
mage is never safe, but here we don't do that).
Calling this from now on "CTLC" for "Covenant Time Locked Contract". As for=
BIP119 vs alternatives, I've been coding with that but I don't *think* any=
thing I say here is relying on that specific version of a covenant op code.=
It will continue to be "CTV" here.
CTLC chain
=3D=3D=3D=3D=3D=3D
By chaining those together for a set of participants (e.g. A,B,C,D,E) we ca=
n essentially control the flow of money a bit like airlocks - it moves forw=
ard specifically when transferring the secret preimages of S_A, S_B, ... :
(A and CLTV) OR ( S_A and CTV) -> (B and CLTV) OR ( S_B and CTV) -> (C and =
CLTV) OR ( S_C and CTV) -> (D and CLTV) OR ( S_D and CTV) -> E
Optimistic PathCoin
=3D=3D=3D=3D=3D=3D
This naturally gives us the first, and I think simplest, variant of PathCoi=
n: A can *spontaneously* choose a path A-B-C-D-E (assuming pubkeys are know=
n, and the secrets S_X can easily be done with tweaks, let's say), set up t=
he CTV chain, fund the coin and then effect payment to B by sending S_A, wh=
o can send to C with sending S_B etc etc. This variant is still nearly as l=
imited in value as what I originally suggested, with different tradeoffs. C=
oin denomination fixed, path fixed, *but* it doesn't require a penalty, and=
doesn't require an initial coordination/signing session. The negative, if =
"spontaneous", is pretty nasty: whoever finally spends the coin on chain ha=
s to broadcast the CTLC chain, so you don't save chain space and the privac=
y gain is not really so hot either.
Instructive to compare that with Rubin's congestion control concept: here, =
the spends are not all guaranteed. On the negative side, here, we cannot bu=
ild trees instead of single paths, because we have a double spend risk from=
privately shared secrets between colluders.
Re the negatives of "if spontaneous" - we will get into this next.
Cold channels
=3D=3D=3D=3D=3D=3D
The simplest kind of path (that requires least coordination) is just a 2-cy=
cle: A-B-A-B-A-B etc. This pattern exists, but is fairly uncommon, in a cus=
tomer-service provider scenario, and, for a typical case, the service provi=
der will be an online server so we don't need some kind of offline version =
of a payment channel there.
However what if it is more of a p2p relationship between two non-profession=
al entities? (As is often seen in the real world Lightning network). We lif=
t the above CTLC chain "offchain" in the usual manner:
Fund a 2 of 2 (AB) multisig, then presign the initial funding of the start =
of the CTLC chain. (Here is where "if spontaneous" is not true - A and B mu=
st coordinate to *setup*, and to *close*, but not to pay).
To close cooperatively, overwrite the CTLC chain to avoid broadcasting the =
whole chain uh .. on chain :)
This construction looks attractive because:
1. Payments do not require the receiver to be online, because state update =
is unilateral. They could be sent (literally just a 32 byte secret in the s=
implest case) e.g. in a store and forward mechanism, or handed over on a US=
B stick. The crappy home node that falls offline for 24 hours will not fail=
(at least, if we use long time locks for such "cold channels").
2. There is no hot signing-wallet requirement after setup (though, the two =
parties do need to defend their corresponding secret preimages of S_{[A,B]_=
n} from each other).
What about routing? I haven't thought about it, probably typical atomicity =
techniques do apply, but this structure is limited with its fixed denominat=
ion, so I'm not sure if there is or isn't something to pursue there.
Re: that fixed denom., perhaps using a lot of such channels at once is usef=
ul to at least ameliorate that.
Private pathcoin
=3D=3D=3D=3D=3D=3D
For completeness I see the original penalty-based setup as in [1] as being =
interesting specifically in that (a) ownership is not timelocked, (b) it so=
rta(?) has much better privacy because spends of the pathcoin itself are pu=
re p2tr keypath spends, and (c) there are interesting hybrids, as explained=
in the comment to the gist [2]. But I'll keep these ideas to one side, as =
I think the optimistic variant, especially offchain in a channel, are the m=
ost interesting.
Cheers,
AdamISZ/ waxwing
[1] https://gist.github.com/AdamISZ/b462838cbc8cc06aae0c15610502e4da
[2] https://gist.github.com/AdamISZ/b462838cbc8cc06aae0c15610502e4da?permal=
ink_comment_id=3D4748805#gistcomment-4748805
[3] I should also note I did code up a proof of concept of the original ver=
sion here: https://github.com/AdamISZ/pathcoin-poc
|
