Consider Removing Message Signing

TheBlueMatt commented at 3:43 am on April 22, 2023: contributor

Signing arbitrary messages with Bitcoin private keys was always a bit strange. It was designed to handle only the narrow case of single-sig keys, and isn’t well-defined for new address types. Worse, it doesn’t allow for signing messages with more arbitrary scripts, and its not clear what the semantics for such things would be.

Sadly, the message signing feature is now being abused to “verify wallets” as a part of withdraw flows. This prevents Bitcoin users from using anything but an incredibly narrow set of scripts (in many cases only P2PKH, not even modern script formats, and definitely not multisig).

Rather than trying to rework it to avoid these things breaking Bitcoin, it seems like it’d be much better to simply remove the message signing logic entirely. If someone comes along with a proposal that considers a broader set of scripts and a more sensible design that could be considered.

TheBlueMatt added the label Feature on Apr 22, 2023

achow101 commented at 4:01 am on April 22, 2023: member

If someone comes along with a proposal that considers a broader set of scripts and a more sensible design that could be considered.

BIP 322? (#24058)

jaybny commented at 4:13 am on April 22, 2023: none

what percentage of bitcoiners still use single-sig keys? P2PKH is perfect for most use cases. what is the problem? please stop this. leave the feature.

weedcoder commented at 4:32 am on April 22, 2023: none

as @achow101 said BIP322. proof of funds is a must have.

elkimek commented at 5:55 am on April 22, 2023: none

You don’t fight bullies with hiding and give up things. You push back like people did when Trezor implemented AOPP.

thibistaken commented at 6:20 am on April 22, 2023: none

What about key health checks? Allows a user to verify the key they control can still sign a given address, without broadcasting it to the network. It’s free and private. Sounds pretty useful.

bitnorbert commented at 7:00 am on April 22, 2023: none

What about key health checks? Allows a user to verify the key they control can still sign a given address, without broadcasting it to the network.

Would arguably be better to do such checks by signing a transaction and not broadcasting it.

GregTonoski commented at 8:27 am on April 22, 2023: none

Sadly, the message signing feature is now being abused to “verify wallets” as a part of withdraw flows

Abusers may resolve the issue themselves and there isn’t any Bitcoin Core change that could stop them. I suggest contacting abusers instead of Bitcoin Core community.

Besides, users like the message signing feature. Not only in Bitcoin Core. There are many wallets that implement it.

aceofbitcoin commented at 1:08 pm on April 22, 2023: none

You can indeed use your private keys of bitcoin to digitally sign messages. If You don’t understand the basics of asymetric keys used to sign/verify transactions, messages or any text, You should first read more books about pgp, bitcoin and asymmetric encryption. I really don’t like such noob proposals, souinds like CSW crap lol. #satoshin https://en.bitcoin.it/wiki/Message_signing

TheBlueMatt commented at 2:28 pm on April 22, 2023: contributor

BIP 322 is great, but isn’t super practical to verify unless you have a full script interpreter (ie are Core). It also doesn’t address the “this is an anti-feature” issue :).

Still, if that’s added the existing message signing should be ripped out. Today it doesn’t really have any use, and the intended uses people do have for it are not good outcomes.

jlopp commented at 4:59 pm on April 22, 2023: contributor

I’ll note that message signing is an important feature we leverage for Casa clients to perform health checks on their keys and hardware devices without requiring them to actually sign a transaction. While at the software level, arbitrary signing of data with private keys could be accomplished pretty much however one wishes, it’s important to us that a message signing standard exists so that there’s a well defined spec for hardware device companies to support.

theStack commented at 5:21 pm on April 22, 2023: contributor

BIP 322 is great, but isn’t super practical to verify unless you have a full script interpreter (ie are Core).

