[bitcoin-dev] Cold channels and PathCoin redux

[bitcoin-dev] Cold channels and PathCoin redux

[AdamISZ]

Hi list,

I've recently spent a lot of time thinking about "PathCoin" ([1] - but I wouldn'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 particular, 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.) work, 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 saying here is well known. But it's better explain in detail, just in case:

CTLCs
======

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 preimage 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* anything I say here is relying on that specific version of a covenant op code. It will continue to be "CTV" here.

CTLC chain
======

By chaining those together for a set of participants (e.g. A,B,C,D,E) we can essentially control the flow of money a bit like airlocks - it moves forward 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
======

This naturally gives us the first, and I think simplest, variant of PathCoin: A can *spontaneously* choose a path A-B-C-D-E (assuming pubkeys are known, and the secrets S_X can easily be done with tweaks, let's say), set up the CTV chain, fund the coin and then effect payment to B by sending S_A, who can send to C with sending S_B etc etc. This variant is still nearly as limited in value as what I originally suggested, with different tradeoffs. Coin 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 has to broadcast the CTLC chain, so you don't save chain space and the privacy 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 build 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
======

The simplest kind of path (that requires least coordination) is just a 2-cycle: A-B-A-B-A-B etc. This pattern exists, but is fairly uncommon, in a customer-service provider scenario, and, for a typical case, the service provider 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-professional entities? (As is often seen in the real world Lightning network). We lift 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 must 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 simplest case) e.g. in a store and forward mechanism, or handed over on a USB 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 denomination, 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 useful to at least ameliorate that.

Private pathcoin
======

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 sorta(?) has much better privacy because spends of the pathcoin itself are pure 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 most interesting.

Cheers,
AdamISZ/ waxwing

[1] https://gist.github.com/AdamISZ/b462838cbc8cc06aae0c15610502e4da
[2] https://gist.github.com/AdamISZ/b462838cbc8cc06aae0c15610502e4da?permalink_comment_id=4748805#gistcomment-4748805
[3] I should also note I did code up a proof of concept of the original version here: https://github.com/AdamISZ/pathcoin-poc