Lightning Specification Meeting 2022/08/29

[t-bast]

The meeting will take place on Monday 2022/08/29 at 8pm 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

Pull Request Review

• Clarify bolt 4 blinding Bolt4: clarify packet forwarding blinding #1012
• Closing fee range turn-based protocol option_closing_rejected: turn-based fee_range coop close (feature 60/61) #1016
• Anchor outputs zero fee htlc txs test vectors Add test vectors for option_anchors_zero_fee_htlc_tx #1018
• Route blinding Route Blinding (Feature 24/25) #765
• Onion messages BOLT 7: Onion message support (features 38/39) #759
• Offers Offers #798
• Add dust exposure threshold Add a max_dust_htlc_exposure_msat #919
• Taproot extension-bolt: simple taproot channels (feature 80/81) #995

Waiting for interop

• Channel update flags Bolt7: add channel update flag for scid alias #999
• Grace period for channel closes gossip: delay considering a channel edge deleted for 12-blocks #1004
• Dual funding interactive-tx: Add dual-funding flow, using the interactive tx protocol (feature 28/29) #851
• 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
• Handle update_fee during shutdown BOLT 2: forget the check about update_* messages, and check what must not happens during shutdown #972
• Websocket transport websocket address type: allow transport over RFC6455 #891

Long Term Updates

• 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
• 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
• Upfront payments / DoS protection Hold fees #843 and https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-August/003673.html
• Peer storage backup Peer backup storage (feature 40/41/42/43) #881
• Anonymous gossip

Backlog

The following are topics that we should discuss at some point, so if we have time to discuss them great, otherwise they slip to the next meeting.

• lnprototest (https://github.com/rustyrussell/lnprototest)

[ariard]

If you can extend the "Upfront payments / DoS protection" entry with : https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-August/003673.html. Happy to collect more feedback on jamming research.

[vincenzopalazzo]

Maybe if there is time, we should discuss if this still have meaning or not anymore #972

[t-bast]

#972 is actually just a clarification PR, isn't it? I ack-ed it so I'm ok with it as-is, not sure about what others feel.

[vincenzopalazzo]

is actually just a clarification PR, isn't it? I ack-ed it so I'm ok with it as-is, not sure about what others feel.

Yeah it is after the rabase, the PR goal was the point to assert on the message that we must not receive, I do not know, maybe we should add a new entry?

Just point out this because in the next coming week I have some time and I can allocate it to make some PR to interop and merge this simple PR

[t-bast]

I don't understand what interop would be needed, this PR just clarifies in the ASCII diagram that after shutdown no new htlcs must be added, but that's already the behavior of all implementations, it doesn't require any implementation change so no interop tests are necessary?

[t-bast]

Also, there is already a requirement making it explicit:

- MUST NOT send an `update_add_htlc` after a `shutdown`.

So this PR doesn't bring much, except in the diagram, so we can either just merge it if others agree it's useful, or drop it, but no other work is needed?

[Roasbeef]

This old issue has received some new activity: #835

There's also a proposed bLIP (since some didn't agree that it was even a problem the way it was formulated?): lightning/blips#18

[vincenzopalazzo]

I don't understand what interop would be needed, this PR just clarifies in the ASCII diagram that after shutdown no new htlcs must be added, but that's already the behavior of all implementations, it doesn't require any implementation change so no interop tests are necessary?

I just asked because I did understand eater because the PR is in the Waiting for interop list, for me we can close it there is no value that is added!

[t-bast]

Right, the part that is waiting for interop is only in the title: "handle update_fee during shutdown", because we realized that implementations don't handle it that well...it's probably worth closing the PR and opening an issue to investigate implementation behavior around update_fee during shutdown?

[vincenzopalazzo]

.it's probably worth closing the PR and opening an issue to investigate implementation behavior around update_fee during shutdown?

Was discussed in some meetings that the update fee should be accepted during the resolution time of the htlc because this time can be long.

I think @TheBlueMatt pointed out this problem, and my original proposal was to ban only update_add_htlc and accept the others one.

