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 2022/11/07 #1038

Closed
10 of 30 tasks
t-bast opened this issue Nov 2, 2022 · 6 comments
Closed
10 of 30 tasks

Lightning Specification Meeting 2022/11/07 #1038

t-bast opened this issue Nov 2, 2022 · 6 comments

Comments

@t-bast
Copy link
Collaborator

t-bast commented Nov 2, 2022

The meeting will take place on Monday 2022/11/07 at 7pm 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

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 Nov 2, 2022
@Crypt-iQ
Copy link
Contributor

Crypt-iQ commented Nov 7, 2022

can we add #1039

@t-bast
Copy link
Collaborator Author

t-bast commented Nov 7, 2022

Done

@Roasbeef
Copy link
Collaborator

Roasbeef commented Nov 7, 2022

channel jamming research:

  • slow jam vs fast jam
    • slow: do it riight before things expire
    • fast: jam quickly, cancel back, keep doing it across the network
  • slow jam solution: reputation (tit-for-tat like)
    • don't think that fees can be efficient, since only a few jams are enough to jam a channel for a long time
    • goal to not have to de-anon senders
    • instead, use local peer reputation: keep track of your peers and their behavior
      • good peers can use all the slots, bad can't use everything
    • good: forwards a steady stream of honest payments, that bring fee revenue to the routing node
    • bad: peer forwards a payment, takes very long to resolve, could be honest or could take a while for w/e reason
      • peer then receives a smaller slice of the virtualized slots, gives them a chance to correct their behavior
      • routing nodes decide on the fly to allow payments or not based on the risk perf
    • impl: based on their preferences, they can set of coefficients which parametrize the algo
      • each peer sets their risk preferences and tradeoff
    • reputation is of a peer, but the quota is per channel (high risk neighbors, etc)
    • endorsement:
      • sender/forwarder can endorse a payment with some additional metadata
      • deviations:
        • endorse a high risk payment: have a tradeoff, if not a jam more likely to succeed, but risk that if it's a jam then you risk punishment
        • don't endorse a low risk payment: you think it's honest, but don't endorse, you decrease probability of success?
      • gives some information by endorsing
    • impl notes: seems straightforward, can be rolled out in a desynchronized manner
      • endorsement impl: can add some metadata to the update_add_htlc message
  • fast jam solution: prepayment
    • upfront fees is the way to go forward
    • upfront fees can be very very low (?)
      • almost never use all of the slots or all of the liquidity
      • idea is that over time the revenue you gain starts to resemble what you'd get for forwarding honest payment flows
    • fee scheme, mean to be as simple as possible, but would still help w/ the issue
      • simplest one seems to be better than nothing?
      • "unconditional fees", can be paid upfront or paid after the fact after the payment has been resolved
      • inherit the structure from the success (base and linear proportion)
    • makes many assumptions about the payment flows, assumes that 2% fee (of original success fee) seems to be sufficient
    • can't make it so expensive for the attackers that pays millions to be discouraged
    • instead, want to at least compensate nodes for that time value lost (the damage)
    • incentive compatibility issue:
      • node can take the fee and just not forward it
      • done some simple calcs that: fees should be set up in such a way that the expected value (failure prob, etc) must be higher than what would be gained by not forwarding it
    • possible way to ensure can't take the unconditional fee w/o forwarding
      • something re a series of payment hashes (N of them?), pre-image that needs is in the next layer of the onion (have to forward)
      • but final hop can't be paid or can't forward or w/e
      • attempts to solve issue of outgoing channel be jammed (so can't forward?)
  • paper goes over the other solutions in depth, and also presents an analysis framework for evaluating the solution
  • cross-over with fat errors
    • can use the fees to determine if someone forwarded the HTLC or not
  • simpler impl PoC
    • instead of paying upfront, but if the payment fails, then next node returns not the whole amount
  • UX aspect: only manifest if you're sending hundreds of payments
    • how to display to users though? ppl freak out about the reserve, but now their balance would go down over time....
    • idea: fee to paid is X, need max 5 payments, probability p%, then can display to them an additional set of bands/bounds for the fees
      * local friend of a friend stuff, potentially exempt from upfront fees? or you pay fees to yourself or w/e

mpp overpayment PR:

  • eclair already does this, will accept the overpayment, won't even look at it
  • backwards compat? seems to be done already, so payment don't need to signal stuff?
  • general agreement re implementing it, trivial change on the receiver side
  • concept ack stage, to progress on spec

ctlv over extend:

  • final nodes should also accept
  • why are intermediate nodes lax?
    • they might have an older channel update?
      * concept ack

dual funding:

  • lisa on vacation
  • made some comments re the indexing, ordering

tlv onion failures:

  • questions re signalling or not
  • have test vectors now as well
    • t-bast has implemented the test vectors
  • now using an odd identifier
  • short term to limit the size of it
  • sender doesn't support it, then would get garbled out
  • should only send after ppl have mostly updated
    • privacy leak re the sender signalling if they can understand it or not
      * short messages: need to detect it, but can be used
    • want to require than > 256 bytes
    • action items:
      • everyone to start to update their receivers to update the messages
      • send them at your own discretion until then

dust threshold:

  • ack from t-bast, need another reviewer on this

fat errors:
* why can't we just append in a naive way and randomize the length?
* simpler, but not as good in terms of privacy, how to randomize properly, etc?
* attempts to give alternative to adding a ton of hmacs to the onion error payload
* could compute the bandwidth over head, and see if the tradeoff or w/e is worth it

turn based co-op close:

  • if you get a warning, what do you set your range to?
  • better idea is to maybe just add a new message instead?
  • what was the original intent of the warning message?

taproot chans:

  • modified nonce ordering (push forward) discussed, seems to be good, laolu to merge in and update spec
  • lingering question re if should be prescriptive about counter vs randomized
    • can use the shachain state as the counter, allows to not write a secret nonce to disk
    • otherwise, can explain how to do it, and leave it up to the imp (not verifiable w/o zkp)

@vincenzopalazzo
Copy link
Contributor

we should push this sequence of points in the main list @Roasbeef ?

@Roasbeef
Copy link
Collaborator

Roasbeef commented Nov 9, 2022

@vincenzopalazzo you mean also send that comment about to the dev mailing list, or update the OP to have the notes?

@vincenzopalazzo
Copy link
Contributor

@Roasbeef I think just the message that you send it there? just to have the discussion in the same place

@t-bast t-bast unpinned this issue Nov 17, 2022
@t-bast t-bast closed this as completed Nov 17, 2022
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