LDK Splicing Meeting Notes 07/10/2023

notes.md

Notes

Interactive TX branches

• Instead of ChannelMode enum, we could have a map for each different types of state (5 different places)
  • we could do that, but there's a lot of copying/reassigning
• We should error with Result
• We should hide the match/if let in the InteractiveTxConstructor
• Type-parameterized version
  • encapsulates the enum and the matches such that the call-sites are cleaner
  • move data into the enum

Dynamic commitments

• Some overlap with splicing
• Lightning Labs are going to do splicing without interactive transaction part
• Be able to skip the Negotiating state into Complete
  • Basically, we don't allow adding a new input or output
• Still early, probably no need to over-index for this

Lightning Summit

• Discussed at LN summit that CLN probably won't support 0-conf V2 channels at all for now and eclair will only support it for channels only funded by initiator for now. So we can probably leave supporting it out to reduce time to release.

  • Blockstream may be worried about the double-spend case where you need to start tracking the UTXOs?
  • No one really knows the concern
  • Duncan to fill in with more context?

• There were some small breakout groups at LN summit that discussed using splicing to upgrade P2WSH channels to simple taproot channels at the same time as splice-in/out creating the new P2TR funding output when we splice.

  • Splicing is going to require to TLV stream that is dependent on the channel type you are upgrading to
  • New channel type may need new information to pass around. For taproot, these are nonces (but we may not have any?)
  • Not having nonce-exchange for taproot will simplify splicing to taproot channels easier

Misc

• New types for different kinds of channel IDs? Txid-based vs XORed revocation basepoint-based. Or is that just going to be a headache? Something like this was mentioned in the splicing channel by Matt.
  • channel_ids are changing, and a lot of code today assumes we can calculate a channel_id from an outpoint. Those needs to go away
  • for clarity, we probably want our ChannelId to be an enum with different variants of how we derive channel_id
  • just adding the enum now will force us to change all the parts of the code that current does it the only way
  • may make sense to just create a PR with enum (Temporary and OutpointDerived) as a refactor
  • could we have a different struct for V1 Channels and V2 Channels?
    • we want to continue to use the outpoint as the key for the channel monitor (and we want to use it when splicing in/out)
    • useful for pruning channel monitors we do not need anymore
    • currently we use outpoint and channel id interchangeably, but we eventually need to pipe them through
  • this probably needs more thought, and someone needs to attempt it and figure it out as we go
  • blocking splicing

Action Items

• Jurvis to iterate on type parameterized version by rename the current InteractiveTxConstructor to InteractiveTxStateMachine, wrap inside a new InteractiveTxConstructor struct with ChannelMode, which will abstract away all the mem::takes, return appropriate errors, and prevent users from calling something they are incapable of within an interactive transation state.
• Duncan to fill in more context into why CLN won't be implementing 0conf V2 channels
• Someone needs to pick up the work around the channel id refactor, which we anticipate to be quite messy, and we will likely churn through a few solutions as we go

For context around CLN not supporting 0conf dual-funded channels at the moment we reference the liquidity griefing issue we run into, mentioned in the mailing list subject, Liquidity griefing for 0-conf dual-funded txs.

For dual-channels, we use the interactive tx construction protocol which relies on potentially both peers interactively adding UTXOs to the funding transaction.
You'd think it might make sense to "reserve" the UTXOs we've added to a specific interactive tx so that we know not to use them elsewhere, but this means that if our peer goes offline, we have these UTXOs locked up for a while.

The post further explains the inefficacy of the most obvious solution:

This cannot easily be fixed by simply unlocking utxos after detecting
that the remote node is fishy, because the remote node would still have
succeeded at locking your liquidity for a (small) duration, and could
start other instances of that attack with different node_ids.

You can read the rest of the post but the current best solution is to never "reserve" or "lock" UTXOs used in interactive txs, which can lead to some concurrent funding sessions with other honest peers failing, but that shouldn't be all to common if things progress quickly.

The problem comes in with 0conf as there could be accidental double spending involved if we don't reserve any UTXOs. So for 0conf we need to reserve UTXOs but then also separate candidate UTXOs for 0conf from non-0conf UTXOs otherwise a race can cause an accidental double spend.

The solution is to "soft lock" or mark UTXOs used in non-0conf funding attempts and not let 0conf funding attempts use those UTXOs, but still let other concurrent non-0conf funding attempts use them.

Eclair currently just uses opportunistic 0conf and sends a channel_ready immediately if the following conditions are met:

• if we receive channel_ready immediately (which means that our peer
  trusts us to use 0-conf)
• and we're the only contributor to the funding transaction (our peer
  doesn't have any input that they could use to double-spend)
• and the transaction hasn't been RBF-ed yet

This is incompatible with the soft locking described above, though.

At LN summit, I spoke with the CLN team and they indicated that they weren't tackling 0conf until there was some better solution (from what I gathered).
We could go the same route as Eclair with the opportunistic funding.