This change can be done with an entry inside this PR that make more sense to me

[niftynei]

Super basic prototype of costs of anchors outputs/transactions (by weight) https://docs.google.com/spreadsheets/d/1mg2paz3iX97FiUwu1_CrmoJJnEZddIlfe2MHO9bjdiM/edit?usp=sharing

[ariard]

Super basic prototype of costs of anchors outputs/transactions (by weight) https://docs.google.com/spreadsheets/d/1mg2paz3iX97FiUwu1_CrmoJJnEZddIlfe2MHO9bjdiM/edit?usp=sharing

What are you aiming to demonstrate ? The most-optimal efficient strategy of broadcast/HTLC aggregation, you might have to care about different HTLC timelocks, not equivalent safety-wise.

[t-bast]

Was discussed in some meetings that the update fee should be accepted during the resolution time of the htlc because this time can be long.

Right, I agree, but I think we all realized that our implementation probably didn't handle this properly...but let's close #972 since it's now unrelated, and we can deal with that elsewhere (it's been years and we're still fine 😄)

[Roasbeef]

Channel jamming research stuff:

• Sort of SoK over the channel jamming research and solution space
• Initial take aways:
  • Easy first step to implement HTLC bucketing (allocate N% for HTLCs of value X)
• Future stuff:
  • Interaction between long CTLV value HTLCs and some of the channel jamming mitigations?
    • Prior ideas also related to the theta to scale the fees based on the CLTV values
• Interaction with bi-di fees and the force close state?
  • If jamming a huge channel for a long period of item, then the damage the other peer takes is "larger" than your commitment?

Inbound fees:

• Talked about in the past, people somewhat unclear on the problem statement
• Social concerns re inbound fees (?):
  • Making a discount on inbound fees isn't actually your "right"?
  • Given that you control the outbound and not the inbound?
  • Example that this isn't all about zero fees: Ability to set inbound and outbound fees #835 (comment)
    • Goal to make it easier to accept channels, don't have to worry as much about imbalancing?
• Joost has new version that's actually a discount:
  • Idea is that it can be backwards compatible (it's a discount, so you can pay more)
• Newer idea re a peer level thing:
  • Gossip changes, but you as a node give a discount to your peer
  • You give a discount to the peer, then they're also able to lower the outbound fee themselves
  • Does this actually give sender's the incentive?
    • Seems to now be a second-order effect
  • This might be easier to deploy since it's a p2p thing and a channel_update addition is a larger thing?
  • Does this actually help senders?
    • It can be kinda lossy since the discount may be gone very quickly assuming greedy optimizing senders?
  • Meta discussion:
    • How can people experiment with something like this in the wild?

Dual funding:

• Fully implemented in eclair now
• Question on if it needs anchors or not:
  • Feel like doesn't need a dependnacy, but liquidity as does?
  • We're two versions: the OG, and the zero fee variant. CLN doesn't support the zero fee variant
• Seems independent, dual funding on a different level
• Call now for people to look at the dual funding PR, also related to the splicing side of things

Taproot:

• Partial sigs are 32 bytes, we have a 64 byte field, options:
  • new field
  • use old field: pack in or zero bytes
  • commit_sig2
• anchor script:
  • which key do we use?
  • the internal keys are only revealed when you force close
  • maybe it's ok, since the internal keys are revealed once a sweep happens
• bip 86 for musig2?
• do we want local+remote nonce to always have the same type?

[niftynei]

Super basic prototype of costs of anchors outputs/transactions (by weight) https://docs.google.com/spreadsheets/d/1mg2paz3iX97FiUwu1_CrmoJJnEZddIlfe2MHO9bjdiM/edit?usp=sharing

What are you aiming to demonstrate ? The most-optimal efficient strategy of broadcast/HTLC aggregation, you might have to care about different HTLC timelocks, not equivalent safety-wise.

On-chain weight differences in anchors vs non-anchors. It's an accounting of total bytes-on-chain cost of various strategies, which I was personally curious about. I get that there's different tradeoffs in terms of security properties, thought it'd be interesting to see the total on-chain cost of those.