-
Notifications
You must be signed in to change notification settings - Fork 491
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
Restrict bitcoin amounts #908
Conversation
It doesn't make sense to exchange amounts that exceed the total bitcoin supply, so let's make that an explicit requirement.
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.
Makes sense. Probably a good thing to do on most implementations to ensure overflows aren't possible.
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.
Good to me, I verified hex are correct :)
I know its pedantic, but when we limit we should use exact amount which would be:
|
I don't see why? The point is that it avoids various internal number overflow checks, reducing it by some tiny % isn't going to change that? |
now that you put it that way I agree :D |
Merging this PR as we had acks from rust-lightning and c-lightning during yesterday's spec meeting. |
It doesn't make sense to exchange amounts that exceed the total bitcoin supply, so let's make that an explicit requirement.
Eclair has always enforced this requirement at the wire layer, where messages that use invalid bitcoin amounts are automatically rejected.