-
Notifications
You must be signed in to change notification settings - Fork 397
Switch default bits of hiding to 52 #834
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
Merged
Merged
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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 concept ACK
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.
It's just taking the arguments out of the giant line. Nothing else changed. I don't fully understand the strange min max thing there. I suppose it's to get the values between -1 and 18.
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.
ct_bits was also previously limited via this min/max construction. It was changed to just 52, I don't see why ct_exponent in this line could not be changed to just 0. The min/max limit for ct_bits was removed in #793 without any explanation, was it deemed useless ?
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.
I ask because I'll need to adjust my lib accordingly, but I hesitate to remove the limitations without fully understanding the consequences. Changing the number of bits result in the change in the size of the proof, and it looks like this only affects the tx size and therefore fee estimation. Setting ct_bits outside sane range would mean the blinding will just not work and fail with error, is this change (removing min/max limitation) added to help detect incorrect settings rather than work with limited settings ? If this is the logic behind this change, then ct_exponent should not be min/max restricted, too, and then
secp256k1_rangeproof_sign_implwill just return 0 if incorrectexpwas suppliedThere 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.
I don't know if your reference to #793 was a typo, but that PR was superseded with this one and it just sets the default number of bits from 38 to 52. We did this because the 38 bits covered only up to 10^-3 BTC or something. Because some assets are issuing assets using the BTC amounts instead of satoshi, we did this to increase the default blinding about up to 45*10^6 BTC.
It's true that it will about double the tx size. But given that we're also reducing the tx fee rate for Liquid to 0.1 sat/byte, that more than compensates for that increase in tx size.
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.
Ah you're probably right about the
min(max(construction of ct_exponent. Any wrong number will result in a failure on the secp side. It might be worth it to remove that construction, yes.Uh oh!
There was an error while loading. Please reload this page.
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.
reference to #793 was not a typo, the change of the value of ct_bits was not that my question was about. I asked why the
std::min(std::max(...is still applied toct_exponent, but not toct_bitsanymore. If there was certain logic behind removing this forct_bits, the same logic should apply toct_exponent. I don't see why this min/max thing is needed for either of these two parameters, but I might be missing something, and it would be good to know the reasoning why min/max was there in the first place. I have this code ported to python, and I will need to sync the code, but I would like the code to be consistent, and having different approaches toct_exponentandct_bitsdoes not seem consistent to me.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.
Removed that construction in followup PR. You were right that it was not needed in either position and it's actually a bit annoying.