Lightning Specification Meeting 2024/01/29

[t-bast]

The meeting will take place on Monday 2024/01/29 at 7pm UTC (5:30am Adelaide time) on Libera Chat IRC #lightning-dev. It is open to the public.

A video link is available for higher bandwidth communication: https://meet.jit.si/Lightning-Spec-Meeting

Recently Updated Proposals / Seeking Review

This section contains changes that have been opened or updated recently and need feedback from the meeting participants.

• Dual funding interactive-tx: Add dual-funding flow, using the interactive tx protocol (feature 28/29) #851
• Simplified mutual close option_simple_close (features 60/61) #1096
• Trampoline routing Trampoline Routing (2021 edition) (Feature 56/57) #829 and Trampoline onion format (Feature 56/57) #836 (2024 is going to be the year of trampoline 🎉)
• Channel jamming draft: Staking Credentials token issuance/redemption #1043 draft: HTLC Endorsement to Mitigate Channel Jamming #1071 blip-0004: experimental endorsement signaling in update_add_htlc blips#27
• Liquidity ads option_will_fund: liquidity ads #878
• Quiescence BOLT 2: quiescence protocol (feature 34/35) option_quiesce #869
• Offers Offers #798
• Taproot extension-bolt: simple taproot channels (feature 80/81) #995
• Taproot gossip extension-bolt: taproot gossip (features 32/33) #1059
• Attributable errors Attributable errors (feature 36/37) #1044
• Splicing Splice draft (feature 62/63) #863 vs Dynamic Commitments Extension/dynamic commitments #1117 vs Upgrade on reestablish BOLT 2: upgrade protocol on reestablish #868
• Peer storage backup Peer backup storage (feature 40/41/42/43) #881 or Peer storage for nodes to distribute small encrypted blobs. #1110
• Clarify channel_reestablish requirements Clarify channel_reestablish requirements #1049 or Rework channel_reestablish requirements #1051

Stale Proposals

This section contains pending changes that may not need feedback from the meeting participants, unless someone explicitly asks for it during the meeting. These changes are usually waiting for implementation work to happen to drive more feedback.

• Inbound fees Inbound routing fees blips#18 and Add a bLIP for backwards-compatible inbound fees blips#22

Waiting for interop

This section contains changes that have been conceptually ACKed and are waiting for at least two implementations to fully interoperate.
They most likely don't need to be covered during the meeting, unless someone asks for updates.

• Spec clean-up Clean up: remove two unused features, assume four more #1092
• Don't force close until error is received after channel_reestablish Nodes shouldn't publish their commitment when receiving outdated channel_reestablish #934

Long Term Updates

This section contains long-term changes that need review, but require a substantial implementation effort.

• Simplified commitment Feature 106/107: option_simplified_update. #867
• Hold htlcs before forwarding Add the ability to hold HTLCs before forwarding (FEAT 52/53) #989
• lnprototest (https://github.com/rustyrussell/lnprototest)

[carlaKC]

Bumping from last meeting: lightning/blips#27

[Roasbeef]

dual funding:

• forces you to provide the whole prev transaction for the input
  • issue in practice as means restricted to 65 KB
  • if trying to bring funds into a channel or mining pay out, etc
  • proposal: get rid of this
  • alternative: paper around the 65 KB limit w/ application level chunking or transport level chunking
  • why do we need this at all?
    • case where there's a mixed input in a unconfirmed transaction, it can modify the tx?
    • unclear how it can be exploited in the first place
    • all the inputs of unconfirmed transaction as input to funding tx need to be pure segwit

rbf-coop close:

• in bitcoind 25, OP_RETURN must now have a zero value output
• interaction with the older version?
  • single funder, all funds on the side of Bob,
• altruistic version:
  • you can't pay for fees, but you send closing_complete, then send no_closer_closee
• lnd close to do interop with eclair, CLN has next release, then working to make concrete

trampoline:

• chat last time about modifying the onion construct: prefix, or onion within the onion
• have implemented relaying to a blinded path
• arik fine with keeping as is, working thru impl

channel jamming

• do we have a feature bit?
  • can only start setting as the sender once more of the network has been updated
  • can use a high feature bit for now
  • yes: should make a PR to the BOLTs to specify a feature bit
• experiment:
  • learning circuit breaker along side, able to drop the rep down to zero based on w/e azlgo
  • collect the signals the be able to dry run the rep on mainnet

[t-bast]

why do we need this at all?

• case where there's a mixed input in a unconfirmed transaction, it can modify the tx?
• unclear how it can be exploited in the first place
• all the inputs of unconfirmed transaction as input to funding tx need to be pure segwit

I've figured out the details, and explained them here: https://delvingbitcoin.org/t/malleability-issues-when-creating-shared-transactions-with-segwit-v0/497

That means we cannot simply drop the prevtx field from tx_add_input messages that claim to use taproot, because that could be a lie. We can only allow the other participant to omit the prevtx field from their tx_add_input messages if we know we will include a taproot input on our side, which will commit to the scriptPubKeys our peer claims to use.

[ariard]

channel jamming

have the credentials in its own embedded rust lib, working poc: https://github.com/ariard/staking-credentials
works well for 1-to-1 coverage of liquidity usage (1sat of liquidity covered by 1sat of pre-paid token).