Lightning Specification Meeting 2022/11/07

[t-bast]

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

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

• Relax MPP recipient requirements Allow nodes to overshoot the MPP total_msat when paying #1031
• Relax payment recipient requirements to fix probing Allow nodes to overshoot final htlc amount and expiry #1032
• Dual funding interactive-tx: Add dual-funding flow, using the interactive tx protocol (feature 28/29) #851
• Anchor outputs zero fee htlc txs test vectors Add test vectors for option_anchors_zero_fee_htlc_tx #1018
• Tlv stream in onion failures TLV failure message and length relaxation #1021
• Add dust exposure threshold Add a max_dust_htlc_exposure_msat #919
• Fat errors https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-October/003723.html
• Sign commitments at various feerates Add option to sign commitments at various feerates (FEAT 32/33) #1036
• Make closing Taproot-compatible BOLT#02: change SHOULD to MUST for fee-range mismatch #1039

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.

• Route blinding Route Blinding (Feature 24/25) #765
• Onion messages BOLT 7: Onion message support (features 38/39) #759
• Offers Offers #798
• Taproot extension-bolt: simple taproot channels (feature 80/81) #995
• Closing fee range turn-based protocol option_closing_rejected: turn-based fee_range coop close (feature 60/61) #1016
• Update static channel parameters zzz-extension-bolt: dynamic commitments #1026

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.

• Fix channel pruning behavior
• Don't force close until error is received after channel_reestablish Nodes shouldn't publish their commitment when receiving outdated channel_reestablish #934
• Graph dump on gossip_timestamp_filter Inconsistent behavior around graph dump on gossip_timestamp_filter. #980
• Websocket transport websocket address type: allow transport over RFC6455 #891

Long Term Updates

This section contains long-term changes that need review, but require a substantial implementation effort.

