Message signing - Revision history

Sysadmin: Fixed formatting for the example of an RFC2440-like signature

2025-09-25T13:40:44Z

Fixed formatting for the example of an RFC2440-like signature

← Older revision		Revision as of 13:40, 25 September 2025
Line 18:		Line 18:
	The RFC2440-like format has the following structure, where Message, Address, and Signature are as defined at the beginning of this section:		The RFC2440-like format has the following structure, where Message, Address, and Signature are as defined at the beginning of this section:

	~~<code>~~		-----BEGIN BITCOIN SIGNED MESSAGE-----
	-----BEGIN BITCOIN SIGNED MESSAGE-----		Message
	Message		-----BEGIN BITCOIN SIGNATURE-----
	-----BEGIN BITCOIN SIGNATURE-----		Address
	Address		Signature
	Signature		-----END BITCOIN SIGNATURE-----
	-----END BITCOIN SIGNATURE-----
	~~</code>~~

	The text must begin with "-----BEGIN BITCOIN SIGNED MESSAGE-----", including the 5 ASCII dashes on both the beginning and end of the line, followed by the Message, followed by "-----BEGIN BITCOIN SIGNATURE-----" along with the dashes similarly, followed by the Address, followed by the Signature, followed by "-----END BITCOIN SIGNATURE-----" with the dashes. All components must be separated by a newline (CRLF, LF, or CR).		The text must begin with "-----BEGIN BITCOIN SIGNED MESSAGE-----", including the 5 ASCII dashes on both the beginning and end of the line, followed by the Message, followed by "-----BEGIN BITCOIN SIGNATURE-----" along with the dashes similarly, followed by the Address, followed by the Signature, followed by "-----END BITCOIN SIGNATURE-----" with the dashes. All components must be separated by a newline (CRLF, LF, or CR).

Coolaj86: fix typo: bettwen => between

2024-10-24T04:26:29Z

fix typo: bettwen => between

← Older revision		Revision as of 04:26, 24 October 2024
Line 176:		Line 176:
	# Set ''DecodedSignature = Base64Decode(Signature)''		# Set ''DecodedSignature = Base64Decode(Signature)''
	# Set ''HeaderByte = DecodedSignature[0]''		# Set ''HeaderByte = DecodedSignature[0]''
	#* If HeaderByte is ~~bettwen~~ 27 and 30 inclusive, use "ECDSA verification, P2PKH uncompressed address".		#* If HeaderByte is between 27 and 30 inclusive, use "ECDSA verification, P2PKH uncompressed address".
	#* Else, if HeaderByte is ~~bettwen~~ 31 and 34 inclusive, use "ECDSA verification, P2PKH compressed address".		#* Else, if HeaderByte is between 31 and 34 inclusive, use "ECDSA verification, P2PKH compressed address".
	#* Else, if HeaderByte is ~~bettwen~~ 35 and 38 inclusive, use "ECDSA verification, P2WPKH-P2SH compressed address".		#* Else, if HeaderByte is between 35 and 38 inclusive, use "ECDSA verification, P2WPKH-P2SH compressed address".
	#* Else, if HeaderByte is ~~bettwen~~ 39 and 42 inclusive, use "ECDSA verification, P2WPKH compressed address".		#* Else, if HeaderByte is between 39 and 42 inclusive, use "ECDSA verification, P2WPKH compressed address".
	#* Else, if HeaderByte is ~~bettwen~~ 43 and 46 inclusive, use "Schnorr verification, P2TR (Taproot) compressed address".		#* Else, if HeaderByte is between 43 and 46 inclusive, use "Schnorr verification, P2TR (Taproot) compressed address".
	#* Else, fail verification with an error similar to "Unknown signature type".		#* Else, fail verification with an error similar to "Unknown signature type".

NotATether: Add information about signing formats

2022-08-06T06:14:08Z

Add information about signing formats

@@ Line 8: / Line 8: @@
 As of this writing, there is no message signing support for Taproot addresses. Not only do they use a different signing algorithm in the form of Schnorr, but public key recovery is not possible with Schnorr signatures, so they cannot be compared to addresses.
 == Detailed specification of the message signature ==
 ECDSA signatures generate a 32-byte r-value and a 32-byte s-value (see [[Elliptic Curve Digital Signature Algorithm]]), which collectively represent the signature. Bitcoin signatures have the r and s values mentioned above, and a 1-byte header. Therefore, the size of a signature is 65 bytes.

NotATether: added BIP322 reference

2022-08-06T06:12:10Z

