Lightning Specification Meeting 2023/11/06

[t-bast]

The meeting will take place on Monday 2023/11/06 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
• Peer storage Peer storage for nodes to distribute small encrypted blobs. #1110
• Spec clean-up Clean up: remove two unused features, assume four more #1092
• Offers Offers #798
• Quiescence BOLT 2: quiescence protocol (feature 34/35) option_quiesce #869
• Splicing Splice draft (feature 62/63) #863 vs Dynamic Commitments zzz-extension-bolt: a proposal for dynamic commitment upgrades #1090 vs Upgrade on reestablish BOLT 2: upgrade protocol on reestablish #868
• 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
• 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
• Liquidity ads option_will_fund: liquidity ads #878

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.

• 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.

• Channel jamming draft: Staking Credentials token issuance/redemption #1043 draft: HTLC Endorsement to Mitigate Channel Jamming #1071
• Simplified commitment Feature 106/107: option_simplified_update. #867
• Peer storage backup Peer backup storage (feature 40/41/42/43) #881 or Peer storage for nodes to distribute small encrypted blobs. #1110
• 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
• lnprototest (https://github.com/rustyrussell/lnprototest)

[Roasbeef]

dual funding:

• interop between CLN and Eclair, was missing reest, but works now
• experimental flag for release with CLN
• last call for dual funding before merged

simplified close:

• new cut out to signal RBF and sequence
• in the "needs interop phase"
• lnd plans to make this the default for taproot channels with the final feature bit

peer storage:

• should it be a bLIP or a BOLT?
• asymmetric feature bits?
  • someone can say I offer it, then the other person says I need it
• could work well for public channels, if only have private channels then harder
• potential for other extra-protocol sats backup system, sats-for-storage

required feature bits:

• CLN doing it in next upcoming release
• eclair in master, will be node in next few days
• lnd planning to land in master in few weeks

offers:
* waiting for ppl to do the scid vs pubkey thing
* required for the sender, optional for the recipient (they choose to set it or not)
* mutiny wallets has implemented in restricted manner, via direct connection
* lessons learned:
* could route to private channels w/ algo, but needed to hack around it somewhat
* do people have e2e tests with routed offers, how do they handle retry+fallback?
* so far LDK no retries, but will try to send on all paths
* will fail after 3 mins, shooting to get down to 1 minute as well
* so will issue more than one, sender should only pay one of them
* basic refund flow implemented as well
* Phoenix to start prototyping in the wallet side to get a feel for how it'll faire on mobile

splicing:

• dual funding cross compat with eclair + CLN, now can start to do interop

• which PR should be rebased on top of what?

  • splicing on top of quiescne?
    • lnd starting to implement quiescne, path to splicing and also dyn commits

• gossip carve out

  • not enough?
  • 6 block overlap where haven't announced yet, 12 block delay, but rejects the update?
    • sending out updates for the old channel, so peers would reject
    • CLN ended up restricting behavior w.r.t how they send updates
  • still have the on-chain idea: can make the splicing transaction identifiable

• dyn commits:

  • new draft PR to replace the old dyn commits one
    • still needs some work, but ready to start to take a look at
  • overlay with quiescne, not HTLCs at all:
    • also want to have the coast be fully clear, no HTLCs at all, so seeking a superset of quiescne

taproot:

• lnd fixing some small bugs in 0.17.1, smooth so far
• LDK ready to start going back into introp land

attributable errors:

• eclair has support, can use it in the route (decode), but not send
  • lnd branch: htlcswitch: attributable errors lightningnetwork/lnd#7139
• two issues
  • what do we do if we can't forward it? need a new error in the spec?
    • @joostjager uses a diff thing, say the recv just zeros
  • signalling
    • how do signal that you want to use it?
    • put inside the payload a new bit, that says use attriutable errors
    • if the onion isn't useable, what do you do?
      • use attributable errors, or fall back?
      • instead put in update_add_htlc?

[niftynei]

we also discussed liquidity ads in the last few minutes.

liquidity ads:

• @niftynei is updating the existing spec PR (option_will_fund: liquidity ads #878); anticipated changes: use CLTV not CSV; rebase on top of current dual-funding spec interactive-tx: Add dual-funding flow, using the interactive tx protocol (feature 28/29) #851
• rationale for CLTV: the liquidity buyer is incentivized to mine the channel tx ASAP to receive their liquidity, so it's fine if the time to mine takes a while as it counts against their own guaranteed liquidity purchase
• @Roasbeef is going to send notes on the existing CLTV commitment tx changes they've made for an existing LND channel-type
• no preference on BLIP vs BOLT; @niftynei to continue with updating existing BOLT PR
• fraud proofs: existing liquidity ads spec contains them for agreed channel fees; @niftynei + @t-bast to confirm that the alias PR (?) works with this

[joostjager]

Regarding attr errors:

if the onion isn't useable, what do you do?

lightningnetwork/lnd#7139 (comment)

[carlaKC]

Transcript: bitcointranscripts/bitcointranscripts#311