š
Original date posted:2023-04-04
šļø Summary of this message: A proposal has been made to protect against double-spend risk from an LSP during splice-in and channel factory construction, but it may be risky for the LSP.
š Original message:
Good morning again ariard and t-bast,
>
> 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."
Actually, given that the LSP is held liable if the TXID never confirms, and the splice TXID has as input the previous funding txo, this is actually risky for the LSP.
Even if the client has given revocation keys for all states dependent on the previous funding txo, the client can still post, and have confirmed, a revoked state.
This prevents the LSP from ever getting the splice TXID confirmed.
The client loses all its funds in the channel, but in exchange the LSP is held liable for not getting the splice TXID confirmed and the LSP reputation is destroyed.
Regards,
ZmnSCPxj
ZmnSCPxj [ARCHIVE] /
npub1g5ā¦3ms3l
2023-06-09 15:13:01
in reply to nevent1qā¦dx8y
Author Public Key
npub1g5zswf6y48f7fy90jf3tlcuwdmjn8znhzaa4vkmtxaeskca8hpss23ms3lPublished at
2023-06-09 15:13:01Event JSON
{
"id": "002b26638f82d03b43495eb33c2716b0fe7714dc6de3bf0b2ea02850a24cb119",
"pubkey": "4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861",
"created_at": 1686316381,
"kind": 1,
"tags": [
[
"e",
"e4dd4b516f11823d5a3200101fb7503d8725eac868884fee4589e56659df2340",
"",
"root"
],
[
"e",
"bf4702156df4d548a52cddb329ea84aec625708ce0f3053ba71d11747da6d47b",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "š
Original date posted:2023-04-04\nšļø Summary of this message: A proposal has been made to protect against double-spend risk from an LSP during splice-in and channel factory construction, but it may be risky for the LSP.\nš Original message:\nGood morning again ariard and t-bast,\n\n\u003e \n\u003e 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\n\u003e \n\u003e 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.\n\u003e 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.\"\n\nActually, given that the LSP is held liable if the TXID never confirms, and the splice TXID has as input the previous funding txo, this is actually risky for the LSP.\n\nEven if the client has given revocation keys for all states dependent on the previous funding txo, the client can still post, and have confirmed, a revoked state.\nThis prevents the LSP from ever getting the splice TXID confirmed.\nThe client loses all its funds in the channel, but in exchange the LSP is held liable for not getting the splice TXID confirmed and the LSP reputation is destroyed.\n\nRegards,\nZmnSCPxj",
"sig": "1ee10c49cea569f76fc1214dd469866f3746e6f9b0bef2087ace62e1fb618c92992c44d949090fe176e82b74c6d886ff78b42e5ac68b5365cb3aeea18af9bb3e"
}