Published on: 2023-01-05T02:07:51+00:00
In a recent email exchange, Laolu and ZmnSCPxj discuss the safety of addresses generated by the `loop in --external` command. Laolu explains that these addresses are not safe for reuse due to the inclusion of a swap hash in the script. However, he suggests that the addresses can be made pseudo-reusable by adding a "cancel" leaf in the rooted tapscript. ZmnSCPxj notes that Swap-in-potentiam addresses are safe for reuse because each UTXO backs a new, separate swap. The conversation also touches on the differences between normal on-chain to off-chain swaps and submarine swaps/peerswaps. Both types of swaps require confirmation before sending out the HTLC on Lightning. The top-level key spend can be spent by both parties, allowing Alice to move funds on chain with the server's cooperation. Regular swaps simplify the process for Bob, as he sends out an HTLC with the corresponding swap hash.The advantages of using a covenant in establishing a channel are discussed. The proposed approach involves receiving funds on the in-potentiam address with 8000 block CSV. If the funding tx confirms promptly, the channel becomes an ordinary channel. If not, LSP fee bumps or closes the channel. Two possible scenarios are Funding -> Unilateral/Cooperative close and In-potentiam -> Wherever (payment made on-chain by the user).The article introduces the Swap-in-Potentiam protocol, which enables immediate transfer of already-confirmed onchain funds to Lightning while minimizing trust requirements. The protocol uses CLTV-style unidirectional time-limited channels and Spilman-style channels. Bob, the potential swap partner, can sign any arbitrary on-chain transaction or receive an on-chain HTLC from the UTXO. The protocol messages for the Onchain use-case include request_arbitrary_signature, response_arbitrary_signature, and reject_arbitrary_signature. For the Channel use-case, the messages are request_swap_in, reject_swap_in, accept_swap_in, swap_in_signed, and swap_in_resolved.The benefits of the Swap-in-Potentiam protocol include immediate transfer of funds and atomic swaps between different blockchains without the need for an intermediary. However, it requires a cooperating LSP, and if the LSP is down or refuses to cooperate, on-chain funds may be locked for some time.The Lightning Network team proposes combining a swap-in with a splice-in to address the issue of insufficient outbound liquidity in mobile wallets. This allows users to draw upon the liquidity when making LN payments without waiting for an on-chain transaction. The team also suggests embedding the actual swap-in-potentiam message ID in the BOLT1 message to reduce pollution of the limited BOLT1 message ID space.In another proposal, ZmnSCPxj details a contract with two participants, Alice and Bob, and two branches: an onchain/channel branch and a timelock branch. The proposal is compared to splice-outs, and concerns are raised about its advantages over splice-outs.Overall, the Swap-in-Potentiam protocol offers a promising solution to the challenge of moving funds from on-chain to Lightning Network while minimizing trust requirements. However, it has certain limitations and requires cooperation from LSPs.The swap-in-potentiam protocol is a potential solution for mobile wallets to commit funds and initiate swaps with their clients. The protocol involves message exchanges between Alice and Bob, including a `request_swap_in` message from Alice to Bob, which contains channel information and an optional change address. To ensure scalability and flexibility, the plan is to reserve only one odd BOLT1 message ID and embed the actual swap-in-potentiam message ID within it.To enhance the protocol, the combination of swap-in and splice-in should be considered. This would allow for adding funds to the channel via splice-in while immediately crediting the swap-in within the current capacity. Taproot with Schnorr signatures is suggested as the implementation method for swap-in-potentiam. Initially, an explicit 2-of-2 branch is recommended over MuSig for deployment, enabling Alice to send the signature in a single half-round without engaging in a 2-round MuSig2 signing ritual.Executing the swap-in-potentiam protocol using existing channels involves several steps. These include `open_channel` from Alice to Bob, `accept_channel` from Bob to Alice, `request_swap_in` from Alice to Bob with the "change address" being the funding address of the channel, and finally, `accept_swap_in` from Bob to Alice, providing the TXID of the funding transaction.While the swap-in-potentiam protocol offers potential benefits, it also has limitations. Further research and development are necessary to refine and improve the protocol for wider adoption and use cases.
Updated on: 2023-08-01T00:57:46.832712+00:00