You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The following situation occured while attempting a splice-in with CLN v24.11:
I initiated a splice as described in the documentation. The splice_init and splice_update commands returned successfully, however splice_signed aborted with an error indicating that the peer was unreachable. Indeed the peer has been offline ever since and no splice transaction has been published.
At the same time, my node apparently detected that the channel was in an error state and attempted to force-close it. However, the force-close doesn't work, because it tries to spend the UTXO of the splice transaction which hasn't been published. If my understanding is correct, the fully-signed splice transaction cannot be known to my node since the peer crashed before it could add their signature and send it. Therefore, the channel cannot be closed now without the peer coming back online and publishing the splice transaction, which hasn't happened and potentially won't.
I don't know what happened on the side of the peer. Obviously, their node also seems to be in trouble, so hopefully they will read this and collaborate to resolve the issue, if possible.
I don't know whether the splicing protocol can be changed to avoid this dangerous state, this might be a matter for research.
This is an excerpt from my log during the splicing operation:
XXXX-XX-XXXXX:X6:53.121Z UNUSUAL XXXXXX-channeld-chan#8: STFU complete: we are quiescent
XXXX-XX-XXXXX:X6:53.122Z UNUSUAL XXXXXX-channeld-chan#8: STFU complete: setting stfu_wait_single_msg = true
XXXX-XX-XXXXX:X7:36.662Z INFO XXXXXX-channeld-chan#8: Splice negotation, will not send commit, not recv commit, not send signature, recv signature as initiator
XXXX-XX-XXXXX:X7:36.663Z INFO XXXXXX-channeld-chan#8: Splice signing tx: 020000000XXXXXX
XXXX-XX-XXXXX:X9:22.305Z INFO XXXXXX-chan#8: Peer transient failure in CHANNELD_NORMAL: Disconnected
XXXX-XX-XXXXX:X9:22.319Z INFO XXXXXX-channeld-chan#8: Unable to resume splice as user sigs are missing.
XXXX-XX-XXXXX:X9:22.534Z INFO XXXXXX-channeld-chan#8: We are initiating tx_abort for reason: next_funding_txid not recognized. Sending tx_abort.
XXXX-XX-XXXXX:X9:26.464Z UNUSUAL XXXXXX-chan#8: Peer permanent failure in CHANNELD_NORMAL: channeld: received ERROR channel XXXXXX: tx_abort is not allowed after I have sent my signature. msg: XXXXXX (reason=protocol)
XXXX-XX-XXXXX:X9:26.464Z INFO XXXXXX-chan#8: State changed from CHANNELD_NORMAL to AWAITING_UNILATERAL
XXXX-XX-XXXXX:X9:29.323Z INFO XXXXXX-connectd: Received WIRE_WARNING: WARNING: channel_announcement: no unspent txout XXXXXX
XXXX-XX-XXXXX:X9:29.699Z INFO XXXXXX-connectd: Received WIRE_WARNING: WARNING: channel_announcement: no unspent txout XXXXXX
This is my node trying to force-close the channel, which fails (bad-txns-inputs-missingorspent) because the splicing transaction is unknown.
The following situation occured while attempting a splice-in with CLN v24.11:
I initiated a splice as described in the documentation. The splice_init and splice_update commands returned successfully, however splice_signed aborted with an error indicating that the peer was unreachable. Indeed the peer has been offline ever since and no splice transaction has been published.
At the same time, my node apparently detected that the channel was in an error state and attempted to force-close it. However, the force-close doesn't work, because it tries to spend the UTXO of the splice transaction which hasn't been published. If my understanding is correct, the fully-signed splice transaction cannot be known to my node since the peer crashed before it could add their signature and send it. Therefore, the channel cannot be closed now without the peer coming back online and publishing the splice transaction, which hasn't happened and potentially won't.
I don't know what happened on the side of the peer. Obviously, their node also seems to be in trouble, so hopefully they will read this and collaborate to resolve the issue, if possible.
I don't know whether the splicing protocol can be changed to avoid this dangerous state, this might be a matter for research.
This is an excerpt from my log during the splicing operation:
This is my node trying to force-close the channel, which fails (bad-txns-inputs-missingorspent) because the splicing transaction is unknown.
The text was updated successfully, but these errors were encountered: