Good morning Laolu,
> Hi Z, > > > * Submarine swap/peerswap: Requires confirmation before the swap service > > will send out the HTLC on Lightning. > > I might be missing something, but I don't see how this is different from a > normal on-chain to off-chain swap (calling this Loop In for short in the > remainder of the email). > > Given some static swap server params (server key, user key, preimage), a > user can derive a tapscript tree and use that to make addresses that any 3rd > party can send to. Services like Loop return a few addrs (including P2TR!) > the client can use depending on their wallet sophistication [1] (in this > case the command is: `loop in --amt=X --external\, external means a 3rd > party will send to the addr). After a 3rd party sends to the script, the > swap can be completed at anytime as soon as the client is online (assuming > swap server is always there). > > In the scenario above, the newly created outputs to our swap addr need to be > confirmed before the swap server will initiate the swap. As you mention, > this could even be zero conf assuming all sides take w/e precautions they're > comfortable with. If the swap server goes away for w/e reason, a long > timeout in the swap can let the user sweep the funds via some other > means eventually. This doesn't need to be a direct swap either, and it can > flow multi-hop like any other swap. > > In your scheme you say that: > > > If so, then the "timer for confirmation" starts as soon as the wallet > > receives on the blockchain, not as soon as the wallet decides to move > > funds from blockchain to Lightning. > > Which seems to be the exact same as the flow I described above. For our > newer musig2-enabled swaps, the top level keyspend can be spent by both > parties, so you also emulate the ability for Alice to move the funds on > chain anywhere else w/ the server's cooperation. > > Using regular swaps also simplified the "Bob Security" section a lot, as Bob > sends out an HTLC w/ the corresponding swap hash (he watches the chain for > the scripts, then initiates the swap once they're seen). > > [1]: https://lightning.engineering/api-docs/api/loop/swap-client/loop-in Quick question: is the address given by the `loop in --external` command safe for reuse? In many common onchain-only wallets **available today**, you can do something like get a receive address and add it to your forum sig or on a static webpage or forum post or whatever, and then anyone can send to it, possibly multiple times with different amounts coming from different people. The fact that `loop in` requires a specific `--amt=X` flag suggests to me that the address generated is not safe for address reuse (in particular, once *one* swap has completed, I am almost sure that any future funds to the same address can be stolen by the swap server without handing it over to the purported owner of the funds). Swap-in-potentiam is safe for address reuse, because each UTXO for the same address backs a new, separate swap (if Alice wanted it). The advantage is that: * You get stable addresses that are safe for reuse (which is already possible today on non-Lightning wallets, so people already do this today). * Those stable addresses can still be spent from quickly on the Lightning Network as soon as they are reasonably confirmed. Regards, ZmnSCPxj _______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
