Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Lightning Specification Meeting 2024/08/26 #1191

Closed
14 of 20 tasks
t-bast opened this issue Aug 23, 2024 · 1 comment
Closed
14 of 20 tasks

Lightning Specification Meeting 2024/08/26 #1191

t-bast opened this issue Aug 23, 2024 · 1 comment

Comments

@t-bast
Copy link
Collaborator

t-bast commented Aug 23, 2024

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

Recently Updated Proposals / Seeking Review

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

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.

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.

Long Term Updates

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

@t-bast t-bast pinned this issue Aug 23, 2024
@Roasbeef
Copy link
Collaborator

Roasbeef commented Aug 26, 2024

channel jamming:

  • new attack variant discovered by morehouse
  • working on updating to account for it

taproot chans:

  • got some review from fabrice, roasbeef working on the changes
  • still not updated to use the mini script compatible scripts, will do that in the non-staging bit
  • rbf co-op:
    • lnd still needing to make change for locktime instead of sequence

taproot gossip:

  • close to revival...
    • near term goal to remove from draft state
    • lnd continuing to work on the new code path

bolt12 contacts:

  • delving post up, not much progress after the initial discussion

splicing:

  • CLN working thru set of changes to

async payments + trampoline:

  • rn trampoline node gets a blinded paths, and relays to blinded paths
    • the issue is that you aren't forced to use it in a privacy safe way
    • so then can use zero hop blinded paths w/ the node themselves
    • so receivers can make bad blinded paths, revealing more information to the sender's first hop
  • potential work around:
    • add another trampoline hop
    • essentially requires including the blinded path twice
      • may only be an issue if you do trampoline "all the way"
      • so instead can do trampoline blinded hops?

dyn commits:

  • pushed to slim down version, removing some of the funding output conversion
    • few segments that say note for reviewers, guide for reviewers, marking unstable parts
  • while we're here....default anchors?
    • eclair stopped accepting non static key anchors
    • two changes:
      1. channel type negotiation by default
      2. reject all non-anchor channels
    • most nodes do support anchors these days

TRUC + v3 + 1p1c:

  • what can we do w/ bitcoind 28 released?
  • how does it affect the commitment format, etc?
  • good topic for summit

peer storage back up:

  • target for lnd 0.19
  • interop:
    • does CLN have a full up to date impl?

inbound fees:

  • lnd deployed bLIP that was proposed
    • discount only for now, RPC will reject anything that's positive

peer alternate connect:

  • ability to privately connect out between peers
  • diff from chan_ann: sent directly to a peer, not broadcasted to the broader network
  • bridge to also allow diff pubkeys to be used for connection subsets:
    • brontide handshake mixes in the pubkey
    • so if you send another pubkey over an existing authenticated

nLightning:

  • finished BOLT 11!
    • had some issues re signature computation
    • defaults to using the low r (not s?)
    • for LN it doesn't care if it's low or high r
    • having a hard time signing w/ low r
    • signature didn't match
    • realized that even post segwit, we use high r on the signature
    • related to: Always create signatures with Low R values bitcoin/bitcoin#13666
      • signature was wrong when using this
    • should add more test vectors that do include low r

@t-bast t-bast unpinned this issue Sep 6, 2024
@t-bast t-bast closed this as completed Sep 6, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants