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
wallet: check auction TXs for dust and null address before sending #479
Conversation
also worth mentioning: the reason this hasn't come up in tests yet is because regtest allows nonstandard TXs: Line 841 in a3049d5
Lines 1437 to 1440 in a3049d5
Lines 1128 to 1151 in a3049d5
|
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.
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.
ACK
first time reviewing! no issues with the code -- also pulled down the branch and ran unit tests.
rebase to 0dcf5e1: address #479 (comment) |
@tynes added that |
if (!output.address) | ||
throw new Error('Cannot send to unknown address.'); | ||
|
||
if (output.address.isNull()) |
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.
What if somebody wants to provably burn some HNS? This would prevent somebody from using the API to do so. I don't see a consensus or policy rule that prevents such an output from existing.
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 think they can use a nulldata address then. This check I think is to catch user error when an address isn't specified in the output and the null value remains:
Lines 99 to 112 in 940f463
isNull() { | |
if (this.hash.length === 20) | |
return this.hash.equals(ZERO_HASH160); | |
if (this.hash.length === 32) | |
return this.hash.equals(consensus.ZERO_HASH); | |
for (let i = 0; i < this.hash.length; i++) { | |
if (this.hash[i] !== 0) | |
return false; | |
} | |
return true; | |
} |
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.
Ok, looking at the implementation of isNull
, it doesn't check the address.version so this would still let somebody provably burn since its not checking Address.isNulldata
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.
The same block of code is here:
Line 3288 in 89d3ab4
if (output.isDust()) |
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.
Right - if they used nulldata (which is just address version 31) they just couldn't ALSO use a ZERO_HASH
as the data part.
ACK 0dcf5e1 |
rebase to cf6d606: rebase on master, let's see the new github workflows run! |
Pull Request Test Coverage Report for Build 199648531
💛 - Coveralls |
Pull Request Test Coverage Report for Build 199648531
💛 - Coveralls |
Closes #463 maybe a few more...
These sanity checks are already applied to regular money-sending
NONE
-covenant transactions in thecreateTX()
methodHowever there is nothing yet to prevent a user from sending a BID with a lockup value that is below the dust threshold.
This is another issue with my least favorite line in the codebase, the "broadcast anyway" clause:
hsd/lib/node/fullnode.js
Lines 335 to 342 in a3049d5
As much as I want to change the "broadcast anyway" behavior we still need the extra sanity check in the wallet for SPV nodes, which can't check new TXs against mempool policy.