Signing a message with your bitcoin keys the old fashioned waySigning a message with your bitcoin keys the old fashioned way
You've probably heard of people talking about "signing a message" with their bitcoin keys. This is often used to demonstrate ownership of coins at a particular address. But the method for signing such messages used to be based on legacy P2PKH addresses and only worked with SegWit addresses using a kind of hack.
There was also this problem with the message signing protocol:
the current message signature format uses ECDSA signatures which do not commit to the public key, meaning that they do not actually prove knowledge of any secret keys. (Indeed, valid signatures can be tweaked by 3rd parties to become valid signatures on certain related keys.)
Nevertheless, most hardware signers like ColdCard, Ledger, Trezor, Jade, and BitBox supported this functionality through companion apps and software like Electrum and Sparrow Wallet.
BIP 322 updated the standard for message signingBIP 322 updated the standard for message signing
In 2018 BIP 322 was proposed as a new standard for this protocol. This standard proposed using the same format as bitcoin transactions (a PSBT), but including an invalid input so that it could never be included in a block. It also proposed a standard that worked with all address types.
While it is still listed as a draft in the BIP repo, it has seen some adoption: Bitcoin Core and Sparrow Wallet both support BIP 322.
Orangesurf's improvementOrangesurf's improvement
When using software that supports BIP 322 to sign a message, hardware signers don't display the actual message itself. @orangesurf recently proposed a way of enabling hardware signers to "display the full human-readable message for user verification before signing, rather than just an opaque hash."
Here's what orangesurf proposes:
Transmit the original message to the signing device alongside the to_sign PSBT. The device verifies the message by computing its hash and comparing against the message_hash in the PSBT. If they match, the device displays the message for user confirmation.
This seems like a good idea to me. It is pretty wild that hardware signers don't display the actual human readable text of the message when signing.
This proposal requires no changes to BIP322 or BIP174. It is purely a convention for transporting the message preimage to signing devices. Devices that do not implement this proposal can still sign BIP322 messages—they simply cannot display the human-readable message to the user.
And it looks like ColdCard has already implemented it:
Why would you ever expose the pubkey of a
p2(w)pkhaddress tho? Like... the whole point of having the hash and single-use keys is that you don't expose the pubkey before you spend it...To be honest, I had never really thought about how message signing worked before doing some reading to write this post.
Did I misunderstand how it worked/works, or was message-signing kind of a bad idea?
I didn't find very great answers on Stack Exchange regarding message signing, and I'm dubious of Gemini's explanations.
With all the quantum bois running around telling us that every long tail exposed address (p2pk, p2tr, reused anything) is at risk of QC haxx0rz? Signing a message would turn your p2(w)pkh into a p2pk, like Satoshi's coin that lopp wants to confiscate because it's too insecure to sit there.
https://twiiit.com/OrangeSurfBTC/status/2021933638594527718