Antminer X9
Monero ASIC Miner
1000KH
HASHRATE
2.47W/KH
EFFICIENCY
2470W
POWER
£857.29
EST. MONTHLY
206
DAYS
EST. ROI
This guide explains BIP 47 Reusable Payment Codes for Hierarchical Deterministic Wallets in plain English. It covers the problem behind the BIP, why it matters and whether the proposal is part of Bitcoin today.
TL;DR
- What it is: BIP 47 lets a wallet publish one reusable payment code while deriving a different Bitcoin address for each payment relationship. A notification transaction conveys a blinded code, after which sender and recipient derive shared-secret-based addresses without further public coordination.
- Why it matters: BIP 47 reduces address reuse while retaining a reusable identity, but notification, metadata and recovery complexity remain. Safe use requires compatible versions, private chain scanning and a tested restoration of contact and index state.
- Current position: Where the proposal is closed, keep historical software isolated from production.
BIP 47 Reusable Payment Codes in simple English
BIP 47 Reusable Payment Codes: Version one and version two differ in recommended monitoring assumptions, and version three or later belongs to the external RFC record.
Simple example
A node operator is checking BIP 47 Reusable Payment Codes. A version-one code serialises a version, feature bits, compressed public key, chain code and reserved bytes before Base58Check encoding.
Key terms in plain English
- BIP:
- Bitcoin Improvement Proposal: a document describing a proposed rule, standard or process. Its status must be checked separately.
- Node:
- A computer running Bitcoin software that checks data and communicates with other peers.
Payment code structure
A version-one code serialises a version, feature bits, compressed public key, chain code and reserved bytes before Base58Check encoding. It begins with a recognisable prefix but is not a payment address. Publishing it reveals a stable identity handle while intended payments go to separately derived addresses.
Notification transaction
The sender pays the recipient’s notification address and embeds a blinded payment-code payload. A designated input exposes a public key used with an elliptic-curve shared secret to mask or recover the code. The recipient monitors notification activity and derives the sender-specific channel after validating the transaction form.
Per-contact address derivation
Both parties combine their private material with the other payment code’s public keys to derive matching child addresses. The sender chooses the next outgoing index and the recipient watches the corresponding incoming chain. Lost contact metadata or index state can make discovery slow even when the root seed survives.
Privacy properties and leaks
Ordinary payment addresses need not be reused, but the notification transaction creates an observable event and spending its change can link activity. Publishing one code associates future contacts with a stable identity. Network lookups, notification monitoring and public explorers can add further metadata leakage.
Version and capability boundaries
Version one and version two differ in recommended monitoring assumptions, and version three or later belongs to the external RFC record. A wallet claiming BIP 47 support may implement only part of the family. Payment codes, features, notification scripts and network must all be negotiated or documented.
Cold storage and recovery
An online watch system can detect notifications but may need an offline device to recover codes and generate large public-key lookahead batches. Recovery scans notification transactions, reconstructs contacts, then scans derived addresses. Seed-only restoration may miss labels, outgoing channel state and application metadata needed for efficient discovery.
How specialists test it
Developers test the proposal with made-up data on an isolated test network. They check normal cases and deliberately invalid cases. Different implementations should reach the same result before anyone relies on the proposal.
Frequently asked questions
What is the main point of BIP 47 Reusable Payment Codes?
BIP 47 Reusable Payment Codes: Version one and version two differ in recommended monitoring assumptions, and version three or later belongs to the external RFC record.
For BIP 47 Reusable Payment Codes, what should a beginner know about payment code structure?
A version-one code serialises a version, feature bits, compressed public key, chain code and reserved bytes before Base58Check encoding.
For BIP 47 Reusable Payment Codes, what should a beginner know about notification transaction?
The sender pays the recipient’s notification address and embeds a blinded payment-code payload.
For BIP 47 Reusable Payment Codes, what should a beginner know about per-contact address derivation?
Both parties combine their private material with the other payment code’s public keys to derive matching child addresses.
Conclusion
BIP 47 reduces address reuse while retaining a reusable identity, but notification, metadata and recovery complexity remain. Safe use requires compatible versions, private chain scanning and a tested restoration of contact and index state.
Primary sources
Check the current specification status and the documentation for the exact implementation you operate before moving production funds or changing a mining node.
Join the ASIC Mining Discussion
Members can read and join the discussion
Log in to read comments from other miners. Create a free account if you would like to ask a question or share your experience.
Membership helps us protect the discussion from spam and keep answers useful.