Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Added LSHIFT and RSHIFT opcode functionality and test
- Loading branch information
1 parent
86ad646
commit 74922dd
Showing
3 changed files
with
324 additions
and
6 deletions.
There are no files selected for viewing
This file contains 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 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
Oops, something went wrong.
74922dd
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'm expecting everyone will be be so distracted by the convoluted table implementations of 256 - (1 << b) and (1 << 8 - b) - 1 that they will never notice the lack of range checking on n with respect to x.size(), resulting in out of bounds accesses.
This also appears to lack sign extension, so I am expecting numbertype negative inputs to not be handled in a consistent way. Leaving values zero-byte padded after right shift seems odd at least not without seeing a document that describes a theory of how someone would use these opcodes. I stopped looking after the out-of-range a few lines in, so there might be other issues too.
This certainly isn't consistent with how the opcodes originally worked: Script originally used bignums and the utility of arithmetic opcodes on bignums was obvious: you could use them to implement things like RSA and the paillier cryptosystem. Arithmetic operations on size limited types could be useful too, but there would probably need to be a consistent interface-- not some operations randomly padding outputs and others not.
74922dd
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.
Greg, you are too generous with your expertise, especially when it benefits people who have declared you both incompetent and evil. But I bet there will be furious behind the scenes activity to take your advice and fix things in a way that tries to avoid attribution to your analysis.
74922dd
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.
Great stuff.
74922dd
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.
Greg, I couldn't possibly agree more with Jmcorgan, these people aren't deserving of your kindness but I guess that's what you the better person. Great stuff
74922dd
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.
Thank you for your comment. However, the algorithm used is not susceptible to an out of range positive value and is never called with a negative value.
74922dd
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.
Hello Greg, I do see the range checks on n are in the CScriptNum
script.h 342:
int getint() const {
if (m_value > std::numeric_limits::max())
return std::numeric_limits::max();
else if (m_value < std::numeric_limits::min())
return std::numeric_limits::min();
return m_value;
}
RShift() and LShift() are always called with n.getint() in the current codebase but for futureproofing it might make more sense to pass CScriptNum to those functions and to call getint() from within.
It's good to see you take an interest in this project. I for one am looking forward to your continued feedback.