ZmnSCPxj [ARCHIVE] on Nostr: 📅 Original date posted:2023-05-07 🗒️ Summary of this message: Dual-funded ...
📅 Original date posted:2023-05-07
🗒️ Summary of this message: Dual-funded 0-conf can be made safe if the initiator uses swap-in-potentiam addresses, allowing for immediate transfer to a 0-conf Lightning channel.
📝 Original message:
Good morning t-bast, and list,
Dual-funded 0-conf can be made safe in the following case:
* If the initiator uses swap-in-potentiam addresses (with initiator as Alice, acceptor as Bob).
If the initiator stalls, then the acceptor can retaliate by refusing to sign the swap-in-potentiam UTXOs forever after that, thus also locking their funds until the swap-in-potentiam times out, thus preventing this liquidity griefing from being cost-free.
The expected use-case is that a user expects onchain operations to be slow and take multiple confirmations to receive.
Once there is deep confirmation that a swap-in-potentiam address has been funded, then it can be transferred immediately to a 0-conf Lightning channel.
The initiator still needs to trust that the acceptor does not double-spend out from under the initiator, but see LSPS3 Promise To Unconditionally Fund 0-conf.
Also, it looks like you are allowing for the initiator to trust the acceptor in that case, as I believe you are taking the point of view of the acceptor of the dual-funding flow.
Regards,
ZmnSCPxj
🗒️ Summary of this message: Dual-funded 0-conf can be made safe if the initiator uses swap-in-potentiam addresses, allowing for immediate transfer to a 0-conf Lightning channel.
📝 Original message:
Good morning t-bast, and list,
Dual-funded 0-conf can be made safe in the following case:
* If the initiator uses swap-in-potentiam addresses (with initiator as Alice, acceptor as Bob).
If the initiator stalls, then the acceptor can retaliate by refusing to sign the swap-in-potentiam UTXOs forever after that, thus also locking their funds until the swap-in-potentiam times out, thus preventing this liquidity griefing from being cost-free.
The expected use-case is that a user expects onchain operations to be slow and take multiple confirmations to receive.
Once there is deep confirmation that a swap-in-potentiam address has been funded, then it can be transferred immediately to a 0-conf Lightning channel.
The initiator still needs to trust that the acceptor does not double-spend out from under the initiator, but see LSPS3 Promise To Unconditionally Fund 0-conf.
Also, it looks like you are allowing for the initiator to trust the acceptor in that case, as I believe you are taking the point of view of the acceptor of the dual-funding flow.
Regards,
ZmnSCPxj