Lightning Specification Meeting 2024/02/12

[t-bast]

The meeting will take place on Monday 2024/02/12 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

Special topics

• v3 transactions usage in lightning: https://delvingbitcoin.org/t/lightning-transactions-with-v3-and-ephemeral-anchors/418
• DNS-based payment information resolution Define a mechanism for looking up an offer from a user/domain pair #1136 Define blip-0032, DNSSEC proof querying over onion messages blips#32

Recently Updated Proposals / Seeking Review

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

• Relax channel reserve requirements bolt2: relax channel_reserve_satoshis requirements #1133
• 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
• Trampoline routing Trampoline Routing (2021 edition) (Feature 56/57) #829 and Trampoline onion format (Feature 56/57) #836 (2024 is going to be the year of trampoline 🎉)
• Channel jamming draft: Staking Credentials token issuance/redemption #1043 draft: HTLC Endorsement to Mitigate Channel Jamming #1071 blip-0004: experimental endorsement signaling in update_add_htlc blips#27
• Liquidity ads option_will_fund: liquidity ads #878
• Quiescence BOLT 2: quiescence protocol (feature 34/35) option_quiesce #869
• Offers Offers #798
• 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
• Splicing Splice draft (feature 62/63) #863 vs Dynamic Commitments Extension/dynamic commitments #1117 vs Upgrade on reestablish BOLT 2: upgrade protocol on reestablish #868
• Peer storage backup Peer backup storage (feature 40/41/42/43) #881 or Peer storage for nodes to distribute small encrypted blobs. #1110
• 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

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.

• Spec clean-up Clean up: remove two unused features, assume four more #1092
• 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.

• 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
• lnprototest (https://github.com/rustyrussell/lnprototest)

[Roasbeef]

v3 txns:

• really happening now, one of the first thing merged
• 1p1c?
  • questions re the zero conf setting, maybe v3 needs minor tweaks to make sure that you can't broadcast if you have two parents
  • could potentially break zero conf
  • only p2p? not sure what
• 1000 vbyte limit?
  • constrains how much the attacker can may you pay
  • smaller you put this, the more bounds you have on the attacker
  • in theory w/ 483 HTLCs each direction, that's really large, so 800k sats of miner fee
• is the design too constrained as is?
  • there's an upgrade path, with the current mempool stuff this is the initial path
  • post cluster mempool and other research, then we can start to look at relaxing the rules
• commitment tx changes:
  • zero fee commitment, one anchor
  • can put the dust HTLCs inside the ephemeral anchor output, can use that to pay fees (?)
  • eliminate update_fee
  • new tnx will still be non-std in the next code release, have more time to see how it interplays
• deployment pipeline:
  • v3 code in bitcoind release
  • update commitment format
  • dyn commit to upgrade the commitment format

new DNS-based addr/invoice resolution:

• how do add offers stuff?
  • add another round trip to be able to do the offer
  • can just include the user name in the domain and the invoice request
  • may not be able to have a distinct node for the offer vs responder?
• should also carve out a larger experimental range for the TLVs in the offer?
  • minimal offer is pubkey + description
• how easy is DNSSEC to add on the server-side in 2024?
  • should just be a check box for any base DNS service
  • cloudflare, etc -- they all have them
  • some shitty registrars will charge you
• all clients need to implement DNSSEC validation?
• matt has server+resolver impl: https://http-dns-prover.as97444.net/
  • can use DoH (DNS over HTTPs) as well
  • can connect out on TCP port 53, etc

zero reserve:

• feature bit route is more robust
  • nodes able to distinguish those that support vs not
• asymmetric version?
  • can also just relax what you accept at an initial version
• feature bit semantics: I accept and you accept it?
• move to migrate the bLIP to a BOLT, something ppl seem to be asking for a lot

funding v2 + dual funding:

• turns out can't remove the req to send the entire transaction
  • needed to handle segwit edge cases

rbf coop close:

• lnd close to interop
• eclair has the branch open, will commit to it given another impl
• upgrade supported?
  • if negotiate for old version, will it accept and allow you to try to RBF the old one?
    • lnd looking to allow that, if possible

trampoline:

• PR rebased, new test vectors
• LDK working on a version

taproot gossip stuff:

• are ppl planning on doing this before channels?
  • CLN planning on starting on gossip before channels
• musig2 PR in secp: Add module "musig" that implements MuSig2 multi-signatures (BIP 327) bitcoin-core/secp256k1#1479

channel jamming:

• PoC thing up, starts setting stuff in the interceptor
• can start to relay the field sooner

liquidity ads:

• JIT channels for liquidity ads
• is it helpful to pin the HTLC in the first state?
  • may require more trust in either way, to actually relay the HTLC, etc
• thing t-bast worked on in the past related to this: https://gist.github.com/t-bast/69018875f4f95e660ec2cbbc80f711a6
  • does something to tie things into open+accept channel?

peer storage:

• lnd to start working on new version
  • has idea to also store HTLC state to improve the SCB recovery story
• trivia impl, can do w/e afterwards