<p><a href="https://www.rfc-editor.org/rfc/rfc4880#section-5.2.1" rel="nofollow noreferrer">RFC4880</a> apparently standardises the way signatures work, so it <em>could</em> be referring to:</p>
<blockquote>
<p>0x18: Subkey Binding Signature
This signature is a statement by the top-level signing key that
indicates that it owns the subkey.  This signature is calculated
directly on the primary key and subkey, and not on any User ID or
other packets.  A signature that binds a signing subkey MUST have
an Embedded Signature subpacket in this binding signature that
contains a 0x19 signature made by the signing subkey on the
primary key and subkey.</p>
</blockquote>
<p>But it seems much more likely <a href="https://github.com/bitid/bitid/blob/master/bip70_extension.md" rel="nofollow noreferrer">BIP70 extension proposal</a> is the reason for standardising signatures, as outlined by their BitID <a href="https://github.com/bitid/bitid#wallet-implementation-requirements" rel="nofollow noreferrer">wallet implementation requirements</a>:</p>
<blockquote>
<p>To be compatible with the BitID protocol, a wallet must implement the following:</p>
<ul>
<li>register the bitid scheme</li>
<li>throw a bitid intent when scanning a BitID QR code (if applicable)</li>
<li>decode the URI and verify its format</li>
<li>display a request for authentication showing the domain name callback and &gt; - ask for validation</li>
<li>ask the user to pick up or create a Bitcoin address for the authentication (show the last Bitcoin address used if this is a known callback address)</li>
<li><em><strong>sign the BitID URI with the private key (using the \x18Bitcoin Signed Message:\n#{message.size.chr}#{message} convention)</strong></em></li>
<li>POST the signature and the public key to the callback URL
completion dialog : success/retry/cancel</li>
</ul>
</blockquote>

CC BY-SA 4.0
2022-01-23T15:26:05.690Z
It would have been much better if you actually explained and not citing the documents.
gneric
CC BY-SA 3.0
2015-04-09T02:59:04.250Z
2015-04-09T02:59:04.250Z
2021-10-07T07:34:52.683Z
Wizard Of Ozzie
<p>The standard Bitcoin message signature works as follows:</p>

<pre><code>sign(sha256(magicPrefix . length(message) . message))
</code></pre>

<p>The "magic prefix" is simply the string <code>'\x18Bitcoin Signed Message:\n'</code>, where 0x18 is the length of the prefix text.</p>

<p>In other words, it's this:</p>

<pre><code>sign(sha256(length(prefix) . prefix . length(message) . message))
</code></pre>

<p>My question is:</p>

<ol>
<li>Why does it use a magic prefix?</li>
<li>Why does it include the lengths of the two components?</li>
</ol>

<p>I'm asking mainly from a security point of view. Does adding a prefix or including the length(s) have any security benefits? If not, I'd like to drop it from my signatures.</p>

CC BY-SA 3.0
2015-04-09T01:50:44.607Z
Is this from the C++ code? Because I saw similar code in pybitcointools' `electrum_sig_hash` function
Wizard Of Ozzie
CC BY-SA 3.0
2015-04-09T02:02:43.667Z
It's also in BitcoinJS: https://github.com/bitcoinjs/bitcoinjs-lib/blob/1079bf95c1095f7fb018f6e4757277d83b7b9d07/src/message.js#L13
Manish
CC BY-SA 3.0
2015-04-09T08:37:15.910Z
The duplicate doesn't address the inclusion of the lengths. The answer is that it's to definitively protect against [length extension attacks](http://en.wikipedia.org/wiki/Length_extension_attack).
David Schwartz
<message-signing>
Why does the standard Bitcoin message signature include a "magic prefix?"
Manish
# Why does the standard Bitcoin message signature include a "magic prefix?"

(Asked by: username_0 on 2015-04-09)

The standard Bitcoin message signature works as follows:
sign(sha256(magicPrefix . length(message) . message))

The "magic prefix" is simply the string '\x18Bitcoin Signed Message:\n', where 0x18 is the length of the prefix text.
In other words, it's this:
sign(sha256(length(prefix) . prefix . length(message) . message))

My question is:

Why does it use a magic prefix?
Why does it include the lengths of the two components?

I'm asking mainly from a security point of view. Does adding a prefix or including the length(s) have any security benefits? If not, I'd like to drop it from my signatures.

**Tags:** message-signing

> **Comments:**
> **username_1**: Is this from the C++ code? Because I saw similar code in pybitcointools' `electrum_sig_hash` function  
> **username_0**: It's also in BitcoinJS: https://github.com/bitcoinjs/bitcoinjs-lib/blob/1079bf95c1095f7fb018f6e4757277d83b7b9d07/src/message.js#L13  
> **username_2**: The duplicate doesn't address the inclusion of the lengths. The answer is that it's to definitively protect against [length extension attacks](http://en.wikipedia.org/wiki/Length_extension_attack).  

---

## 1 answers

### Answer by username_1 on 2015-04-09. Score: 0

[RFC4880](https://www.rfc-editor.org/rfc/rfc4880#section-5.2.1) apparently standardises the way signatures work, so it *could* be referring to:

> 0x18: Subkey Binding Signature
> This signature is a statement by the top-level signing key that
> indicates that it owns the subkey. This signature is calculated
> directly on the primary key and subkey, and not on any User ID or
> other packets. A signature that binds a signing subkey MUST have
> an Embedded Signature subpacket in this binding signature that
> contains a 0x19 signature made by the signing subkey on the
> primary key and subkey.

But it seems much more likely [BIP70 extension proposal](https://github.com/bitid/bitid/blob/master/bip70_extension.md) is the reason for standardising signatures, as outlined by their BitID [wallet implementation requirements](https://github.com/bitid/bitid#wallet-implementation-requirements):

> To be compatible with the BitID protocol, a wallet must implement the following:
>
> * register the bitid scheme
> * throw a bitid intent when scanning a BitID QR code (if applicable)
> * decode the URI and verify its format
> * display a request for authentication showing the domain name callback and > - ask for validation
> * ask the user to pick up or create a Bitcoin address for the authentication (show the last Bitcoin address used if this is a known callback address)
> * ***sign the BitID URI with the private key (using the \x18Bitcoin Signed Message:\n#{message.size.chr}#{message} convention)***
> * POST the signature and the public key to the callback URL
>   completion dialog : success/retry/cancel

> **Comments:**
> **username_3**: It would have been much better if you actually explained and not citing the documents.  

---

