-
-
Notifications
You must be signed in to change notification settings - Fork 11
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
[DO NOT MERGE] fix: change scriptHash generation for spending condition #278
Conversation
integration tests need fixing 👀 |
src/tx/applyTx/checkSpendCond.js
Outdated
@@ -227,7 +227,8 @@ module.exports = async (state, tx, bridgeState, nodeConfig = {}) => { | |||
// we only allow one spending condition in an transaction, do we want to throw if we find more? | |||
spendingInput = input; | |||
spendingInputUnspent = unspent; | |||
spendingAddrBuf = utils.ripemd160(spendingInput.script); | |||
const { script } = spendingInput; | |||
spendingAddrBuf = utils.ripemd160(script.length, utils.keccak256(script)); |
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.
How does ethereumjs-util
handle the int in ripemd
, does it pad it somehow to a fixed size integer?
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.
🤦♂ sorry, it is all broken .. ripemd doesn't even accepts multiple args as inputs. Will fix this mess tomorrow
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.
should be really something like ripemd160([keccak256(length), keccak256(script)])
Should we pad the ripemd hash itself as well? Though it will always be padded with 12 zero bytes
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.
Here is the current implementation: https://github.com/leapdao/leap-core/pull/114/files#diff-7e1ea5f3cb35910ce52c225628d785d7R4
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.
Should we pad the ripemd hash itself as well? Though it will always be padded with 12 zero bytes
No need to pad the ripemd hash.
Here is the current implementation: https://github.com/leapdao/leap-core/pull/114/files#diff-7e1ea5f3cb35910ce52c225628d785d7R4
We can just pad script.length
with zero-bytes on the left side to 32 bytes like
0x${script.length.toString(16).padStart(64, '0')}
That way we have a constant-size variable and everything is nice :)
Codecov Report
@@ Coverage Diff @@
## master #278 +/- ##
==========================================
- Coverage 94.57% 73.8% -20.77%
==========================================
Files 62 62
Lines 922 924 +2
Branches 173 170 -3
==========================================
- Hits 872 682 -190
- Misses 46 197 +151
- Partials 4 45 +41
Continue to review full report at Codecov.
|
a8d3ade
to
f216b65
Compare
f216b65
to
bb63bef
Compare
stale |
Resolves #242
Related:
leapdao/leap-sandbox#31
leapdao/leap-core#114