Lightning Specification Meeting 2024/05/06

[t-bast]

Lightning Specification Meeting 2024/05/06

[Roasbeef]

channel update error issues:

• potentially can fingerprint senders by sending out unique channel_update values
• should we remove it all together?
  • would eliminate a finger printing vector
  • but, may add additional UX issues, as not able to get the latest update at runtime
  • can affect mobile nodes that aren't syncing gossip all the time, if they can't get the latest updates, payments may never happen
• can do in two phases:
  1. say it's optional for now
  2. remove the text about applying and broadcasting

BOLT 12 stuff:

• CLN doesn't do direct connect for invoice replies, just for sending
  • would say not connected, can't reply, working on adding that portion
• #798 (comment)

trampoline:

• question re interaction of blinded paths + trampoline
• async payments interaction:
  • looks like sender is setting the CLTV
  • async payments wants a very long CLTV
  • maybe looking at letting a trampoline node extend it themselves

stfu:

• seems that won't be adding termination?
  • for all updates, you have a state where you get to be half committed
  • can't abort, but only one side has exchanged secret data
  • can always end up here during disconnect, handled during channel reest
  • if we add go-on, then we can end up in a half committed state if you haven't d/c'd from peer?
    • do you put chan reest mid protocol?
    • or can try some state sync protocol
    • why go thru the extra effort?
    • instead centralize logic, and use disconnect/chan-reest otherwise

splicing:

• new splicing PR!!
  • old one was still in draft, latest here: #1160
• still have a dep on stfu

liquidity ads:

• working on a PoC of JIT channels
  • flexibility in how you pay, liquidity ads used to advertise fees
  • how would ppl reject?
    • phoenix: set a fee budget, automatic accept, otherwise fail
      * t-bast working on bLIP for JIT channel open
  • includes a will_send_htlc message, has the onion, proves there's actually an HTLC, etc, etc

gossip v1.5:

• motivation for old+new channels in v1.5?
  • block height for channel updates
    • can add to old chan update?
  • also need re-negotiation logic as well
  • effectively double gossip traffic until a future switch over date
• gives migration path away from old gossip for all chans

[ellemouton]

Re taproot gossip: posted some questions in the PR & pushed some updates.

#1059 (comment)

Main question is around the use of the new messages for both existing, legacy channels & new, legacy channels

[valentinewallace]

Re: trampoline, would like to discuss this spec feedback on trampoline <> blinded paths: #829 (comment)

[carlaKC]

bitcointranscripts/bitcointranscripts#481