-
Notifications
You must be signed in to change notification settings - Fork 37.7k
mempool: delete exists(uint256) function #23325
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
Conversation
Why not do a 'newtype' wrapper and then multiple dispatch? struct Wtxid {
uint256 h;
explicit Wtxid(uint256 i): h(i);
}
struct Txid {
uint256 h;
explicit Txid(uint256 i): h(i);
}
class CTxMempool{
bool exists(Txid t);
bool exists(Wtxid t);
} (for a more thorough treatment of newtypes, see https://www.boost.org/doc/libs/1_46_1/boost/strong_typedef.hpp) |
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. ConflictsReviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first. |
Right, ideally we have different types for txid and wtxid. I also think we should make @MarcoFalke @JeremyRubin would you prefer I change this PR to add new types, or open a new one? Either way we'd delete this function. |
I am not sure if it is possible to make |
True, we'd need to change the |
Concept ACK. I think the confusion is worth addressing. |
Concept ACK. Mixing up txids and wtxids has been a source of several bugs. Anything that we can do to stop just passing I agree that ideally we'd have separate types for I initially thought that this change carried a tiny performance penalty, since |
Allowing callers to pass in a uint256 (which could be txid or wtxid) but then always assuming that it's a txid is a footgunny interface.
d767a93
to
4307849
Compare
Thanks for the reviews! I've added the explicit ctors. |
i think the newtype stuff is obviously better, but that can be handled as a separate PR if desired. Given the named CTor approach, it's also possible to change those into static functions returning the newtype wrappers with minimal diff. |
@@ -393,6 +393,8 @@ class GenTxid | |||
uint256 m_hash; | |||
public: | |||
GenTxid(bool is_wtxid, const uint256& hash) : m_is_wtxid(is_wtxid), m_hash(hash) {} |
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.
Would be nice to make this constructor private / protected at some point (not here though)
Code review ACK 4307849 |
Tested and code review ACK 4307849 The static ctors seem like a strictly superior way to construct the |
review ACK 4307849 👘 Show signature and timestampSignature:
|
We use the same type for txids and wtxids,
uint256
. In places where we want the ability to pass either one, we distinguish them usingGenTxid
.The (overloaded)
CTxMemPool::exists()
function is defined as follows:It always assumes that a uint256 is a txid, which is a footgunny interface.
Querying by wtxid returns a false negative if the transaction has a witness. 🐛
Another approach would be to try both:
But that's slower and wrongfully placing the burden on the callee; the caller always knows whether the hash is a txid or a wtxid.