pull down to refresh

Hi everyone,

I’m reaching out to the community to discuss a technical discrepancy that, as far as I can tell, shouldn't be possible according to the Lightning Network specifications (BOLT #3). I want to understand if I’m missing something fundamental or if we’re looking at a serious state-tracking failure in exchange infrastructure.

The Context: On January 3rd, 2026, I generated a Lightning deposit invoice directly from KuCoin’s platform. I paid the invoice using my node (Electrum). The transaction timed out, resulting in a unilateral force-close.

The Paradox: KuCoin has officially confirmed (via support) that they have the record of the invoice I generated. However, they claim:

  1. "The channel creation was not successful."
  2. "The transaction is not in our records."
  3. "The Node ID does not appear in our peer logs."

The Hard Evidence (On-Chain): Despite their internal logs being empty, the Bitcoin blockchain shows a very different story:

  • Funding Transaction: 1d9a8aec6debc2623599bee987f1486abd77d879b476bb7a48da4c266bba79ef (Confirmed with 3,300+ confirmations).
  • Force-Close Transaction: 65a2e68e8fdce08cccd8f04abfc2cbae0b51925fe0331f31b84cebcbfda3e91d.
  • The Locked Output (Unspent): bc1q0xg5y4g2zvtt4weacflhmnjsa7lnqxf6w5l4tvtl7zkcqlwk2d4skhg3x5.

The Technical Dilemma: The Witness Script for the unspent 0.022 BTC output is 799142.... I have extracted the public keys, and one of them (02aa0971...) is a deterministic derivation that—mathematically speaking—can only belong to the entity that signed the original invoice (KuCoin).

My Question to the Experts: How is it possible for an exchange's system to generate a signed BOLT #11 invoice, have that invoice result in a successfully funded on-chain multisig 2-of-2 channel, and yet have the exchange’s node claim the channel "never existed"?

  • Is it possible for a node to sign a commitment transaction and then "forget" the channel state entirely while the funding Tx is still pending?
  • Could this be a failure in the automated "sweeper" because the node doesn't recognize the outpoint in its channel.db**?**
  • If KuCoin is correct and the channel "failed," then who holds the private key for the remote side of a 2-of-2 multisig that was initiated by their own signed invoice?

I’m less worried about the 2.2M sats and more concerned about the implications for Lightning robustness. If an exchange can lose track of a funded channel state while admitting the invoice is theirs, we have a serious custody/infrastructure gap.

I’d love to hear thoughts from node operators or BOLT contributors.

Resources:

Thanks for your insights.