The current logic is a bit confusing. First creating the UniValue return dict, then parsing it again to get the type as std::string.
Clean this up by using a strong type TxoutType. Also, remove whitespace.
The current logic is a bit confusing. First creating the UniValue return dict, then parsing it again to get the type as std::string.
Clean this up by using a strong type TxoutType. Also, remove whitespace.
Can be reviewed via --ignore-all-space
Also, remove std::string type.
ACK 33330702081f67cb05fd86e00b252f6355249513
The refactoring looks good, and I find it an improvement over the current master’s code. This PR removes the extra steps of:
Instead, this PR directly creates a TxoutType object corresponding to the script and compares the result with the enum values of the TxoutType class, which was subsequently done even in the master branch’s case.
The whitespace removal commit also looks good. I checked for any formatting issues, and I found none.
<!--e57a25ab6845829454e8d69fc972939a-->
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.
<!--174a7506f384e20aa4161008e828411d-->
Reviewers, 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.
Concept ACK on using the strong type TxoutType instead of strings. However, now the type-solving happens rather twice (once in ScriptPubKeyToUniv, a second time immediately after its call) rather than "earlier", isn't it? Not sure though if this is really a problem for the performance, probably the RPC call overhead is already an order of magnitude higher than the solving itself, so that it doesn't really matter if it's done twice.
Yes, I'd say it shouldn't matter performance wise. After all, it already happens twice on current master.
Yes, I'd say it shouldn't matter performance wise. After all, it already happens twice on current master.
Oh, nevermind, for some reason I didn't see the second solver call in master 🤦♂️
Code-review ACK 33330702081f67cb05fd86e00b252f6355249513