-
Notifications
You must be signed in to change notification settings - Fork 36.2k
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
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
@@ -1707,6 +1711,9 @@ bool GenericTransactionSignatureChecker<T>::CheckSchnorrSignature(Span<const uns | |||
|
|||
uint8_t hashtype = SIGHASH_DEFAULT; | |||
if (sig.size() == 65) { | |||
if (m_require_sighash_all) { |
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
@@ -348,9 +348,16 @@ static RPCHelpMan verifymessage() | |||
throw JSONRPCError(RPC_TYPE_ERROR, "Address does not refer to key"); | |||
case MessageVerificationResult::ERR_MALFORMED_SIGNATURE: | |||
throw JSONRPCError(RPC_TYPE_ERROR, "Malformed base64 encoding"); | |||
case MessageVerificationResult::ERR_POF: | |||
throw JSONRPCError(RPC_TYPE_ERROR, "Proof of funds require UTXO set access to verify"); // TODO: get access to UTXO set / mempool to handle this, then remove this error code? |
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
case MessageVerificationResult::ERR_POF: | ||
throw JSONRPCError(RPC_TYPE_ERROR, "Proof of funds require UTXO set access to verify"); // TODO: get access to UTXO set / mempool to handle this, then remove this error code? | ||
case MessageVerificationResult::INCONCLUSIVE: | ||
return false; // TODO: switch to a string based result? mix bool and strings? |
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"?
OK, | ||
|
||
// | ||
// BIP-322 extensions |
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? |
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). |
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
} | ||
|
||
// prepare message hash | ||
uint256 message_hash = (CHashWriter(HASHER_BIP322) << message).GetSHA256(); |
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 b23186d 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
"AkgwRQIhAOzyynlqt93lOKJr+wmmxIens//zPzl9tqIOua93wO6MAiBi5n5EyAcPScOjf1lAqIUIQtr3zKNeavYabHyR8eGhowEhAsfxIAMZZEKUPYWI4BruhAQjzFT8FSFSajuFwrDL1Yhy", | ||
"Hello World"), |
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 get this value in my implementation, yet it is not reflected in the BIP
@kallewoof could you leave a comment explaining why you closed this PR? It is not apparent from looking at the history of this PR what the state is of BIP-322 support in Bitcoin Core. |
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
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: