Lightning Specification Meeting 2023/05/22

[t-bast]

The meeting will take place on Monday 2023/05/22 at 8pm 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.

• Bolt 8 chaining keys clarification BOLT 8: make it clear that there are *two* chaining keys. #1079
• Correct final CLTV for blinded paths: Correct final_cltv handling in blinded paths #1066 and Clarify final cltv expiry computation in route blinding #1069
• Onion messages BOLT 7: Onion message support (features 38/39) #759
• Offers Offers #798
• Add dust exposure threshold Add a max_dust_htlc_exposure_msat #919
• Taproot extension-bolt: simple taproot channels (feature 80/81) #995
• Taproot gossip extension-bolt: taproot gossip (features 32/33) #1059
• Quiescence BOLT 2: quiescence protocol (feature 34/35) option_quiesce #869
• Splicing Splice draft (feature 62/63) #863
• Relax HTLC receiver reserve requirement Allow HTLC receiver to dip into channel reserve #1083
• Fat errors Attributable errors (feature 36/37) #1044
• Clarify channel_reestablish requirements Clarify channel_reestablish requirements #1049 or Rework channel_reestablish requirements #1051
• Peer storage backup Peer backup storage (feature 40/41/42/43) #881

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
• 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
• Liquidity ads option_will_fund: liquidity ads #878
• Sign commitments at various feerates Add option to sign commitments at various feerates (FEAT 32/33) #1036

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.

• Dual funding interactive-tx: Add dual-funding flow, using the interactive tx protocol (feature 28/29) #851
• Don't force close until error is received after channel_reestablish Nodes shouldn't publish their commitment when receiving outdated channel_reestablish #934
• Websocket transport websocket address type: allow transport over RFC6455 #891 or Websocket address type: attempt 2 #1068

Long Term Updates

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

• Channel jamming draft: Staking Credentials token issuance/redemption #1043 draft: Upfront Fees to Mitigate Channel Jamming #1052 draft: HTLC Endorsement to Mitigate Channel Jamming #1071
• Pinning attacks as related to splicing / dynamic commitments: https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-August/003665.html
• 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
• Anonymous gossip
• lnprototest (https://github.com/rustyrussell/lnprototest)

[valentinewallace]

Would appreciate some discussion on lightning/blips#25 🙏

[Roasbeef]

offers + onion messaging:

• mainly tightening up test vectors
• questions around structured errors in onion message replies?
  • can also have error fields to also say what you didn't like, or other information
  • general now, have the fields there can make more strict in the future
• interop question re onion message offers path finding:
  • what do ppl do rn to test?
  • do you path find, or do a direct connect?
  • eclair wanted to re-use the path finding code (for onion messaging)
    • can't just use the old stuff verbatim, eg: disabled edges don't matter, etc

smarter go to chain w.r.t dust HTLCs:

• lnd prototyping: don't go to chain for dust HTLCs, just cancel back and keep the outgoing
  • eg: 100 sat HTLC, chain fees are 5k sats, just cancel back and keep the 100 sat HTLC
    • if they cancel back fine, if they settle fine, you just eat that 100 sat HTLC, better than 5k sats on chain
    • over time need to have a risk model, re the number of HTLCs you'll hold onto, before just closing
• other scenario: in certain situations, should you just cancel back earlier before you confirm outgoing?
  • say that maybe it'll confirm in a few blocks, so that's fine
  • cln+lnd will cancel back the dust HTLCs or the ones that are on a pending commitment asap
  • eclair will cancel back all the HTLCs as soon as they make the decision (doesn't wait for a conf on the outgoing link)
    • has always done it, but not if there's multiple inflight commitments (unrevoked commitment)
  • deadline awareness
    • eclair RBFs aggressively when things get close to timeout
    • lnd has the deadline ramp up code, should be in 0.17
    • cln w/ the latest release is now deadline aware, they cap it, then beyond that point they give up
  • potentially relevant PR: https://fc23.ifca.ai/preproceedings/94.pdf

taproot chans + gossip:

• LDK: fixed something brought up in the last meeting, getting ready to put up PRs to merge in for interop
• laolu still to make post around

splicing + quiescence:

• eclair finished, has been testing on mainnet to see how it works w/ the high fees, etc
• they hadn't implemented quiescence though, only had a happy path where did it only w/ HTLCs
• t-bast wanting to revive the PRs, and make sure it's up to date, as needed for normal splicing
• PR adds an stfu message, doesn't do anything by itself, needs something else to use it
• rusty has the base impl, also looking back into the simplified state machine, need to make sure it works with reconnect, etc

htlc channel reserve edge case:

• t-bast ran into it during splicing
• old thing: can get get stuck if you add an HTLC while all the funds are on the non-initiator side
  • can't also add the HTLC and also maintain the channel reserve
• ask for cut out: allow that to go below the reserve, if needed to add that HTLC
• splicing relation: responder swaps in some funds, so then the reserve value goes up, can also cause the channel to be stuck
• what do other impls do?
  • scenario: as the initiator, you recv an HTLC, it dips below the reserve, what do you do?
  • lnd: will error out

LSP wanting to take fee from first payment user wants

• so they skim off the to to pay for the service
• LDK has a config option, related TLV change
  • MPP issue: if recv 3 HTLCs, have chan to mobile wallet, then forward to the user
  • if there's another HTLC, no more balance so can't forward it
  • Phoenix has MPP awareness at the LSP layer, so then only send it all back at once
• phoenix does something diff:
  • if we recv an HTLC w/o that, send a new message w/ the onion in that
  • client can then aggregate, then send a message to plz open the channel
  • and they negotiate the channel at that point
  • new UI updates in Phoenix where user can control how much they're willing to pay

[carlaKC]

Transcript: bitcointranscripts/bitcointranscripts#258