Lightning Specification Meeting 2022/08/01

[Roasbeef]

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

Pull Request Review

• channel update pruning clarification: Clarify Bolt 7 latest channel update pruning #1014
• Channel update flags BOLT #7: Make channel_update always have htlc_maximum_msat. #996 or Bolt7: add channel update flag for scid alias #999
• Grace period for channel closes gossip: delay considering a channel edge deleted for 12-blocks #1004
• fee range clarification: bolt2: fee_range clarification #1013
• Route blinding Route Blinding (Feature 24/25) #765
• 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
• Dynamic DNS support in gossip messages BOLT 7: add gossip address descriptor type DNS hostname #911

Waiting for interop

• Handle update_fee during shutdown BOLT 2: forget the check about update_* messages, and check what must not happens during shutdown #972
• Graph dump on gossip_timestamp_filter Inconsistent behavior around graph dump on gossip_timestamp_filter. #980
• Dual funding interactive-tx: Add dual-funding flow, using the interactive tx protocol (feature 28/29) #851
• Websocket transport websocket address type: allow transport over RFC6455 #891
• 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

• Pinning attacks as related to: splicing, dual funding, dynamic commitments: Splice draft (feature 62/63) #863 (comment)
• Liquidity ads option_will_fund: liquidity ads #878
• 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
• Peer storage backup Peer backup storage (feature 40/41/42/43) #881
• Anonymous gossip

Backlog

The following are topics that we should discuss at some point, so if we have time to discuss them great, otherwise they slip to the next meeting.

• lnprototest (https://github.com/rustyrussell/lnprototest)

[Roasbeef]

Legacy onion format update:

• latest lnd release switches the "send to route" call to use the modern payload
• t-bast still seeing some legacy onion payloads, around 5%

HTLC max stuff:

• Trivial number not setting, it should be g2g

Actions:

• Clarify Bolt 7 latest channel update pruning #1014:
  • matches
• Bolt7: add channel update flag for scid alias #999:
  • needs interop
• gossip: delay considering a channel edge deleted for 12-blocks #1004:
  • potential interactions w/ splicing and pinning, but seem somewhat unrelated
  • no major contests
• bolt2: fee_range clarification #1013:
  • related to some idea re a turn based protocol for the simple taproot channels
  • agreement that a new warning message (w/ an error code) would make things less ambiguous
  • lnd working on fully implementing it
• Route Blinding (Feature 24/25) #765
  • routing blinding! lnd has a PR now for the crypto bits
  • new ideas re error messages:
    • if you get an unexpected error, then you need to reject it w/ "bad onion" (invoice expires, already paid, etc)
      • the node that straddles the path (part blinded, part plaintext) will always send the bad onion
    • alternative: all failures look the same
    • if you get mpp timeout, then can use that to re-split the payment?
  • implementations now moving on to implementing the sending+receiving side of things
  • t-bast wanting to regenerate the test vectors, waiting for a real concept ACK on the TLVs (last commit of the PR)
• BOLT 7: Onion message support (features 38/39) #759
  • rusty might be rolling it back to 33 byte pubkeys, easy to make backwards compatible
  • nothing much has changed
  • fork of lnd exists that has it working (?)
  • should it be 100% route blinded?
• Add a max_dust_htlc_exposure_msat #919
  • new version seems to be cleaned up, ready for another round for review?
  • fwiw, most implementations have already implemented some form of this, but now we want to codify it in the spec
• extension-bolt: simple taproot channels (feature 80/81) #995
  • laolu shooting to get end demo out as a PR this week, few other things to respond to
  • possile thread to spin out here re turn based protoocl for co-op close
  • in gossip 1.5 should we go for just block based timestamps instead?
• Inconsistent behavior around graph dump on gossip_timestamp_filter. #980
  • trinary mode: send all, send none, send 2 weeks

Interop updates:

• DNS and websockets extensions looking g2g, clear to merge
  • lnd 0.15 will now properly allow them to propagate (ignoring unknown node addr types)

[t-bast]

Thanks for the summary laolu! Here are more details on the route blinding discussion about error messages.

The current state of the PR says that whenever an error occurs inside the blinded path, nodes must return a malformed onion (with update_fail_malformed_htlc) to ensure no data from within the blinded path can leak and reveal private information (probing protection). Nodes inside the blinded path should also transform normal errors into malformed errors: this way even if one node is misbehaving and sending a normal error, this can be corrected by other nodes inside the blinded path.

This strategy is quite extreme. We may want to allow some information to be propagated back to the sender for some failure cases. The proposal from @rustyrussell is that the final node can be allowed to send normal errors (update_fail_htlc) for a few cases, such as MPP timeout. Intermediate nodes should still only use update_fail_malformed_htlc for their own errors, but shouldn't transform normal errors into malformed errors anymore.

The risk with that proposal is that a misbehaving node who is next-to-last can now send a normal error (instead of a malformed one) and other nodes in the blinded will not correct it by transforming it into a malformed error, potentially giving the sender private information that would let them probe the identity of the recipient. However, if such a next-to-last node was malicious, they probably have other ways of exposing the recipient, and can simply deny them the payment, so maybe we shouldn't care about such scenario?

I don't have a definite answer yet, @thomash-acinq and I will spend more time on the implementation and will report back.