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 2023/07/31 #1098

Closed
10 of 27 tasks
t-bast opened this issue Jul 27, 2023 · 5 comments
Closed
10 of 27 tasks

Lightning Specification Meeting 2023/07/31 #1098

t-bast opened this issue Jul 27, 2023 · 5 comments

Comments

@t-bast
Copy link
Collaborator

t-bast commented Jul 27, 2023

The meeting will take place on Monday 2023/07/31 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 Jul 27, 2023
@t-bast
Copy link
Collaborator Author

t-bast commented Jul 27, 2023

I won't be available for this spec meeting either (yay french holidays) but I'll review most PRs before that!

@jkczyz
Copy link
Contributor

jkczyz commented Jul 31, 2023

I drafted a small PR (#1099 based on #798) to allow using scids in an offer's blinded path, as discussed last meeting.

@Roasbeef
Copy link
Collaborator

simple close chans:

  • will people implement this before or after taproot channels?
  • how do we want to handle the feature gating here?
    • as is, it just assumes this is the "thing" and doesn't have any feature bit negotiation
    • in the form of two commits: adds it all, then removes the old
      • gives people an option w.r.t what they want
        • should it be the only way for taproot?
  • shutdown retransmission:
    • if you reconnect, then you can send shut down again
    • will always start with the shutdown sequence with the nonce
  • what to do if no one cares about their output?
    • allows either party to omit their own? or only if it's higher
    • what about the dust values?
  • game theory?
    • paying for own thing, so want you to pay vs not
    • normal case, opener is paying all the fees
    • what if you really don't want to pay?
      • propose fee that's below 1 sat/byte, or a zero fee close
      • then you sign off
      • but already the same with the current force close hijinks?
      • doesn't the existing dust field allow us to figure things out?
      • diff is you know exactly how much it'll cost to spend it
        • so then ends up being a way to late bind the dust values
  • op_return
    • allow both sides to just say they don't want the channel
    • in practice, just close on min fee and let propagate, this is the nuclear scenario where don't care about

optional + require bits:

  • undefined what to do if someone sets both
  • people seem to not care about it rn? maybe in the future we can pick an interpretation for it?

cleaning up features:

  • perhaps we just make a jump to required first? then revisit afterwards
  • then later on can set the new assumption behavior

attributable errors:

  • have clearer scope, looking to reduce the hmac size
  • needs spec updates, lnd impl to be updated, then waiting for interop w/ the rest

onion messaging:

  • has interop, working on more interop
  • LDK working on test vectors

offers:

  • needs test vectors

dust exposure:

  • rusty promises that he'll review it today

taproot:

  • FROST questions re nested musig vs not

@carlaKC
Copy link
Contributor

carlaKC commented Aug 3, 2023

Transcript: bitcointranscripts/bitcointranscripts#270

@t-bast
Copy link
Collaborator Author

t-bast commented Aug 8, 2023

simple close chans:

  • will people implement this before or after taproot channels?

On the eclair side, we will implement this soon, much before taproot channels, this way we can pave the road for deprecation of the older closing protocols.

@t-bast t-bast unpinned this issue Aug 10, 2023
@t-bast t-bast closed this as completed Aug 10, 2023
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

4 participants