pull down to refresh

Another one from @supertestnet, this guy is unstoppable. From my understanding, it swaps both ways using any NWC server. As simple as to:
  1. download index.html
  2. setup nwc server from index.html?server=true
  3. make the swap at file://localhost/path/index.html
Did not try yet but I will. Anyone has tried it yet?
1021 sats \ 0 replies \ @conduition 14h
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).
reply
Eager to test. Is there any windows desktop LN wallet with NWC and testnet4 support?
reply
I need to try that. Sounds amazing @supertestnet
reply
Nit! Thanks @supertestnet
Papa Swaps are an "upgrade" over regular submarine swaps with the following benefits:
(1) Papa swaps only involve 1 transaction, whereas regular submarine swaps require 2 transactions (2) Papa swaps are twice as fast as submarine swaps due to needing half the number of transactions (3) Papa swaps slash the cost of submarine swaps in half due to needing half the number of transactions (4) Papa swaps slash the cost even further by using taproot, where scripts of this kind are more efficient than they are in segwit v0
reply
deleted by author