Lightning Specification Meeting 2020/10/12

[t-bast]

The meeting will take place on Monday 2020/10/12 at 7pm UTC on IRC #lightning-dev. It is open to the public.

Pull Request Review

• Clarify bolt 4 BOLT 4: link to BOLT 1 for tlv_payload format #801
• Anchor revoked to_local Require to claim revoked local output in its own penalty tx post-anchor #803

Issues Review

• Asynchronous HTLCs and channel_reestablish commit_sig, revoke_and_ack ordering in channel reestablish flow #794

Long Term Updates

• Evaluate historical min_relay_fee to improve update_fee in anchors (@rustyrussell and @TheBlueMatt)
• Blinded paths Route Blinding (Feature 24/25) #765 (@t-bast)
• Upfront payments / DoS protection
• Offers Offers #798
• lnprototest https://github.com/rustyrussell/lnprototest (@rustyrussell)
• Trampoline routing Trampoline Routing #654 (@t-bast)

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.

• Hornet (@cfromknecht)

---

Post-Meeting notes:

Action items

• address PR comments on BOLT 4: link to BOLT 1 for tlv_payload format #801 @bitonic-cjp
• address PR comments on Require to claim revoked local output in its own penalty tx post-anchor #803 @ariard
• every implementation to check its behavior on the channel de-sync scenario described in commit_sig, revoke_and_ack ordering in channel reestablish flow #794
• summarize upfront payments proposals, known attacks/abuses, threat model @t-bast
• share chaumian token proposal with ML @rustyrussell

The full logs can be found here

[t-bast]

Sorry for missing yesterday's meeting! I think the having a tracking issue can be helpful to prepare beforehand (at least it's useful for me), don't hesitate to add other topics to the list.

[ariard]

See #803. Also might be a good time to talk about Upfront payment, at least more fine-grained channel policy management (cf. ml discussions)

[t-bast]

Added and promoted upfront payments out of the backlog

[cdecker]

Can we add #798 to the long-term updates? It has gotten a number of updates lately.

[t-bast]

Can we add #798 to the long-term updates?

Of course, done (I think all admins have the right to edit the issue, don't hesitate to add things)

[cdecker]

I prefer to make these requests in public, even if I apply them myself (makes the tracking issues a bit more lively and eventually we will want to discuss priorities ahead of the meeting, e.g., moving things to Backlog if there's too much to reasonably discuss in the next meeting).

[cdecker]

I'd also be interested in discussing Lloyd Fournier's recent mail to the
lightning-dev mailing list about the safety of two-round MuSig. It seems to me
that a longer-term relationship between two peers with an initial setup phase,
solves many of the concerns that are present in ad-hoc sessions that MuSig-DN
is concerned with.

[t-bast]

Good idea, this is an interesting topic 👍