-
Notifications
You must be signed in to change notification settings - Fork 132
Invoice manager tolerance tweaks #1673
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
Conversation
how does this differ from #1639 ? |
Pull Request Test Coverage Report for Build 17449019071Warning: This coverage report may be inaccurate.This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.
Details
💛 - Coveralls |
above adds a single 1 unit per invoice on the tolerance This approach adds N msats, where N is the number of HTLCs paying to this invoice |
b8ece69
to
343b196
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM 🎉
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Have gone over this in detail, LGTM. 👍 👍
@ffranr: review reminder |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM ❄️
// allows for a total error that scales with the number of | ||
// shards. We go up to numHTLCS-1 because we want to add any | ||
// leftovers to the last shard. | ||
for range numHTLCs - 1 { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Heh, I always forget that we have this new range syntax to just do a simple loop N times.
We slightly bump the rapid test range for the asset rate, in order to allow for 1 asset unit to evaluate to much less than 1msat. This exposes some of the rounding errors causing errors in the rapid test (it fails if you run it on this commit).
We update the tolerance model in the rapid test to account for 1 unit plus 1 msat, both per HTLC.
469f2e1
to
4df245b
Compare
tacked on a commit with release notes |
Description
First commit exposes our current tolerance, leading to new rounding errors.
There was also an inaccuracy in the way we sharded the amount across the number of HTLCs. We had to also carry the remainder of
invoiceAmt / numHTLCs
, which is currently added to the last shard.Then we modify the tolerance model to instead be
(1unit + 1msat)*numHTLCs
Let's use this topology to put things in order
Dave creates an asset invoice, Alice pays to it (with
N
HTLCs)N units
of toleranceN msats
of toleranceThe current rapid test tolerance model follows the above model and seems to be happy (for
rapid.checks
up to 10M)