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/05/06 #1161

Closed
12 of 25 tasks
t-bast opened this issue May 2, 2024 · 4 comments
Closed
12 of 25 tasks

Lightning Specification Meeting 2024/05/06 #1161

t-bast opened this issue May 2, 2024 · 4 comments

Comments

@t-bast
Copy link
Collaborator

t-bast commented May 2, 2024

The meeting will take place on Monday 2024/05/06 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 May 2, 2024
@ellemouton
Copy link
Contributor

Re taproot gossip: posted some questions in the PR & pushed some updates.

#1059 (comment)

Main question is around the use of the new messages for both existing, legacy channels & new, legacy channels

@valentinewallace
Copy link
Contributor

Re: trampoline, would like to discuss this spec feedback on trampoline <> blinded paths: #829 (comment)

@Roasbeef
Copy link
Collaborator

Roasbeef commented May 6, 2024

channel update error issues:

  • potentially can fingerprint senders by sending out unique channel_update values
  • should we remove it all together?
    • would eliminate a finger printing vector
    • but, may add additional UX issues, as not able to get the latest update at runtime
    • can affect mobile nodes that aren't syncing gossip all the time, if they can't get the latest updates, payments may never happen
  • can do in two phases:
    1. say it's optional for now
    2. remove the text about applying and broadcasting

BOLT 12 stuff:

  • CLN doesn't do direct connect for invoice replies, just for sending
    • would say not connected, can't reply, working on adding that portion
  • Offers #798 (comment)

trampoline:

  • question re interaction of blinded paths + trampoline
  • async payments interaction:
    • looks like sender is setting the CLTV
    • async payments wants a very long CLTV
    • maybe looking at letting a trampoline node extend it themselves

stfu:

  • seems that won't be adding termination?
    • for all updates, you have a state where you get to be half committed
    • can't abort, but only one side has exchanged secret data
    • can always end up here during disconnect, handled during channel reest
    • if we add go-on, then we can end up in a half committed state if you haven't d/c'd from peer?
      • do you put chan reest mid protocol?
      • or can try some state sync protocol
      • why go thru the extra effort?
      • instead centralize logic, and use disconnect/chan-reest otherwise

splicing:

liquidity ads:

  • working on a PoC of JIT channels
    • flexibility in how you pay, liquidity ads used to advertise fees
    • how would ppl reject?
      • phoenix: set a fee budget, automatic accept, otherwise fail
        * t-bast working on bLIP for JIT channel open
    • includes a will_send_htlc message, has the onion, proves there's actually an HTLC, etc, etc

gossip v1.5:

  • motivation for old+new channels in v1.5?
    • block height for channel updates
      • can add to old chan update?
    • also need re-negotiation logic as well
    • effectively double gossip traffic until a future switch over date
  • gives migration path away from old gossip for all chans

@t-bast t-bast unpinned this issue May 14, 2024
@t-bast t-bast closed this as completed May 14, 2024
@carlaKC
Copy link
Contributor

carlaKC commented May 21, 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

5 participants