Lightning Specification Meeting 2024/02/12

[t-bast]

Lightning Specification Meeting 2024/02/12

[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: 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