{"number":150,"title":"Peer Authentication","authors":["Jonas Schnelli"],"status":"Closed","type":"Specification","layer":"Peer Services","created":"2016-03-23","license":"PD","requires":[],"replaces":[],"replacedBy":[],"discussion":[],"comments":"https://github.com/bitcoin/bips/wiki/Comments:BIP-0150","abstract":"This BIP describes a way for peers to authenticate to other peers to guarantee node ownership and/or allow peers to access additional or limited node services, without the possibility of fingerprinting.","eli5":"Describes a way for Bitcoin nodes to prove their identity to trusted peers, for example so an operator can securely connect their own wallet to their own node. It is designed so that outsiders cannot use the authentication to fingerprint or track nodes.","categories":["network"],"filename":"bip-0150.mediawiki","githubUrl":"https://github.com/bitcoin/bips/blob/master/bip-0150.mediawiki","format":"mediawiki","readingMinutes":6,"inbound":1,"revisions":11,"impact":37,"core":false,"references":[151],"lastModified":"2025-10-08","html":"<h2 id=\"abstract\">Abstract</h2>\n<p>This BIP describes a way for peers to authenticate to other peers to guarantee node ownership and/or allow peers to access additional or limited node services, without the possibility of fingerprinting.</p>\n<h2 id=\"motivation\">Motivation</h2>\n<p>We assume peer operators want to limit the access of different node services or increase datastream priorities to a selective subset of peers. Also we assume that peers want to connect to specific peers to broadcast or filter transactions (or similar actions that reveal sensitive information) and therefore operators want to authenticate the remote peer and ensure that they have not connected to a MITM (man-in-the-middle) attacker.</p>\n<p>Benefits of peer authentication:</p>\n<ul><li>\nPeers can detect MITM attacks when connecting to known peers\n</li></ul>\n<ul><li>\nPeers can allow resource hungry transaction filtering only to specific peers\n</li></ul>\n<ul><li>\nPeers can allow access to sensitive information that can lead to node fingerprinting (fee estimation)\n</li></ul>\n<ul><li>\nPeers can allow custom message types (private extensions) to authenticated peers\n</li></ul>\n<p>A simple authentication scheme based on elliptic cryptography will allow peers to identify each other and selectively allow access to restricted services or reject the connection if the peer identity cannot be verified.</p>\n<h2 id=\"specification\">Specification</h2>\n<p>The authentication scheme proposed in this BIP uses ECDSA, <strong>secrets will never be transmitted</strong>.</p>\n<p><strong>Authentication initialization must only happen if encrypted channels have been established (according to BIP-151 [1]).</strong></p>\n<p>The <strong>encryption-session-ID</strong> is available once channels are encrypted (according to BIP-151 [1]).</p>\n<p>The identity-public-keys used for the authentication must be pre-shared over a different channel (mail/PGP, physical paper exchange, etc.). This BIP does not cover a \"trust on first use\" (TOFU) concept.</p>\n<p>The authentication state must be kept until the encryption/connection terminates.</p>\n<p>Only one authentication process is allowed per connection. Re-authentication require re-establishing the connection.</p>\n<h3 id=\"known-peers-and-authorized-peers-database\">Known-peers and authorized-peers database</h3>\n<p>Each peer that supports p2p authentication must provide two user-editable \"databases\".</p>\n<ol><li>\n<strong>known-peers</strong> contains known identity-public-keys together with a network identifier (IP & port), similar to the \"known-host\" file supported by openssh.\n</li></ol>\n<ol><li>\n<strong>authorized-peers</strong> contains authorized identity-public-keys\n</li></ol>\n<h3 id=\"local-identity-key-management\">Local identity key management</h3>\n<p>Each peer can configure multiple identity-keys (ECC, 32 bytes). Peers should make sure that each network interface (IPv4, IPv6, tor) has its own identity-key (otherwise it would be possible to link a tor address to a IPvX address). The identity-public-key(s) can be shared over a different channel with other node-operators (or non-validating clients) to grant authorized access.</p>\n<h3 id=\"authentication-procedure\">Authentication procedure</h3>\n<p>Authentication based on this BIP will require both sides to authenticate. Signatures/public-keys will only be revealed if the remote peer can prove that they already know the remote identity-public-key.</p>\n<ol><li>\n-> Requesting peer sends <code>AUTHCHALLENGE</code> (hash)\n</li></ol>\n<ol><li>\n<- Responding peer sends <code>AUTHREPLY</code> (signature)\n</li></ol>\n<ol><li>\n-> Requesting peer sends <code>AUTHPROPOSE</code> (hash)\n</li></ol>\n<ol><li>\n<- Responding peer sends <code>AUTHCHALLENGE</code> (hash)\n</li></ol>\n<ol><li>\n-> Requesting peer sends <code>AUTHREPLY</code> (signature)\n</li></ol>\n<p>For privacy reasons, dropping the connection or aborting during the authentication process must not be allowed.</p>\n<h3 id=\"authchallenge-message\"><code>AUTHCHALLENGE</code> message</h3>\n<p>A peer can send an authentication challenge to see if the responding peer can produce a valid signature with the expected responding peer's identity-public-key by sending an <code>AUTHCHALLENGE</code>-message to the remote peer.</p>\n<p>The responding peer needs to check if the hash matches the hash calculated with his own local identity-public-key. Fingerprinting the requesting peer is not possible.</p>\n<div class=\"table-wrap\"><table><tbody><tr><th>Field Size</th><th>Description</th><th>Data type</th><th>Comments</th></tr><tr><td>32bytes</td><td>challenge-hash</td><td>hash</td><td><code>hash(encryption-session-ID</td><td>challenge_type</td><td>remote-peers-expected-identity-public-key)</code></td></tr></tbody></table></div>\n<p><code>challenge_type</code> is a single character. <code>i</code> if the <code>AUTHCHALLENGE</code>-message is the first, requesting challenge or <code>r</code> if it's the second, remote peers challenge message.</p>\n<h3 id=\"authreply-message\"><code>AUTHREPLY</code> message</h3>\n<p>A peer must reply an <code>AUTHCHALLENGE</code>-message with an <code>AUTHREPLY</code>-message.</p>\n<div class=\"table-wrap\"><table><tbody><tr><th>Field Size</th><th>Description</th><th>Data type</th><th>Comments</th></tr><tr><td>64bytes</td><td>signature</td><td>normalized comp.-signature</td><td>A signature of the encryption-session-ID done with the identity-key</td></tr></tbody></table></div>\n<p>If the challenge-hash from the <code>AUTHCHALLENGE</code>-message did not match the local authentication public-key, the signature must contain 64 bytes of zeros.</p>\n<p>The requesting peer can check the responding peer's identity by checking the validity of the sent signature against with the pre-shared remote peers identity-public-key.</p>\n<p>If the signature was invalid, the requesting peer must still proceed with the authentication by sending an <code>AUTHPROPOSE</code>-message with 32 random bytes.</p>\n<h3 id=\"authpropose-message\"><code>AUTHPROPOSE</code> message</h3>\n<p>A peer can propose authentication of the channel by sending an <code>AUTHPROPOSE</code>-message to the remote peer.</p>\n<p>If the signature sent in <code>AUTHREPLY</code> was invalid, the peer must still send an <code>AUTHPROPOSE</code>-message containing 32 random bytes.</p>\n<p>The <code>AUTHPROPOSE</code> message must be answered with an <code>AUTHCHALLENGE</code>-message - even if the proposed requesting-peers identity-public-key has not been found in the authorized-peers database. In case of no match, the responding <code>AUTHCHALLENGE</code>-message must contains 32 bytes of zeros.</p>\n<div class=\"table-wrap\"><table><tbody><tr><th>Field Size</th><th>Description</th><th>Data type</th><th>Comments</th></tr><tr><td>32bytes</td><td>auth-propose-hash</td><td>hash</td><td><code>hash(encryption-session-ID</td><td>\"p\"</td><td>identity-public-key)</code></td></tr></tbody></table></div>\n<h2 id=\"post-authentication-re-keying\">Post-Authentication Re-Keying</h2>\n<p>After the second <code>AUTHREPLY</code> message (requesting peer's signature -> responding peer), both clients must re-key the symmetric encryption according to BIP151 while using <strong>a slightly different re-key key derivation hash</strong>.</p>\n<p>Both peers re-key with <code>hash(encryption-session-ID || old_symmetric_cipher_key || requesting-peer-identity-public-key || responding-peer-identity-public-key)</code></p>\n<h2 id=\"identity-addresses\">Identity-Addresses</h2>\n<p>The peers should display/log the identity-public-key as an identity-address to the users, which is a base58-check encoded ripemd160(sha256) hash. The purpose of this is for better visual comparison (logs, accept-dialogs). The base58check identity byte is <code>0x0F</code> followed by an identity-address version number (=<code>0xFF01</code>).</p>\n<p>An identity address would look like <code>TfG4ScDgysrSpodWD4Re5UtXmcLbY5CiUHA</code> and can be interpreted as a remote peer's fingerprint.</p>\n<h2 id=\"compatibility\">Compatibility</h2>\n<p>This proposal is backward compatible. Non-supporting peers will ignore the new <code>AUTH*</code> messages.</p>\n<h2 id=\"example-of-an-auth-interaction\">Example of an auth interaction</h2>\n<p>Before authentication (once during peer setup or upgrade)</p>\n<ol><li>\nRequesting peer and responding peer create each an identity-keypair (standard ECC priv/pubkey)\n</li></ol>\n<ol><li>\nRequesting and responding peer share the identity-public-key over a different channel (mail/PGP, physical paper exchange, etc.)\n</li></ol>\n<ol><li>\nResponding peer stores requesting peers identity-public-key in its authorized-peers database (A)\n</li></ol>\n<ol><li>\nRequesting peer stores responding peers identity-public-key in its known-peers database together with its IP and port (B)\n</li></ol>\n<p>Encryption</p>\n<ol><li>\nEncrypted channels must be established (according to BIP-151 [1])\n</li></ol>\n<p>Authentication</p>\n<ol><li>\nRequesting peer sends an <code>AUTHCHALLENGE</code> message\n</li></ol>\n<p>AUTHCHALLENGE:     [32 bytes, hash(encryption-session-ID || \"i\" || <remote-peers-expected-identity-public-key>)]</p>\n<ol><li>\nResponding peer does create the same hash <code>(encryption-session-ID || \"i\" || &lt;remote-peers-expected-identity-public-key&gt;)</code> with its local identity-public-key\n</li></ol>\n<ol><li>\nIf the hash does not match, response with an <code>AUTHREPLY</code> message containing 64bytes of zeros.\n</li></ol>\n<ol><li>\nIn case of a match, response with an <code>AUTHREPLY</code> message\n</li></ol>\n<p>AUTHREPLY:     [64 bytes normalized compact ECDSA signature (H)] (sig of the encryption-session-ID done with the identity-key)</p>\n<ol><li>\nRequesting peer does verify the signature with the <code>remote-peers-identity-public-key</code>\n</li></ol>\n<ol><li>\nIf the signature is invalid, requesting peer answers with an <code>AUTHREPLY</code> message containing 32 random bytes\n</li></ol>\n<ol><li>\nIn case of a valid signature, requesting peer sends an <code>AUTHPROPOSE</code> message\n</li></ol>\n<p>AUTHPROPOSE:     [32 bytes, hash(encryption-session-ID || \"p\" || <client-identity-public-key>)]</p>\n<ol><li>\nResponding peer iterates over authorized-peers database (A), hashes the identical data and looks for a match.\n</li></ol>\n<ol><li>\nIf the hash does not match, responding peer answer with an <code>AUTHCHALLENGE</code> message containing 32 bytes of zeros.\n</li></ol>\n<ol><li>\nIn case of a match, responding peer sends an <code>AUTHCHALLENGE</code> message with the hashed client public-key\n</li></ol>\n<p>AUTHCHALLENGE:     [32 bytes, hash(encryption-session-ID || \"r\" || <client-identity-public-key>)]</p>\n<ol><li>\nRequesting peer sends an <code>AUTHREPLY</code> message containing 64 bytes of zeros if server failed to authenticate\n</li></ol>\n<ol><li>\nOtherwise, response with signature in the <code>AUTHREPLY</code> message\n</li></ol>\n<p>AUTHREPLY:     [64 bytes normalized compact ECDSA signature (H)] (sig of the encryption-session-ID done with the identity-key)</p>\n<ol><li>\nResponding peer must verify the signature and can grant access to restricted services.\n</li></ol>\n<ol><li>\nBoth peers re-key the encryption after BIP151 including the requesting-peer-identity-public-key and responding-peer-identity-public-key\n</li></ol>\n<h2 id=\"disadvantages\">Disadvantages</h2>\n<p>The protocol may be slow if a peer has a large authorized-peers database due to the requirement of iterating and hashing over all available authorized peer identity-public-keys.</p>\n<h2 id=\"reference-implementation\">Reference implementation</h2>\n<h2 id=\"references\">References</h2>\n<ul><li>\n[1] <a href=\"/bip/151\">BIP 151: Peer-to-Peer Communication Encryption</a>\n</li></ul>\n<h2 id=\"acknowledgements\">Acknowledgements</h2>\n<ul><li>\nGregory Maxwell and Pieter Wuille for most of the ideas in this BIP.\n</li></ul>\n<ul><li>\nBryan Bishop for editing.\n</li></ul>\n<h2 id=\"copyright\">Copyright</h2>\n<p>This work is placed in the public domain.</p>","toc":[{"id":"abstract","title":"Abstract","level":2},{"id":"motivation","title":"Motivation","level":2},{"id":"specification","title":"Specification","level":2},{"id":"known-peers-and-authorized-peers-database","title":"Known-peers and authorized-peers database","level":3},{"id":"local-identity-key-management","title":"Local identity key management","level":3},{"id":"authentication-procedure","title":"Authentication procedure","level":3},{"id":"authchallenge-message","title":"AUTHCHALLENGE message","level":3},{"id":"authreply-message","title":"AUTHREPLY message","level":3},{"id":"authpropose-message","title":"AUTHPROPOSE message","level":3},{"id":"post-authentication-re-keying","title":"Post-Authentication Re-Keying","level":2},{"id":"identity-addresses","title":"Identity-Addresses","level":2},{"id":"compatibility","title":"Compatibility","level":2},{"id":"example-of-an-auth-interaction","title":"Example of an auth interaction","level":2},{"id":"disadvantages","title":"Disadvantages","level":2},{"id":"reference-implementation","title":"Reference implementation","level":2},{"id":"references","title":"References","level":2},{"id":"acknowledgements","title":"Acknowledgements","level":2},{"id":"copyright","title":"Copyright","level":2}],"history":{"totalCommits":11,"firstCommit":"2016-05-18T09:19:24+02:00","lastUpdated":"2025-10-08T14:59:36-07:00","events":[{"sha":"24e96e870fffaa257b465ce1f0370c14aac588e8","date":"2025-10-08T14:59:36-07:00","author":"Murch","message":"process: Created ↦ Assigned","url":"https://github.com/bitcoin/bips/commit/24e96e870fffaa257b465ce1f0370c14aac588e8","kind":"edit"},{"sha":"5207ef92a52d0b8902895b0dbb40823a4d698ec9","date":"2025-04-11T20:08:17-07:00","author":"Murch","message":"process: Author ↦ Authors","url":"https://github.com/bitcoin/bips/commit/5207ef92a52d0b8902895b0dbb40823a4d698ec9","kind":"edit"},{"sha":"a233bde4af52c6a11269e2e6dd9707abce441ffe","date":"2025-04-11T18:19:21-07:00","author":"Murch","message":"process: Standards Track ↦ Specification","url":"https://github.com/bitcoin/bips/commit/a233bde4af52c6a11269e2e6dd9707abce441ffe","kind":"edit"},{"sha":"66defbdc03ad64ccddfd373e1c59af9a41ab990f","date":"2025-04-11T18:11:55-07:00","author":"Murch","message":"process: Deferred/Obsolete/Rejected/Replaced/Withdrawn ↦ Closed","url":"https://github.com/bitcoin/bips/commit/66defbdc03ad64ccddfd373e1c59af9a41ab990f","kind":"status"},{"sha":"29312fbe912a0125ad70a95d61a3734692a25de6","date":"2024-07-17T21:46:35+02:00","author":"Jonas Schnelli","message":"BIP150: Deferred","url":"https://github.com/bitcoin/bips/commit/29312fbe912a0125ad70a95d61a3734692a25de6","kind":"edit"},{"sha":"f1485fdb5f1875bf96d5ecdcfa27b275ac45ef6a","date":"2017-08-24T23:50:20+12:00","author":"MeshCollider","message":"Fixing spelling in BIP 150","url":"https://github.com/bitcoin/bips/commit/f1485fdb5f1875bf96d5ecdcfa27b275ac45ef6a","kind":"edit"},{"sha":"d9396155350b16b098a0d0b5ec10da80ebd96d5f","date":"2017-03-14T23:27:57+00:00","author":"Luke Dashjr","message":"Propagate summary tone of BIP Comments to their applicable BIP preambles","url":"https://github.com/bitcoin/bips/commit/d9396155350b16b098a0d0b5ec10da80ebd96d5f","kind":"edit"},{"sha":"959fecc15bdad070afa63455468b1dba54655fa6","date":"2016-11-30T09:47:31+00:00","author":"Luke Dashjr","message":"Promote BIP 2 Draft->Active, and implement it","url":"https://github.com/bitcoin/bips/commit/959fecc15bdad070afa63455468b1dba54655fa6","kind":"status"},{"sha":"72f18918a8ae655212ea2700b30f0dc4d758b843","date":"2016-11-30T09:45:33+00:00","author":"Luke Dashjr","message":"Promote BIP 123 Draft->Active, and implement it","url":"https://github.com/bitcoin/bips/commit/72f18918a8ae655212ea2700b30f0dc4d758b843","kind":"status"},{"sha":"ffa155e452080b0820a6354081d0ef895c498000","date":"2016-08-16T11:56:22-05:00","author":"Bryan Bishop","message":"peer authentication bip draft editing","url":"https://github.com/bitcoin/bips/commit/ffa155e452080b0820a6354081d0ef895c498000","kind":"edit"},{"sha":"5e49486769ec7dddb4689bdf270e587a91d74c0c","date":"2016-05-18T09:19:24+02:00","author":"Jonas Schnelli","message":"Add BIP150 (Peer Authentication)","url":"https://github.com/bitcoin/bips/commit/5e49486769ec7dddb4689bdf270e587a91d74c0c","kind":"edit"}]}}