Protocol enhancements

[ZmnSCPxj]

Here are a few protocol enhancements, assuming we solve the value correlation problem:

I use this as reference: https://github.com/AdamISZ/CoinSwapCS/blob/master/docs/coinswap_new.pdf

nLockTime-protected Backouts

Waiting for TX0 and TX1 to be confirmed takes a long time, so this is the point at which the protocol is most likely to fail.

In order to reduce the effects of a protocol abort, as soon as the transactions are on the mempool, it is possible to create new transactions, TX0-backoff and TX1-backoff.

TX0-backoff spends TX0, has an nLockTime equal to the OP_CLTV on TX2, and pays out to Alice. Simiarly, TX1-backoff spends TX1, has an nLockTime equal to the TX3 OP_CLTV, and pays out to Carol.

When backing out on the timelock paths of the HTLCs on TX2/TX3, instead of publishing TX2/TX3 and then the timelocked transactions, publish the TX0-backoff/TX1-backoff.

Since the protocol has to abort anyway when the timelock is reached, TX0-backoff and TX1-backoff are safe to create. They do not otherwise affect the protocol. Advantages:

1. A timelock abort is indistinguishable from a normal multisig spend, especially if it becomes common that nLockTime is set to the current block height by wallets when spending (e.g. Bitcoin Core behavior). This reduces the privacy leak of aborts.
2. A timelock abort is only one transaction on top of the TX0/TX1 pair, instead of TX2/TX3 and then the backoff path.

Private Key Turnover

The last part of the protocol, after Alice provides X, both Alice and Carol coordinate to sign TX4 and TX5.

Instead of doing so, Carol can give the private key carol_4 to Alice, and Alice can now generate both signatures for TX5. Then Alice gives the private key alice_0 to Carol, and Carol can now generate both signatures for TX4.

It is safe to do so since Alice still cannot spend TX0 by herself until the timelock, and Carol still cannot spend TX1 by herself until the timelock.

The advantage is that if Carol is contacted by a new client, she can cut-through the TX4 for this swap with the TX1 for the new client, as long as the timelock on TX0 is still far in the future. Similarly, if Alice intends to swap with a new server, she can cut-through the TX5 for this swap with the TX0 for the new swap.

Given long-enough timelocks, both Alice and Carol can leave the funds in TX0/TX1 until the timelock is near, so that normal spends can directly use the TX0/TX1 outputs (this is probably more practical for server Carol). TX4/5 are only necessary if no other use of the money is needed and the timelock approaches in time. This is very safe since Alice and Carol can remake TX5/TX4 with a higher or lower mining fee at whatever time it judges it absolutely needs to spend TX0/TX1.

Care must be taken when not immediately generating TX4/TX5, however; TX2/TX3 remain valid and should be monitored.

[chris-belcher]

Earlier on the mailing list I pointed out how private key turnover was mentioned in the Lightning whitepaper. However I just noticed its also mentioned in the original coinswap thread: https://bitcointalk.org/index.php?topic=321228.msg3444210#msg3444210

Yep. Privacy requires new keys, but in general any protocol with a blind refund must always use a new key.

Petertodd proposed above that the final releases should be accomplished by handing over the keys, which also is another reason why you want to use fresh keys.

It's a very cool and useful idea so not surprising that it's been realized several times.

[AdamISZ]

As well as noting that private key transfers exist in earlier proposals than LN, it's also worth mentioning that LN eventually went a different route and worth considering why and how they made that choice. It seems in real systems private key transfer almost never turns out to be a thing that people want to use in real protocols, even given that (of course) the keys concerned are ephemeral.

My guess is that there is some fundamental pattern/transformation from a protocol with key transfer to one that uses another public key crypto primitive that "kind of" always applies. Devil in details of course, but still.

[chris-belcher]

Good thinking.

I read around a little bit and asked on #lightning-dev. It seems the reason they went with hash locks instead of private keys is simply cost. It costs less CPU to verify a hash than a private key, and there's no benefit to LN from using keys.

However there are huge benefits for using private key handover in CoinSwap, namely less block space usage and better privacy (because it greatly reduces the fingerprint of sending a coin to an address and then soon after spending it)