A Bitcoin node can show an encrypted connection while the transactions it relays remain publicly visible. To understand that status, start with the connection itself: which two computers are communicating, and who else could observe their exchange?
BIP324 is Bitcoin’s version-two peer-to-peer transport protocol. Its protection applies to traffic between supporting peers. It is useful to node operators, but should never be interpreted as a transaction-anonymity setting. BIP324’s scope
The link between two nodes
Bitcoin’s peer-to-peer network carries blocks and transactions. A full node checks incoming data and can relay it onward. Receiving a transaction from a particular computer therefore does not, by itself, prove that the computer’s operator created that payment. Bitcoin’s peer-to-peer guide
Think of a hypothetical path from node A through node B to node C. A protection negotiated between A and B applies to that connection. B remains a participant in the exchange and handles the information it receives; the next connection has its own transport status. This illustration follows the network’s peer-by-peer relay model.
Bitcoin Core 26.0 introduced experimental BIP324 support, initially disabled by default. Its release notes explicitly described negotiation separately for each supporting peer, while retaining version-one connections. Core 26.0 release notes
Core 27.0 enabled version two by default. Its manual connection options also began following that setting, with a retry using version one if the attempt failed. Those historical changes explain why enabling the feature and verifying every connection are separate tasks. They are not measurements of how much of today’s network uses encryption. Core 27.0 release notes
What a passive observer loses
BIP324 encrypts message content and produces a byte stream designed to look random to passive observers. This makes straightforward inspection and identification of Bitcoin traffic harder. Timing and traffic patterns can still reveal information. BIP324’s goals and limitations
The protocol does not authenticate a peer’s identity. Active attackers can attempt interception or downgrades, or operate a peer themselves. Operators of a deliberate connection can compare transport versions and session identifiers through a trusted channel to help detect interference. BIP324’s active-attack discussion
Validation remains a separate responsibility. The peer-to-peer guide describes nodes checking blocks and transactions before relaying them. An encrypted route does not make the arriving data automatically valid. The practical inference is to keep transport checks and node-validation checks as distinct parts of an operational review. Network validation model
The public ledger and the wallet server
Bitcoin’s published ledger still records transactions, and outside information can link activity to people. Bitcoin.org also warns that transaction-relay IP addresses can be logged, while emphasizing that a relaying node may be mistaken for the originator. Transport encryption does not erase information already published on-chain or identify which relay actually originated a payment. Bitcoin.org’s privacy guidance
A wallet’s connection to its information provider deserves its own review. Sparrow’s documentation warns that a public server can learn the wallet’s balance and, through a direct connection, its IP address. BIP324 on a node’s peer connections does not change what a separate wallet server learns from the queries it receives. This is a practical inference from the two connections’ different roles. Sparrow’s server-privacy guidance
Tor addresses another part of the picture. Bitcoin Core documents proxy and onion-service arrangements for connecting through Tor. Using those arrangements requires attention to the actual network configuration; a version-two transport label alone does not establish that a connection travels through Tor. Core’s Tor documentation
Read the actual connection state
Bitcoin Core’s read-only getpeerinfo command reports each connected peer. In the version 31.0 reference, transport_protocol_type distinguishes detecting, v1 and v2. Detecting means the software has not yet established which transport applies; v1 is plaintext and v2 is BIP324 encrypted transport. Peer-status reference
The same response reports the network separately, such as IPv4, IPv6 or onion, along with a session_id for a version-two connection. Keeping those fields separate helps answer two different questions: how the peer is reached, and how the Bitcoin messages are transported. A session identifier is not a named identity certificate for the remote operator. Documented peer fields
For an operator’s review, record the software version, relevant configuration and the observed connection states. If a connection unexpectedly uses version one, investigate the settings and the other peer’s capabilities before drawing a conclusion. A single snapshot describes the peers connected at that moment, rather than every future connection.
For a useful privacy review, sketch the actual communication path. Identify the wallet, any service it queries, the node and its peers. Then ask what each participant learns and which observations remain possible elsewhere. This keeps a reassuring status label tied to a specific, testable claim.