š
Original date posted:2023-04-04
šļø Summary of this message: Swap-in-potentiam addresses provide implicit protection against 0-conf double-spend risk for all operations that move from onchain to Lightning, including channel opens and onchain-to-offchain swaps.
š Original message:
Hi ariard and t-bast,
I would like to point out that spends from swap-in-potentiam addresses are safely 0-conf if Bob is the other signatory in the swap-in-potentiam address.
On the other hand swap-in-potentiam is arguably cheating, since sending to a swap-in-potentiam address is actually a channel open of a Spilman-like channel with `OP_CSV` instead of `OP_CLTV`.
This implicit protection against 0-conf double-spend risk that swap-in-potentiam provides, exists for all operations that move from onchain to Lightning, including: channel opens, onchain-to-offchain swap, splice-in.
I should also note that the UTXOs with swap-in-potentiam addressed do need to be confirmed.
--
For cases where the one doing splice-in is an LSP and the other side is a client of that LSP, also consider this proposal: https://github.com/BitcoinAndLightningLayerSpecs/lsp/pull/24
While it is designed for 0-conf channel funding, the actual protocol is generic enough that it can be used where there is double-spend risk from an LSP, that the client wants to protect against.
This can applied to splice-in and channel factory construction, as the protocol is simply a promise "I the LSP will do my best to get the transaction with this TXID confirmed before some future blockheight, so you the client can rest assured that even if it is unconfirmed now (0-conf) you can always rely on it being confirmed later."
Regards,
ZmnSCPxj
ZmnSCPxj [ARCHIVE] /
npub1g5ā¦3ms3l
2023-06-09 13:13:01
in reply to nevent1qā¦0mgr
Author Public Key
npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3lPublished at
2023-06-09 13:13:01Event JSON
{
"id": "bf4702156df4d548a52cddb329ea84aec625708ce0f3053ba71d11747da6d47b",
"pubkey": "4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861",
"created_at": 1686316381,
"kind": 1,
"tags": [
[
"e",
"e4dd4b516f11823d5a3200101fb7503d8725eac868884fee4589e56659df2340",
"",
"root"
],
[
"e",
"fd72c9ed68a6ab82e56f49cbec2756207dfee7bfd9cf2420d85f92021895c1f3",
"",
"reply"
],
[
"p",
"6485bc56963b51c9043d0855cca9f78fcbd0ce135a195c3f969e18ca54a0d551"
]
],
"content": "š
Original date posted:2023-04-04\nšļø Summary of this message: Swap-in-potentiam addresses provide implicit protection against 0-conf double-spend risk for all operations that move from onchain to Lightning, including channel opens and onchain-to-offchain swaps.\nš Original message:\nHi ariard and t-bast,\n\nI would like to point out that spends from swap-in-potentiam addresses are safely 0-conf if Bob is the other signatory in the swap-in-potentiam address.\n\nOn the other hand swap-in-potentiam is arguably cheating, since sending to a swap-in-potentiam address is actually a channel open of a Spilman-like channel with `OP_CSV` instead of `OP_CLTV`.\n\nThis implicit protection against 0-conf double-spend risk that swap-in-potentiam provides, exists for all operations that move from onchain to Lightning, including: channel opens, onchain-to-offchain swap, splice-in.\n\nI should also note that the UTXOs with swap-in-potentiam addressed do need to be confirmed.\n\n--\n\nFor cases where the one doing splice-in is an LSP and the other side is a client of that LSP, also consider this proposal: https://github.com/BitcoinAndLightningLayerSpecs/lsp/pull/24\n\nWhile it is designed for 0-conf channel funding, the actual protocol is generic enough that it can be used where there is double-spend risk from an LSP, that the client wants to protect against.\nThis can applied to splice-in and channel factory construction, as the protocol is simply a promise \"I the LSP will do my best to get the transaction with this TXID confirmed before some future blockheight, so you the client can rest assured that even if it is unconfirmed now (0-conf) you can always rely on it being confirmed later.\"\n\nRegards,\nZmnSCPxj",
"sig": "6243bfc30f19e318319ead75bbe837d2d473be7be22ab9479189f5bdfbd1c86852d1042b2063e240789e90958926d375131753c2eca322fb16f6db015627d419"
}