-
Notifications
You must be signed in to change notification settings - Fork 38.7k
BIP-322 basic support #24058
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
BIP-322 basic support #24058
Conversation
c9ff394 to
abc51e1
Compare
|
Concept ACK This should fix #10542 |
|
@kallewoof do you know if any other wallet implemented BIP-322 yet, so we can compare the implementation? This is really a good time to add test vectors to the BIP (and this PR). |
src/script/interpreter.cpp
Outdated
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.
Although SIGHASH_DEFAULT implies SIGHASH_ALL, AFAIK using SIGHASH_ALL is still possible for users who wish to waste 1 byte. So I think you need m_require_sighash_all && nHashType != SIGHASH_ALL here too.
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.
Isn't that a malleability? Anyway, gotcha.
src/rpc/misc.cpp
Outdated
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.
This message implies the user can do something about it. Suggest instead: "BIP-322 Proof of Funds is not supported"
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.
Sounds good. The intention is to actually add this functionality, but I think it should be its own PR.
src/rpc/misc.cpp
Outdated
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.
Why not just throw in these other cases?
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.
Because these aren't errors? But yeah, that would be one way to return a message. I think I'd prefer to expand the returned value from simple bool to true|false|"inconclusive", but not sure that would be appreciated.
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.
Some RPCs return false as the result and an error message field. Others just throw with an error code and message. It's an error in the vague sense that the RPC failed to verify what it was asked to verify.
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, but what about "OK_TIMELOCKED"?
src/util/message.h
Outdated
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 unsure, but perhaps we should make a fresh enum BIP322VerificationResult?
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.
Oftentimes you won't know which type it is until you finish verifying, so unifying the two types seems sensible to me.
|
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. ReviewsSee the guideline for information on the review process.
If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update. 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. |
I have an implementation here: bitcoin-s/bitcoin-s#3823 |
|
I will make test vectors very soon. Let's compare notes at that point @benthecarman. |
Sounds good, I made some in pr if you want to try those |
|
Yep. I will try them, once I make my own. I don't want to adjust the code to fit your test vectors, I'd rather both implementations independently passing both sets. |
8eb5031 to
93a9c68
Compare
|
Would like to see BIP 322 address the distinction between the current "signer receives fund with the address" and the long-desired "signer sent a prior transaction" even if not supported by this PR. |
|
@luke-jr I'm not sure if you're suggesting a BIP change or a code feature. If the latter, I think the ideal path forward is for you to open a pull request follow-up to this one (maybe post-merge) to do what you are requesting. If former, open a PR to the BIP? |
theStack
left a comment
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.
Strong Concept ACK
Thanks for working on this!
|
There is now a WIP with test vectors in bitcoin/bips#1279 which needs to be filled in (possibly with @benthecarman's cases). |
theStack
left a comment
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.
PR description nit:
(RPC) format is restricted to SINGLE mode now; it may eventually be LEGACY, SINGLE, OR FULL
This should likely be SIMPLE rather than SINGLE?
src/util/message.cpp
Outdated
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.
Note that HASHER_BIP322 and some other identifiers are not available yet at this commit, i.e. compiling b23186d9f816aefe2fcf95e6f77d941c65e9c71c currently fails:
...
CXX wallet/libbitcoin_wallet_tool_a-wallettool.o
util/message.cpp:105:41: error: use of undeclared identifier 'HASHER_BIP322'
uint256 message_hash = (CHashWriter(HASHER_BIP322) << message).GetSHA256();
^
util/message.cpp:116:22: error: use of undeclared identifier 'DecodeTx'
if (signature && DecodeTx(to_sign, *signature, /* try_no_witness */ true, /* try_witness */ true)) {
^
util/message.cpp:120:49: error: no member named 'ERR_POF' in 'MessageVerificationResult'
result = MessageVerificationResult::ERR_POF;
~~~~~~~~~~~~~~~~~~~~~~~~~~~^
util/message.cpp:128:49: error: no member named 'ERR_INVALID' in 'MessageVerificationResult'
result = MessageVerificationResult::ERR_INVALID;
~~~~~~~~~~~~~~~~~~~~~~~~~~~^
util/message.cpp:141:57: error: no member named 'ERR_INVALID' in 'MessageVerificationResult'
result = MessageVerificationResult::ERR_INVALID;
~~~~~~~~~~~~~~~~~~~~~~~~~~~^
5 errors generated.
...
6de4601 to
5053032
Compare
Github-Pull: bitcoin#24058 Rebased-From: b08d75d
Github-Pull: bitcoin#24058 Rebased-From: 3b00ed9
Github-Pull: bitcoin#24058 Rebased-From: f57ed58
Github-Pull: bitcoin#24058 Rebased-From: b32c238
Github-Pull: bitcoin#24058 Rebased-From: 69bd3c4
Github-Pull: bitcoin#24058 Rebased-From: b8a55e2
…rify tests Co-authored-by: Will Abramson <wip.abramson@gmail.com> Github-Pull: bitcoin#24058 Rebased-From: 63a2f59
Co-authored-by: Will Abramson <wip.abramson@gmail.com> Github-Pull: bitcoin#24058 Rebased-From: de070b3
Co-authored-by: Will Abramson <wip.abramson@gmail.com> Github-Pull: bitcoin#24058 Rebased-From: 29b28d0
Github-Pull: bitcoin#24058 Rebased-From: 3a5816f
Github-Pull: bitcoin#24058 Rebased-From: f0af8bd
Github-Pull: bitcoin#24058 Rebased-From: cf2d75f
Github-Pull: bitcoin#24058 Rebased-From: 35cf639
Github-Pull: bitcoin#24058 Rebased-From: b08d75d
Github-Pull: bitcoin#24058 Rebased-From: 3b00ed9
Github-Pull: bitcoin#24058 Rebased-From: f57ed58
Github-Pull: bitcoin#24058 Rebased-From: b32c238
Github-Pull: bitcoin#24058 Rebased-From: 69bd3c4
Github-Pull: bitcoin#24058 Rebased-From: b8a55e2
…rify tests Co-authored-by: Will Abramson <wip.abramson@gmail.com> Github-Pull: bitcoin#24058 Rebased-From: 63a2f59
Co-authored-by: Will Abramson <wip.abramson@gmail.com> Github-Pull: bitcoin#24058 Rebased-From: de070b3
Co-authored-by: Will Abramson <wip.abramson@gmail.com> Github-Pull: bitcoin#24058 Rebased-From: 29b28d0
Came here from reading BIP 322. Should this be marked as up for grabs? Still desired/needed? Edit: seems to be a prerequisite for BIP 129. |
|
I closed it as the effort required to keep up with wallet changes vs the interest in the feature itself did not at all match up. If someone wants to pick it up then by all means. |
|
Thanks @kallewoof! |
|
For the record, I do believe there is a strong use case for this feature. In particular, due to the travel rule. We have clients who get requests to prove the ownership of their wallet and since they can't use the legacy message signing option with their multisig wallet, the exchanges and other service providers are requiring them to send dust-level amounts of bitcoin to prove control. This, of course, is not really a viable long-term strategy. |
|
If no one is actively looking into this at the moment, I will see about restoring (probably rewriting from scratch) this PR. |
This PR enables support for BIP-322, the sign/verify message upgrade.
Fixes #10542.
This PR is greatly simplified and is supposed to have one or more follow-up PRs to complete functionality.
In this PR:
Missing features/limitations: