Replies (29)
What makes Papa Swaps interesting, imo, is this: traditional submarine swaps require 2 L1 transactions before the user has full control of the money; Papa Swaps reduce this to 1 L1 transaction. That means blockspace is economized by 50%, fees fall by 50%, and they are 100x faster
@Super Testnet doing it again.
This dude rocks.
Wouldn't there be a race at the last step? Unless there's another secret the user implicitly has in a step im missing, then settling the invoice to reveal the sellers secret is going to be slower than the the seller can use it to broadcast the paramount back to themselves
If it's locked to their key then what's the failure recovery scenario for the seller?
so what exactly is the supposed advantage? not revealing the preimage on-chain if everyone plays nice?
you still gonna have to swipe to take unilateral unconditional self-custody.
Ok but please rename it papichulo swap
btw you could just make the server private key (hardened derivation) the secret for the LN invoice.
basically if you want to optimize your idea, you could make it a MuSig2 2/2 with a tapscript HTLC alternative (no additional spending required)
The sig from the user is only valid for a tx that puts the money in a regular submarine swap address, so that's the only thing the server can do with the money, whereupon the user has 2 weeks to sweep it back (I use relative timelocks). So the "sad path" is that the server tries to sweep the money, has to wait, and the user recovers it using the secret. Moreover, in my demo implemention, the user's sig also depends on the existence of another utxo which gets spent whenever the user sends or receives money -- so the next time the user does that, the old sig becomes invalid, and the server can't use it.
Yes, a musig would be more efficient. I have never used musig in a demo except a demo of musig itself, because I find it hard to implement and not worth it for a proof of concept. A real implementation should probably use musig for greater efficiency.
Not needing revealing the preimage is one theoretical advantage, but a bigger advantage is that the user gets full, unilateral control of the money after only 1 tx. They do not need to sweep it, as possession of the secret and a sighash_none sig from the server lets the user send the money wherever the user wants to.
The server, by contrast, is limited: he can only send the money into a traditional submarine swap address, which the user controls too, since the server has to wait 2 weeks to do anything, and the user does not, as the user knows the secret. So the user has full control of the money in the papa swap address in the same sense that a user fully controls their LN balance.
Also, in my implementation, the sig that lets the server move the money into a submarine swap address depends on the existence of a utxo that gets consumed when the user next sends or receives money. Once the user does that, the old sig becomes invalid, so the server cannot even move the money into a traditional submarine swap address.
The name Papa Swap comes from Papa Class, a group of Cold War submarines that included the world’s fastest declassified submarine – the Soviet K-222. As those are the fastest submarines, these are the fastest submarine swaps.
Sir, you are a freaking legend.
I take it back papa swap goes deep and fast
in this case you wouldn't even have co-op signing, so you can skip the fancy parts.
a simple aggregate public key would do. if you go multiplicative, a·b·G instead of (a+b)G then it's basically a DH key exchange. A·b = a·B, so Alice and Bob just reveal each other their pubkey for the session, and then both can generate the same address.
also note that there is no way to prove the relationship between b from B=b·G and H(b), but that is why you have the HTLC as a fallback.
on the happy path if Bob is playing honestly Alice can spend without revealing this was a swap. it just looks like a taproot keyspend. if not, then it is an HTLC plain and simple.
It sounds like you like it! Consider writing your own version with this improvement implemented. And help me convince
@Boltz - Non-Custodial Bitcoin Bridge to implement this, or maybe write a real version and compete with them
i think from a privacy pov it's definitely a good idea not to reveal on-chain that it's an HTLC and what was the hash lock/preimage on the happy path.
i'm not sure about how UX is improved otherwise.
started writing something up, will see if this helps me get back in the saddle. i should probably check out how submarine swaps work first before i go into more details, lol!
Gist
SHOT - Schnorr HTLC Obfuscation Technique
SHOT - Schnorr HTLC Obfuscation Technique. GitHub Gist: instantly share code, notes, and snippets.
The problem I see with this design is that the server has to do L1 transaction + commit to locking funds up for possible time period without assurance from user that they will pay lightning invoice. I may be misunderstanding.
These problems could be mitigated with a fee that has to be played before the L1 transaction but I would like to hear your ideas for mitigation
@Super Testnet
Thanks! Very interesting idea!
Excited to hear more about Papa Swap at
@btcplusplus in Istanbul!
View quoted note →is it interactive or non-interactive spend on the happy path?
based on this, interactive (proper MuSig2)
@Kilian
correct
it's not a huge win, but you can make it non-interactive by making the private key share for the internal key the secret for the LN invoice. probably makes more sense for LN to on-chain swaps.
in theory this makes the user able to unilaterally pay straight up from the HTLC and swipe the change.
decreases server load and might improve UX. idk.
Yup, this is a general unsolved problem with submarine swaps: the party with the timelock path can be grieved by abandoning the swap after the name the L1 deposit. They lose atwo mining fees and make no money.
I think a fidelity bond paid via LN can help here. If you compete the swap, you trust the server to give you the bond money back. If you abandon the swap, the server keeps the bond money to reimburse their two mining fees.
If you think about it, all submarine swaps are LN to on chain. Even when one party is going from on chain to LN, the other party is going from LN to on chain.
