I started working on this subject after reading the discussion in
0xB10C/project-ideas#12.
The question that interested me was relatively simple: after BIP324 removes the
cleartext Bitcoin message framing, what can a passive observer still learn from
the traffic?
BIP324 prevents an observer from directly reading commands such as inv, tx,
and block. However, TCP behavior, payload sizes, traffic direction, timing,
and encrypted bursts remain visible. I built a controlled Warnet experiment to
explore how useful those signals are, without decrypting the traffic or running
another Bitcoin node to observe the protocol directly.
The complete write-up is available here:
Passive Traffic Analysis of Bitcoin P2P v2
The experiment uses two repositories. The
bip324-traffic-lab
project generates reproducible Warnet traffic, background noise, PCAPs, Bitcoin
Core logs, and metadata. The
bip324-traffic-analysis
project processes those captures and evaluates the resulting candidates.
Approach
The analysis combines characteristics of the initial BIP324 TCP exchange with
packet sizes, direction, inter-packet gaps, and bursts observed at different
time scales. TCP sequence numbers are used to avoid counting retransmitted
payload twice. The detector also looks for temporal sequences that may resemble
transaction relay and for propagation evidence appearing across independent
flows.
Candidate generation is based on captured traffic. In the Warnet experiment,
an IP map first limits the evaluation to the controlled lab endpoints, but it
does not tell the classifier whether a retained flow is Bitcoin or noise.
Bitcoin Core logs and simulation metadata are only used afterward for
validation and reproducibility.
Current observations
The current run contains 632 retained lab flows: five labeled BIP324 flows and
627 background-noise flows.
Inside the common PCAP/log interval, the handshake heuristic found all five
reference handshakes. When all retained lab flows were considered, it also
classified the single obfs4 flow as a handshake candidate.
In the table below, TP means that a Bitcoin flow was detected, FP is a noise
flow incorrectly selected, FN is a missed Bitcoin flow, and TN is a noise flow
correctly rejected. Precision measures how many selected flows were correct,
recall measures how many reference Bitcoin flows were found, and F1 summarizes
both values.
| TP | FP | FN | TN | Precision | Recall | F1 |
|---|---|---|---|---|---|---|
| 5 | 1 | 0 | 626 | 83.33% | 100.00% | 90.91% |
This is still a small controlled sample. The obfs4 result provides one concrete
case in which the current heuristic fails, but a single flow is not enough to
estimate a general false-positive rate for obfs4.
The transaction-related results were mixed. The transaction-relay sequence
reached 71.80% measured recall and 61.07% F1, while still producing 292
false positives. INV and TX-like evidence had moderate results, whereas
request-like detection reached only 24.41% recall.
Block detection was considerably weaker. Block arrival, compact-block arrival,
and propagation-wave detection all had recall below 14%. One difficulty is
that Bitcoin Core logs contain observations from several nodes and peers, while
a passive burst may contain or aggregate more than one encrypted message.
Consequently, the validation is an operational reference rather than
packet-level ground truth.
These results describe the current detector and this particular Warnet run.
They do not show that BIP324 application messages can be identified reliably
from traffic metadata.
Randomized listening ports
I also implemented an experimental Bitcoin Core option for selecting a random
high listening port at startup:
Randomized P2P port implementation
When started with -port=0, the node selects an available port between 49152
and 65534, persists it after startup, advertises it through Bitcoin Core’s
existing local-address mechanism, and reuses it on later restarts.
The intention is to reduce the usefulness of the default listening port as an
initial traffic-selection signal. The implementation remains experimental and
would benefit from further review, especially regarding configuration, address
advertisement, reachability, and operational behavior.
Comments on this research would be very helpful. I would particularly
appreciate ideas for detecting other events, improving the heuristics already
tested, or approaching the same problem differently. Feedback on the
randomized-port implementation and its practical trade-offs would also be
welcome.