Bitcoin Core’s silent-payments work passed another implementation checkpoint on October 7, when developers merged a correction to the way its new BIP 352 code extracts public keys from certain older-style transaction inputs. The change follows a September 23 merge of foundational silent-payment logic. Together, they show both progress and the detailed compatibility work involved in adding a privacy feature. October 7 correction and September 23 implementation.
For wallet users, the important boundary is the work’s scope. As checked on October 10, the separate Bitcoin Core sending pull request remains open, while the receiving pull request is still a draft. Those statuses do not establish a released, complete wallet feature. This is an analysis of development progress, rather than an announcement that every Bitcoin Core user can now receive silent payments. Sending work and receiving work.
What a reusable payment address can improve
Silent payments address a familiar privacy problem: a person wants to publish one lasting payment destination without directing every payment to the same publicly identifiable on-chain address. Under BIP 352, a sender uses the recipient’s published silent-payment address and information tied to the transaction’s inputs to derive a fresh output. The recipient discovers that output by scanning. There is no separate on-chain notification payment. BIP 352.
Consider a hypothetical developer who accepts tips through a public website. A conventional address reused for every tip gives observers a convenient place to follow receipts. A silent-payment address is designed to remove that particular link between the published destination and individual payment outputs. The recipient can leave the published address in place while compatible senders create different outputs.
That does not make Bitcoin amounts secret or erase the rest of a transaction’s history. Bitcoin’s ledger remains public, and information disclosed elsewhere can still help identify activity. Publishing a screenshot of a payment, for example, may defeat a privacy benefit that address handling alone was intended to provide. Bitcoin.org’s privacy guidance emphasizes both blockchain transparency and the risks of revealing transaction information. Privacy guidance.
The cost moves into discovery
The recipient must find payments without being handed a conventional address to watch for each one. BIP 352 therefore requires scanning eligible transaction data. Its specification describes full-node scanning as generally feasible, while privacy-preserving light-client support remains more challenging. The practical question for a wallet developer is how to make discovery work reliably without imposing unacceptable bandwidth or processing demands. Scanning design.
An important building block already exists in libsecp256k1 version 0.8.0, whose release notes list a silent-payments module supporting sending and full-node scanning. That is a cryptographic library capability. Applications still have to integrate it into their transaction and wallet behavior. A component’s availability is useful evidence of progress, but it is not evidence that a particular wallet has shipped a polished receiving experience. Library release.
Why the October correction matters
The October 7 correction concerns P2PKH inputs, an older Bitcoin transaction type. The pull request describes a crafted script that could make the new extraction routine identify the wrong public key. Its fix searches the script’s pushed data for the key matching the previous output’s public-key hash, rather than relying on the earlier dummy-signature-checking approach. Correction details.
This is significant because both sides must derive the same payment destination from transaction data. My reading is that compatibility work of this kind is part of making the feature dependable across valid transactions, not merely making a demonstration succeed. The report should also be kept in proportion: the pull-request author said the existing silent-payment implementations they had examined were unaffected. That observation is narrower than a universal security assurance.
What to watch next
Bitcoin Core’s integration tracker separates base protocol code, wallet sending, wallet receiving and light-client infrastructure. That division offers a more useful progress checklist than a single “supported” label. The sending proposal includes coin-selection and fee-bumping considerations; the receiving proposal includes wallet scanning and dedicated wallet-management changes. These are proposed integrations whose final behavior can change during review. Integration tracker, sending proposal and receiving proposal.
Before adopting any wallet’s implementation, a reader should check that specific wallet’s released documentation for sending, receiving and recovery support. Ask how payments are discovered after time offline and what resources that process requires. For now, the defensible conclusion is concrete but limited: Bitcoin Core has merged important underlying logic and a follow-on correctness fix, while separate wallet integration work remains visible and unfinished. That is meaningful progress worth tracking without turning it into a release promise.