reply on: Papa swap: Submarine swaps that are faster, cheaper, and easier than HTLCs \ stacker news ~lightning

pull down to refresh

21 sats \ 0 replies \ @conduition 5h \ on: Papa swap: Submarine swaps that are faster, cheaper, and easier than HTLCs lightning

Neat, but it's nothing new IMO. To me this appears functionally the same as an HTLC with a really long delayed-activation timeout path, and with a 2-of-2 key-spend path where the server gives its half of the signing key to the user after the preimage is revealed.

I won't comment on the code, as it's clearly still in early development stages. But i will mention some gaps in the protocol which could become vulnerabilities if not filled in correctly.

the user optimistically hopes the preimage given by the server in step 8 of the protocol is also the private key to the public key which, when tweaked with the user’s pubkey, yields the key required for spending the money via the keypath

This must be done carefully using musig or some other key aggregation scheme. If they use naive point addition to perform this "tweak" as he calls it, the two parties could defraud each other using key-cancellation attacks.

User waits for the funding tx to confirm, verifies that the smart contract contains the exact amount needed for the swap (and that the funding utxo is the one they expected), and pays the lightning invoice

The protocol doesn't describe how it handles uncooperative LN edgecases. What if the server doesn't cooperatively disclose the preimage in a timely manner? If the in-flight LN HTLCs need to be settled on-chain, they can take weeks to resolve if the LN onion route is long enough - potentially long enough for the server to claw back the coins in the smart contract while also claiming the LN HTLC (the user gets shorted).

When paying the invoice, the user must set up proper CLTV limits which ensure the user will learn the preimage well before the server has a chance to sweep the on-chain coins back with the tx1 -> tx2 timeout path.

As soon as they pay the lightning invoice, they have everything they need to spend the money to whatever address they want, whenever they want. Nothing bad can happen.

I would be wary of this pitch. The user clearly has a liveness requirement similar to LN, or else the server can steal the money back. I'm not saying a liveness requirement is bad - but it's not the same custody profile as a two-stage HTLC, so it's silly to compare them the way he does in the readme. The user's funds are still at risk until she moves the coins out of the smart contract, and only then may she safely go offline (just like an HTLC).