added BIP322 reference

← Older revision		Revision as of 06:12, 6 August 2022
Line 39:		Line 39:

	== Algorithm for signing and verifying messages ==		== Algorithm for signing and verifying messages ==

			Below is a list of instructions for creating a BIP137-compliant message signing and verification algorithm.

	It is not required, but you should strip trailing newlines from the message before signing it, because some clients cannot process messages that contain trailing newlines.		It is not required, but you should strip trailing newlines from the message before signing it, because some clients cannot process messages that contain trailing newlines.
Line 89:		Line 91:
	The constant ''G'' shall refer to the secp256k1 generator point, defined as ''(79BE667E F9DCBBAC 55A06295 CE870B07 029BFCDB 2DCE28D9 59F2815B 16F81798, 483ADA77 26A3C465 5DA4FBFC 0E1108A8 FD17B448 A6855419 9C47D08F FB10D4B8)''		The constant ''G'' shall refer to the secp256k1 generator point, defined as ''(79BE667E F9DCBBAC 55A06295 CE870B07 029BFCDB 2DCE28D9 59F2815B 16F81798, 483ADA77 26A3C465 5DA4FBFC 0E1108A8 FD17B448 A6855419 9C47D08F FB10D4B8)''

	=== Message signing ~~Method~~ ===		=== Message signing method ===

			It takes the following parameters:

	~~It takes the following parameters~~
	* The private key (PrivateKey)		* The private key (PrivateKey)
	* The public key (PublicKey) (optional, if performance is desired)		* The public key (PublicKey) (optional, if performance is desired)
Line 138:		Line 141:


	=== Message verification ~~Method~~ ===		=== Message verification method ===

	It takes the following parameters:		It takes the following parameters:
Line 238:		Line 241:
	# Compute ''DerivedAddress = Bech32("bc", 0, AddressHash)''		# Compute ''DerivedAddress = Bech32("bc", 0, AddressHash)''
	# If ''DerivedAddress == Address'', succeed verification. Else fail verification with an error similar to "Wrong address for signature".		# If ''DerivedAddress == Address'', succeed verification. Else fail verification with an error similar to "Wrong address for signature".

			== Alternative formats ==

			Work is currently under way to create a new signing format called BIP322<ref>https://github.com/bitcoin/bips/blob/master/bip-0322.mediawiki - BIP 322</ref> that can verify signatures from all types of addresses, including scripts, multisig, and Taproot. It is currently a draft.

	== References ==		== References ==

NotATether: add references

2022-08-06T06:08:43Z

add references

← Older revision		Revision as of 06:08, 6 August 2022
Line 238:		Line 238:
	# Compute ''DerivedAddress = Bech32("bc", 0, AddressHash)''		# Compute ''DerivedAddress = Bech32("bc", 0, AddressHash)''
	# If ''DerivedAddress == Address'', succeed verification. Else fail verification with an error similar to "Wrong address for signature".		# If ''DerivedAddress == Address'', succeed verification. Else fail verification with an error similar to "Wrong address for signature".

			== References ==

NotATether: added algorithm

2022-08-06T06:07:48Z

added algorithm

Show changes

NotATether: Create preliminary page

2022-08-06T05:55:56Z

Create preliminary page

New page

'''Message signing''' is the action of signing a cryptographic message using a private key and its associated address, to prove that you have access to the address. These messages can be verified by wallets by checking the signature against the address to see if they correspond to each other. The result of message signing is often called a '''signed message'''.

Bitcoin signed messages have three parts, which are the '''Message''', '''Address''', and '''Signature'''. The message is the actual message text - all kinds of text is supported, but it is recommended to avoid using non-ASCII characters in the signature because they might be encoded in different character sets, preventing signature verification.

The address is a legacy, nested segwit, or native segwit address. Message signing from segwit addresses has been added by BIP137<ref>https://github.com/bitcoin/bips/blob/master/bip-0137.mediawiki - BIP 137</ref>.

The Signature is a base64-encoded ECDSA signature that, when decoded, contain the following fields:

* Byte 0 of the signature represents the header byte, which identifies the address type
* Bytes 1 to 32 inclusive represents the "r" of the ECDSA signature (see [[Elliptic Curve Digital Signature Algorithm]]).
* Bytes 33 to 65 inclusive represents the "s" of the ECDSA signature.

As of this writing, there is no message signing support for Taproot addresses. Not only do they use a different signing algorithm in the form of Schnorr, but public key recovery is not possible with Schnorr signatures, so they cannot be compared to addresses.