Skip to content

Conversation

@kallewoof
Copy link
Contributor

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

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
Contributor 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
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
Contributor 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
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
Contributor 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
Contributor 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"?

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

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

@kallewoof kallewoof force-pushed the 202201-bip322 branch 2 times, most recently from 6de4601 to 5053032 Compare January 31, 2022 04:18
luke-jr pushed a commit to bitcoinknots/bitcoin that referenced this pull request Mar 5, 2025
luke-jr pushed a commit to bitcoinknots/bitcoin that referenced this pull request Mar 5, 2025
luke-jr pushed a commit to bitcoinknots/bitcoin that referenced this pull request Mar 5, 2025
luke-jr pushed a commit to bitcoinknots/bitcoin that referenced this pull request Mar 5, 2025
luke-jr added a commit to bitcoinknots/bitcoin that referenced this pull request Mar 5, 2025
luke-jr pushed a commit to bitcoinknots/bitcoin that referenced this pull request Mar 5, 2025
luke-jr pushed a commit to bitcoinknots/bitcoin that referenced this pull request Mar 5, 2025
…rify tests

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

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

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

Github-Pull: bitcoin#24058
Rebased-From: 29b28d0
@bitcoin bitcoin deleted a comment Mar 11, 2025
@bitcoin bitcoin deleted a comment Mar 11, 2025
luke-jr pushed a commit to luke-jr/bitcoin that referenced this pull request Jun 6, 2025
luke-jr pushed a commit to luke-jr/bitcoin that referenced this pull request Jun 6, 2025
luke-jr pushed a commit to luke-jr/bitcoin that referenced this pull request Jun 6, 2025
luke-jr pushed a commit to luke-jr/bitcoin that referenced this pull request Jun 6, 2025
luke-jr pushed a commit to luke-jr/bitcoin that referenced this pull request Jun 6, 2025
luke-jr pushed a commit to luke-jr/bitcoin that referenced this pull request Jun 6, 2025
luke-jr pushed a commit to luke-jr/bitcoin that referenced this pull request Jun 6, 2025
luke-jr pushed a commit to luke-jr/bitcoin that referenced this pull request Jun 6, 2025
luke-jr added a commit to luke-jr/bitcoin that referenced this pull request Jun 6, 2025
luke-jr pushed a commit to luke-jr/bitcoin that referenced this pull request Jun 6, 2025
luke-jr pushed a commit to luke-jr/bitcoin that referenced this pull request Jun 6, 2025
…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 Jun 6, 2025
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 Jun 6, 2025
Co-authored-by: Will Abramson <wip.abramson@gmail.com>

Github-Pull: bitcoin#24058
Rebased-From: 29b28d0
@jonatack
Copy link
Member

jonatack commented Oct 26, 2025

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

Same question @kallewoof , why did you close this? It's a much needed feature.

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.

@kallewoof
Copy link
Contributor Author

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.

@kallewoof
Copy link
Contributor Author

Belated, but I completely missed the two other comments asking for clarification until now. Sorry @benma and @kilrau, didn't mean to ignore you.

@jonatack
Copy link
Member

Thanks @kallewoof!

@jlopp
Copy link
Contributor

jlopp commented Nov 18, 2025

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.

@kallewoof
Copy link
Contributor Author

If no one is actively looking into this at the moment, I will see about restoring (probably rewriting from scratch) this PR.

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