Skip to content
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

Closed
wants to merge 13 commits into from
Closed

BIP-322 basic support #24058

wants to merge 13 commits into from

Conversation

kallewoof
Copy link
Member

@kallewoof kallewoof commented Jan 13, 2022

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:

  • signing using single key (any type)
  • verifying any signed message (auto-detects BIP-322 vs legacy)

Missing features/limitations:

  • proof of funds (i.e. additional inputs) support
  • multisig or other custom address type support (I need feedback on how to do this; I assume some psbt thing would be good?)
  • (RPC) format is restricted to SIMPLE mode now; it may eventually be LEGACY, SIMPLE, or FULL. (In some cases, it will use FULL format but this is not selectable yet.)
  • timelock support

@ghost
Copy link

ghost commented Jan 13, 2022

Concept ACK

This should fix #10542

@Sjors
Copy link
Member

Sjors commented Jan 13, 2022

@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).

@@ -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) {
Copy link
Member

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.

Copy link
Member Author

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?
Copy link
Member

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"

Copy link
Member Author

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?
Copy link
Member

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?

Copy link
Member Author

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.

Copy link
Member

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.

Copy link
Member Author

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
Copy link
Member

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?

Copy link
Member Author

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.

@DrahtBot
Copy link
Contributor

DrahtBot commented Jan 13, 2022

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Reviews

See the guideline for information on the review process.

Type Reviewers
ACK theStack
Concept ACK ghost

If your review is incorrectly listed, please react with 👎 to this comment and the bot will ignore it on the next update.

Conflicts

Reviewers, this pull request conflicts with the following ones:

  • #26008 (wallet: cache IsMine scriptPubKeys to improve performance of descriptor wallets by achow101)

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.

@benthecarman
Copy link
Contributor

@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).

I have an implementation here: bitcoin-s/bitcoin-s#3823

@kallewoof
Copy link
Member Author

I will make test vectors very soon. Let's compare notes at that point @benthecarman.

@benthecarman
Copy link
Contributor

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

@kallewoof
Copy link
Member Author

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.

@kallewoof kallewoof force-pushed the 202201-bip322 branch 2 times, most recently from 8eb5031 to 93a9c68 Compare January 14, 2022 04:53
@luke-jr
Copy link
Member

luke-jr commented Jan 15, 2022

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.

@kallewoof
Copy link
Member Author

@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?

Copy link
Contributor

@theStack theStack left a 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!

@kallewoof
Copy link
Member Author

There is now a WIP with test vectors in bitcoin/bips#1279 which needs to be filled in (possibly with @benthecarman's cases).

Copy link
Contributor

@theStack theStack left a 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?

}

// prepare message hash
uint256 message_hash = (CHashWriter(HASHER_BIP322) << message).GetSHA256();
Copy link
Contributor

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.
...

@kallewoof kallewoof force-pushed the 202201-bip322 branch 2 times, most recently from 6de4601 to 5053032 Compare January 31, 2022 04:18
Comment on lines +2717 to +2718
"AkgwRQIhAOzyynlqt93lOKJr+wmmxIens//zPzl9tqIOua93wO6MAiBi5n5EyAcPScOjf1lAqIUIQtr3zKNeavYabHyR8eGhowEhAsfxIAMZZEKUPYWI4BruhAQjzFT8FSFSajuFwrDL1Yhy",
"Hello World"),

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

@benma
Copy link

benma commented Oct 26, 2023

@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.

luke-jr pushed a commit to luke-jr/bitcoin that referenced this pull request Mar 12, 2024
luke-jr pushed a commit to luke-jr/bitcoin that referenced this pull request Mar 12, 2024
luke-jr pushed a commit to luke-jr/bitcoin that referenced this pull request Mar 12, 2024
luke-jr pushed a commit to luke-jr/bitcoin that referenced this pull request Mar 12, 2024
luke-jr pushed a commit to luke-jr/bitcoin that referenced this pull request Mar 12, 2024
luke-jr pushed a commit to luke-jr/bitcoin that referenced this pull request Mar 12, 2024
luke-jr pushed a commit to luke-jr/bitcoin that referenced this pull request Mar 12, 2024
luke-jr pushed a commit to luke-jr/bitcoin that referenced this pull request Mar 12, 2024
luke-jr pushed a commit to luke-jr/bitcoin that referenced this pull request Mar 12, 2024
luke-jr pushed a commit to luke-jr/bitcoin that referenced this pull request Mar 12, 2024
luke-jr pushed a commit to luke-jr/bitcoin that referenced this pull request Mar 12, 2024
…rify tests

Co-authored-by: Will Abramson <wip.abramson@gmail.com>

Github-Pull: bitcoin#24058
Rebased-From: 63a2f59
luke-jr pushed a commit to luke-jr/bitcoin that referenced this pull request Mar 12, 2024
Co-authored-by: Will Abramson <wip.abramson@gmail.com>

Github-Pull: bitcoin#24058
Rebased-From: de070b3
luke-jr pushed a commit to luke-jr/bitcoin that referenced this pull request Mar 12, 2024
Co-authored-by: Will Abramson <wip.abramson@gmail.com>

Github-Pull: bitcoin#24058
Rebased-From: 29b28d0
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

Signmessage doesn't work with segwit addresses