In theory, using libconsensus for that shouldn’t be too hard, especially if a proper language binding is available? (Though admittedly, it still lacks Taproot support – #21158 is up for grabs).

sipa commented at 5:25 pm on April 22, 2023: member

BIP322 doesn’t actually need full script validation if partiality is acceptable (e.g. a verifier can just implement a specific templated subset of scripts, and reply inconclusive for anything beyond that). That may sound suboptimal, but a scheme that’s restricted by design to some subset cannot do better either.

The question is just getting it implemented and accepted; perhaps there is just not enough animus to spend effort on. But if that’s the case, I’m not sure if any (simpler, more restrictive?) alternative is going to fare much better.

In any case, I’m not in favor of dropping this feature until there is a reasonable more flexible alternative available and adopted. Bitcoin Core, as a wallet, isn’t all that important in the market I think, so dropping support for a feature that seems abused by some is more likely to just drive people who rely on to other wallets rather than effect change in how it’s used.

mzumsande commented at 6:04 pm on April 22, 2023: contributor

some previous discussion in #24186.

harding commented at 6:34 pm on April 22, 2023: contributor

Signing arbitrary messages with Bitcoin private keys was always a bit strange. It was designed to handle only the narrow case of single-sig keys, and isn’t well-defined for new address types. Worse, it doesn’t allow for signing messages with more arbitrary scripts

LN requires channel owners sign their gossip messages in order to use the costliness of acquiring a UTXO to prevent DoS attacks. Both currently and in proposed changes, that requires using a narrow set of specific script templates.

If using UTXO-controlling keys to sign non-transaction data is something we’re baking into core protocols, I don’t think we should be making it harder for application protocols to also use that feature. If the problem is that signing only works with a narrow set of script templates, then I think that’s something that should be addressed first in core protocols. Alternatively, if we think adding support for arbitrary script verification to core protocols is unwarranted, then I don’t think it’s warranted for us to ask application protocols to do what we will not.

NicolasDorier commented at 2:18 am on April 23, 2023: contributor

Just mentioning here that I removed the ability for message signing from NBitcoin a long time ago against the push for AOPP.

People who really need it just have to code it themselves. (which is just a few lines you can get looking the history of NBitcoin’s code)

satsie commented at 3:20 pm on April 24, 2023: contributor

Given that all features require some effort to maintain, does this message signing code have a disproportionately high maintenance cost? You mention it is being abused to verify wallets, but I want to echo jlopp’s comment about its usage being, in the absence of another well established standard (official or not), a way to arbitrarily sign messages with private keys. From what I have seen, this feature is mainly used to verify the integrity of hardware and software wallets–to make sure the BIP-32 HD wallet root key is still intact and the device can produce a signature. While it’s certainly not ideal to use P2PKH, in this context, it doesn’t really matter.

I believe the scope of this feature’s usage might be larger than most realize. Both Casa ("Health Check") and Unchained ("Key Check") are using it, which means every device they support has implemented this style of message signing: Trezor, Ledger, Coldcard, Keystone, Passport

The folks at CoinKite have even created a tool for verifying messages (https://checkmsg.org/), and it’s my understanding that Sparrow supports this as well. In fact, I think any piece of software that supports BIP-137 has to have implemented this feature since BIP-137 is a proposal to extend this kind of message signing to support other address types.

Admittedly, I’m a little baffled at how this style of message signing became so widely used, as it was Satoshi code that came before the BIP process. The best place I’ve found it documented is the Bitcoin Wiki, and even that is missing some critical information like the Bitcoin Signed Message:\n magic bytes. It follows that Bitcoin Core’s implementation is being used as reference, and its removal, especially in the absence of

a single source of truth for technical documentation on how to do “Satoshi format” (a term I first saw here) message signing and
a suitable replacement

would be premature and create confusion.

ekzyis commented at 4:22 pm on April 25, 2023: none

Would arguably be better to do such checks by signing a transaction and not broadcasting it.

I think having to create a transaction is unnecessary complex if you just want to check if you can spend a UTXO. For a transaction, you need to specify amount, fee rate and receiving address. And after signing, you must make sure to wipe this transaction completely from your computer so no one else can broadcast it.

You don’t fight bullies with hiding and give up things. You push back like people did when Trezor implemented AOPP.

I agree with this. I think removing this feature does more damage to good use cases instead of preventing/delaying AOPP. I don’t think any exchange or service which wants to implement AOPP will stop doing it because Bitcoin Core removed the feature. They can still give you the code to do it. For example, a simple website where you can download a tool and then upload a signature would suffice. They don’t need Bitcoin Core. It’s just code.

willcl-ark commented at 3:45 pm on September 21, 2023: contributor

This seems controversial and unlikely to be implemented.

willcl-ark closed this on Sep 21, 2023

Consider Removing Message Signing #27515