ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2023-01-04 🗒️ Summary of this message: The proposed ...
📅 Original date posted:2023-01-04
🗒️ Summary of this message: The proposed submarine swap/peerswap is not different from a normal on-chain to off-chain swap. The address generated by the `loop in --external` command may not be safe for reuse.
📝 Original message:
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
🗒️ Summary of this message: The proposed submarine swap/peerswap is not different from a normal on-chain to off-chain swap. The address generated by the `loop in --external` command may not be safe for reuse.
📝 Original message:
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