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
Subject: [bitcoin-dev] Cold channels and PathCoin redux
Precedence: list

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