Lightning Specification Meeting 2022/10/24

[t-bast]

The meeting will take place on Monday 2022/10/24 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

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

• Relax forwarding amount instructions final_incorrect_htlc_amount failure too strict? #1025, Allow nodes to overshoot the MPP total_msat when paying #1031 and Allow nodes to overshoot final htlc amount and expiry #1032
• Dual funding interactive-tx: Add dual-funding flow, using the interactive tx protocol (feature 28/29) #851
• Anchor outputs zero fee htlc txs test vectors Add test vectors for option_anchors_zero_fee_htlc_tx #1018
• Tlv stream in onion failures TLV failure message and length relaxation #1021
• Add dust exposure threshold Add a max_dust_htlc_exposure_msat #919

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.

• Route blinding Route Blinding (Feature 24/25) #765
• Onion messages BOLT 7: Onion message support (features 38/39) #759
• Offers Offers #798
• Taproot extension-bolt: simple taproot channels (feature 80/81) #995
• Closing fee range turn-based protocol option_closing_rejected: turn-based fee_range coop close (feature 60/61) #1016
• Update static channel parameters zzz-extension-bolt: dynamic commitments #1026

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.

• Fix channel pruning behavior
• Don't force close until error is received after channel_reestablish Nodes shouldn't publish their commitment when receiving outdated channel_reestablish #934
• Graph dump on gossip_timestamp_filter Inconsistent behavior around graph dump on gossip_timestamp_filter. #980
• Websocket transport websocket address type: allow transport over RFC6455 #891

Long Term Updates

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

• Pinning attacks as related to splicing / dynamic commitments: https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-August/003665.html
• Liquidity ads option_will_fund: liquidity ads #878
• Quiescence BOLT 2: quiescence protocol (feature 34/35) option_quiesce #869
• Splicing Splice draft (feature 62/63) #863
• 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
• Trampoline routing Trampoline Routing (2021 edition) (Feature 56/57) #829 and Trampoline onion format (Feature 56/57) #836
• Upfront payments / DoS protection Hold fees #843 and https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-August/003673.html
• Peer storage backup Peer backup storage (feature 40/41/42/43) #881
• Anonymous gossip
• lnprototest (https://github.com/rustyrussell/lnprototest)

[t-bast]

We're entering DST mess, not 100% sure I got the meeting time right, I may update it at the last minute if it's wrong, watch closely.

[joostjager]

Fat errors: https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-October/003723.html

[ariard]

Updated #919 with the edit suggested.

[Roasbeef]

relaxing recipient requirements:

• equality vs inequality
• to keep intermediate nodes as they are (you get more fees), but last node being more lax
  • would then mean that responders would accept more
  • otherwise potentially a probing vector
• main PRs Allow nodes to overshoot final htlc amount and expiry #1032 which builds on Allow nodes to overshoot the MPP total_msat when paying #1031
  • receivers can just update at all, resolves the last mile probing from the PoV of the value
  • two layers: mpp level relaxing, and also onion level relaxing -- both in the PRs above
• discussion w.r.t if we need to add a feature bit or not: when can the sender start to send more than the amount
  • can cause failures otherwise trigger failures if one tries to use this feature w/o the sender having being upgraded
  • may be able to get by or not....
  • question of if we should get rid of min_hltc, but then people would still enforce the value

dual funding + interactive tx:

• interop between eclair and CLN now finished
• few open questions:
  • rn input ordering: provide input for each input, then order the input ordering according to that
  • question that we use that instead of BIP 69, since we're not using that, then LN txns will differ
  • not using BIP 69 gives ppl more flexibility, to do fancier sighash stuff in the future
• who sends signature first?
  • if one sends the sigs first, then one party can broadcast but the other party doesn't
  • if opener always sends the signatures, then you can't batch two funding transactions
  • proposal:
    • allows initiator to defer sending the signature w/ a TLV to allow tx batching
  • current: the side w/ the most sats inputs signs first
  • or: the person w/ the most inputs, since they need to spend the most to double spend
    * restrictions on inputs:
  • can specify to reject inputs that aren't confirmed
  • related to splicing, then makes a lot of unconfirmed generations of transactions as well

anchor output tx test vectors:

• on the TOOD list for CLN+lnd, LDK has it merged, PR up to eclair

tlv streams in failures:

• last question: wanting to add a feature bit to signal things
• implications for feature bits and forwarding:
  • implications for path finding and also intermediate nodes?
  • seems lnd will forward it, but the sender errors out
  • if you're the sender then:
    • the intermediate node erroring, doesn't know if the sender supports it or not
    • so you want a feature bit in the onion as well
  • potentially privacy leak:
    • sender (of the payments) identifies themselves in the onion (they know this new feature)
    • only exists until others don't do it, arguably a similar leak exists w/ feature bits as is, onion space hasn't been modified in a while
      • other stuff like forwarding passes or other stuff would also start to use this intermediate onion space
• related to revamped fat errors (lets the sender pinpoint who sent the error) wants larger errors as well

dust level spec advice:

• new version, t-bast has ack'd, ready for other review