• Channel jamming: https://eprint.iacr.org/2022/1454.pdf
• Pinning attacks as related to splicing / dynamic commitments: https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-August/003665.html
• Liquidity ads option_will_fund: liquidity ads #878
• Quiescence BOLT 2: quiescence protocol (feature 34/35) option_quiesce #869
• 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
• Peer storage backup Peer backup storage (feature 40/41/42/43) #881
• Anonymous gossip
• lnprototest (https://github.com/rustyrussell/lnprototest)

[Crypt-iQ]

can we add #1039

[t-bast]

Done

[Roasbeef]

channel jamming research:

• slow jam vs fast jam
  • slow: do it riight before things expire
  • fast: jam quickly, cancel back, keep doing it across the network
• slow jam solution: reputation (tit-for-tat like)
  • don't think that fees can be efficient, since only a few jams are enough to jam a channel for a long time
  • goal to not have to de-anon senders
  • instead, use local peer reputation: keep track of your peers and their behavior
    • good peers can use all the slots, bad can't use everything
  • good: forwards a steady stream of honest payments, that bring fee revenue to the routing node
  • bad: peer forwards a payment, takes very long to resolve, could be honest or could take a while for w/e reason
    • peer then receives a smaller slice of the virtualized slots, gives them a chance to correct their behavior
    • routing nodes decide on the fly to allow payments or not based on the risk perf
  • impl: based on their preferences, they can set of coefficients which parametrize the algo
    • each peer sets their risk preferences and tradeoff
  • reputation is of a peer, but the quota is per channel (high risk neighbors, etc)
  • endorsement:
    • sender/forwarder can endorse a payment with some additional metadata
    • deviations:
      • endorse a high risk payment: have a tradeoff, if not a jam more likely to succeed, but risk that if it's a jam then you risk punishment
      • don't endorse a low risk payment: you think it's honest, but don't endorse, you decrease probability of success?
    • gives some information by endorsing
  • impl notes: seems straightforward, can be rolled out in a desynchronized manner
    • endorsement impl: can add some metadata to the update_add_htlc message
• fast jam solution: prepayment
  • upfront fees is the way to go forward
  • upfront fees can be very very low (?)
    • almost never use all of the slots or all of the liquidity
    • idea is that over time the revenue you gain starts to resemble what you'd get for forwarding honest payment flows
  • fee scheme, mean to be as simple as possible, but would still help w/ the issue
    • simplest one seems to be better than nothing?
    • "unconditional fees", can be paid upfront or paid after the fact after the payment has been resolved
    • inherit the structure from the success (base and linear proportion)
  • makes many assumptions about the payment flows, assumes that 2% fee (of original success fee) seems to be sufficient
  • can't make it so expensive for the attackers that pays millions to be discouraged
  • instead, want to at least compensate nodes for that time value lost (the damage)
  • incentive compatibility issue:
    • node can take the fee and just not forward it
    • done some simple calcs that: fees should be set up in such a way that the expected value (failure prob, etc) must be higher than what would be gained by not forwarding it
  • possible way to ensure can't take the unconditional fee w/o forwarding
    • something re a series of payment hashes (N of them?), pre-image that needs is in the next layer of the onion (have to forward)
    • but final hop can't be paid or can't forward or w/e
    • attempts to solve issue of outgoing channel be jammed (so can't forward?)
• paper goes over the other solutions in depth, and also presents an analysis framework for evaluating the solution
• cross-over with fat errors
  • can use the fees to determine if someone forwarded the HTLC or not
• simpler impl PoC
  • instead of paying upfront, but if the payment fails, then next node returns not the whole amount
• UX aspect: only manifest if you're sending hundreds of payments
  • how to display to users though? ppl freak out about the reserve, but now their balance would go down over time....
  • idea: fee to paid is X, need max 5 payments, probability p%, then can display to them an additional set of bands/bounds for the fees
    * local friend of a friend stuff, potentially exempt from upfront fees? or you pay fees to yourself or w/e

mpp overpayment PR:

• eclair already does this, will accept the overpayment, won't even look at it
• backwards compat? seems to be done already, so payment don't need to signal stuff?
• general agreement re implementing it, trivial change on the receiver side
• concept ack stage, to progress on spec

ctlv over extend:

• final nodes should also accept
• why are intermediate nodes lax?
  • they might have an older channel update?
    * concept ack

dual funding:

• lisa on vacation
• made some comments re the indexing, ordering

tlv onion failures:

• questions re signalling or not
• have test vectors now as well
  • t-bast has implemented the test vectors
• now using an odd identifier
• short term to limit the size of it
• sender doesn't support it, then would get garbled out
• should only send after ppl have mostly updated
  • privacy leak re the sender signalling if they can understand it or not
    * short messages: need to detect it, but can be used
  • want to require than > 256 bytes
  • action items:
    • everyone to start to update their receivers to update the messages
    • send them at your own discretion until then

dust threshold:

• ack from t-bast, need another reviewer on this

fat errors:
* why can't we just append in a naive way and randomize the length?
* simpler, but not as good in terms of privacy, how to randomize properly, etc?
* attempts to give alternative to adding a ton of hmacs to the onion error payload
* could compute the bandwidth over head, and see if the tradeoff or w/e is worth it

turn based co-op close:

• if you get a warning, what do you set your range to?
• better idea is to maybe just add a new message instead?
• what was the original intent of the warning message?

taproot chans:

• modified nonce ordering (push forward) discussed, seems to be good, laolu to merge in and update spec
• lingering question re if should be prescriptive about counter vs randomized
  • can use the shachain state as the counter, allows to not write a secret nonce to disk
  • otherwise, can explain how to do it, and leave it up to the imp (not verifiable w/o zkp)

[vincenzopalazzo]

we should push this sequence of points in the main list @Roasbeef ?

[Roasbeef]

@vincenzopalazzo you mean also send that comment about to the dev mailing list, or update the OP to have the notes?

[vincenzopalazzo]

@Roasbeef I think just the message that you send it there? just to have the discussion in the same place