Olaoluwa Osuntokun [ARCHIVE] on Nostr: 📅 Original date posted:2023-01-05 📝 Original message: Hi Z, > Quick question: ...
📅 Original date posted:2023-01-05
📝 Original message:
Hi Z,
> Quick question: is the address given by the `loop in --external` command
safe
> for reuse?
Thx for this question, I think this is the key difference I was looking for
(not the aspect about confirmations, since that's no different). Since that
address contains a swap hash in the script, it's not safe to reuse (just
like a
vanilla invoice on LN today: ppl will learn the pre-image).
The potentiam swap is effectively a sort of deferred two stage swap. The
Loop
In swap I described earlier it complete after two transactions: initial
swap tx
confirmation, and the swap by the user. This swap can only be complete after
three transactions: initial deferred "no-premium swaption" (Alice can swap,
or
just leave it for a while), swap transaction confirmation (Alice initiates
w/
the HTLC added), and final sweep.
So this swap is less efficient from an on-chain perspective (2 vs 3 txns),
but
it gives Alice more optionality. Both variants however enable the final step
(sweeping on chain) to be batched with other related or distinct swaps.
I think one can make the Loop In swap addr pseudo-reusable by adding a
"cancel"
leaf in the rooted tapscript. It would slow down the process though, as
you'd
need another level of relative timeout for Alice to get the funds back. Ofc,
all this is muuuch nicer w/ proper covenants ;).
> The fact that `loop in` requires a specific `--amt=X` flag suggests to me
> that the address generated is not safe for address reuse
The amt field can in theory be left out of the flow, with the swap server
just
assuming w/e was sent to the address is the sending amt.
> 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:
Indeed, if I were to re-write your initial post, I'd lead with this as (to
myself at least) it makes the contribution of this scheme much clearer.
-- Laolu
On Wed, Jan 4, 2023 at 7:11 AM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230104/75286083/attachment.html>;
📝 Original message:
Hi Z,
> Quick question: is the address given by the `loop in --external` command
safe
> for reuse?
Thx for this question, I think this is the key difference I was looking for
(not the aspect about confirmations, since that's no different). Since that
address contains a swap hash in the script, it's not safe to reuse (just
like a
vanilla invoice on LN today: ppl will learn the pre-image).
The potentiam swap is effectively a sort of deferred two stage swap. The
Loop
In swap I described earlier it complete after two transactions: initial
swap tx
confirmation, and the swap by the user. This swap can only be complete after
three transactions: initial deferred "no-premium swaption" (Alice can swap,
or
just leave it for a while), swap transaction confirmation (Alice initiates
w/
the HTLC added), and final sweep.
So this swap is less efficient from an on-chain perspective (2 vs 3 txns),
but
it gives Alice more optionality. Both variants however enable the final step
(sweeping on chain) to be batched with other related or distinct swaps.
I think one can make the Loop In swap addr pseudo-reusable by adding a
"cancel"
leaf in the rooted tapscript. It would slow down the process though, as
you'd
need another level of relative timeout for Alice to get the funds back. Ofc,
all this is muuuch nicer w/ proper covenants ;).
> The fact that `loop in` requires a specific `--amt=X` flag suggests to me
> that the address generated is not safe for address reuse
The amt field can in theory be left out of the flow, with the swap server
just
assuming w/e was sent to the address is the sending amt.
> 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:
Indeed, if I were to re-write your initial post, I'd lead with this as (to
myself at least) it makes the contribution of this scheme much clearer.
-- Laolu
On Wed, Jan 4, 2023 at 7:11 AM ZmnSCPxj <ZmnSCPxj at protonmail.com> wrote:
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230104/75286083/attachment.html>;