Revisiting Elliptic++ for Bitcoin Forensics: Feature Reconstruction and Leakage-Resistant Evaluation

CCS Concepts • Applied computing → Forecasting; • Security and privacy → Intrusion/anomaly detection and malware mitigation; Database activity monitoring.

Introduction

The pseudonymous nature of cryptocurrency transactions makes them attractive for illicit use. In 2025, the volume of cryptocurrency involved in identified illicit activities was estimated to be at least $154 billion, more than double the $57.2 billion recorded in 2024 [6]. On top of pseudonymity, a public and decentralised ledger further encourages illicit use by removing the need for a trusted intermediary among transacting parties, though it simultaneously makes that use traceable. Publicly accessible transaction data allow forensic analysts to reconstruct flows of illicit funds and study criminal characteristics [7, 12, 22, 35]. Among all cryptocurrencies, Bitcoin has caught particular attention from academic researchers and empirical analysts, given its dominating market share. Foley et al. [10] estimate that approximately a quarter of Bitcoin users and half of its transactions were associated with illegal activity between 2009 and 2017. They also show that this illegal share declined over the period as mainstream adoption grew.

In practice, forensic analysts face far more candidate transactions and addresses than can be examined manually, creating an operational need for detection tools that flag suspicious activities. Recent literature treats this forensic detection as a supervised classification task, releasing labelled datasets of Bitcoin transactions or addresses, and benchmarking detection tools and algorithms on them. The Elliptic dataset [38], at its release the largest publicly available labelled Bitcoin transaction dataset, was made public jointly by the MIT-IBM Watson AI Lab and Elliptic, a blockchain intelligence firm that partners with UK government agencies¹. Its labels are produced by Elliptic’s investigators, who attribute transactions to known licit and illicit entities, such as exchanges, ransomware operators, and scams, through a heuristics-based reasoning process [38]. With this provenance, the Elliptic dataset is commonly used as ground truth in the literature. Subsequent datasets have extended the labels to the address level (Elliptic++) [9] and to subgraphs of a much larger transaction graph (Elliptic2) [5].

On this family of Elliptic datasets, the reported detection performance is generally high, yet recent re-evaluations show that such performance advantages need not reflect out-of-sample detection, due to information leakage [15, 21, 31]. A forensic detector must flag entities that appear after it is trained, so its evaluation must respect that order. Such inflated performance is also reported for malware detection in the security literature [3, 27].

There are two main channels through which the leakage can enter: the split and the feature channels. The first one is a randomised split disregarding time, in which training and test samples can come from the same periods [3, 13, 27]. The second one is a problematic feature computation process, in which features are computed with information from the test period and consequently violate the legitimacy rule of Kaufman et al. [14]². Elliptic’s transaction-level split follows time, but Šafář et al. [31] reverse-engineered its anonymised transaction-level features and found that most of the nominally local features are aggregates of the transacting parties (addresses), computed with information that includes the test period. These transaction-level features are therefore leaky, through the feature channel. Moreover, because these address-aggregates are identical for every transaction that involves the same address, training and test transactions are linked through shared addresses, a further channel identified by Šafář et al. [31]. They argue that because the transactions are labelled by association between transactions’ input addresses and the known entities controlling them, a classifier can then inflate its performance by recognising those addresses rather than by detecting illicit activity.

Both the Elliptic and Elliptic++ datasets are widely used in Bitcoin forensics research. As of 13 October 2026, Google Scholar lists 1,154 citations of Weber et al. [38] and 205 of Elmougy and Liu [9]. The leakage problem may therefore affect a large body of published and ongoing work, which calls for a solution. In Elliptic, transactions are labelled as illicit, whereas in Elliptic++, labels are assigned to addresses, which may serve as inputs to many transactions. For transaction-level labelling, Šafář et al. [31] provide a pipeline to allow for leakage-resistant⁴ transaction-level feature construction. For transaction-level model training, illicit addresses can appear in both the training and test periods. To close this leakage channel, Šafář et al. [31] suggest shifting the analysis unit from transaction to address, because each address then appears only once. Focusing on addresses is also aligned with how security research and law enforcement treat illicit activity on Bitcoin: Meiklejohn et al. [22] trace illicit funds by clustering addresses into the entities that control them, ransom payments are traced and measured through the addresses of ransomware operators [12, 25], labelled datasets for ransomware detection are built at the address level [1], and sanctions designate specific Bitcoin addresses [36].

Elmougy and Liu [9] took the pioneering step when they released Elliptic++, the first address-level extension of Elliptic, on which a random forest (RF) reaches an F1 of 0.845 on the illicit class. However, the shifting of the analysis unit from transaction to address does not solve the leakage problem. In the Elliptic++ dataset, the released split is positional rather than temporal and its address-level features are lifetime summaries of each address’s full history. This paper addresses both. We (1) recompute the Elliptic++ address-level features in a leakage-resistant way and share the exact definitions of them, (2) quantify the negative effect of leakage by comparing classification performance under leaky and leakage-resistant settings, (3) release the recomputed features and the construction code⁵ to encourage further re-evaluation of results built on Elliptic++ under leakage-resistant settings.

The Leakage Problem

Current studies and their findings

Empirical studies of Bitcoin began with the public transaction graph itself. Early work parsed the full ledger to describe its network structure [17, 30] and clustered addresses into the entities that control them [22]. As labelled data became available, the focus moved from describing the network to detecting illicit activity in it, a task now often described as supervised classification. Two benchmark datasets dominate this field, the Elliptic dataset [38] and its address-level extension Elliptic++ [9].

The original Elliptic dataset [38] provides a set of transactions with licit or illicit labels and attaches features to each transaction. These include local features (e.g., number of inputs and outputs, transaction volume) and aggregated features that summarise the same local information over the one-hop neighbouring transactions (maximum, minimum, standard deviation, and correlation coefficients). However, due to intellectual property concerns, these features are anonymised as numerical indices. Elliptic++ [9] extends the original dataset in two directions. Firstly, at the transaction level, 17 additional features are appended, derived from the addresses participating in each transaction. Furthermore, over 822,000 wallet addresses are recovered from the original Elliptic transactions, each described by 55 summary statistics of local transaction activity. These address-level features are released with verbal descriptions but without exact definitions, so their computation cannot be reproduced from the release alone.

Methodological work in this literature focuses on two families, graph neural networks (GNNs), which learn node representations by aggregating information along graph edges, and tree-based ensembles. The original Elliptic study applied graph convolutional networks (GCN) [16] alongside random forests. Subsequent work introduced temporal adaptations (EvolveGCN) [26], attention-based architectures (GAT) [37], models capable of generalising to unseen nodes (GraphSAGE) [11], unsupervised structural discrimination [20], heterogeneous graph neural networks with metapath-based aggregation [33], subgraph representation learning [5], and heterogeneous graph transformers [28]. Reported accuracy across these models is generally high. However, a recurring result is that tree-based models remain hard to beat. For example, Shaizat and Mus-siraliyeva [32] show that a random forest (RF) fitted on a subset of Elliptic and Elliptic++ features selected by a specialised search algorithm is competitive with more advanced graph models. In the Elliptic++ study, Elmougy and Liu [9] show that RF outperforms logistic regression alongside other tree- and GNN-based models. Similarly, Nguyen et al. [23] show that both RF and extreme gradient boosting baselines slightly outperform their proposed SAGE-FIN model. RF is thus the strongest model reported on Elliptic++, and it is the model whose performance we re-evaluate under leakage-resistant settings in Section § 4.

Recent work has raised concerns about the evaluation settings behind the high accuracy reported for Bitcoin classifiers [15, 21, 31]. Both leakage channels introduced in Section § 1 are named in this literature. Through the split channel, much of the literature evaluates on random or quasi-random splits, in which samples from the same time periods fall on both sides of the train/test split [9, 23]. Samples drawn from the same blockchain regime share similar feature characteristics, so a classifier can inflate its performance by recognising the current regime rather than by detecting illicit activity in a later one. Through the feature channel, static features computed over the full sampling period contain post-cutoff information by construction, and this leakage persists even under a temporal split. Both channels cast doubt on the reported performance under out-of-sample detection.

The transaction-level Elliptic literature has begun to treat this as a major concern. Maganti [21] compares evaluation settings directly across matched runs, holding other configurations (architecture, optimiser, loss, and seed) fixed. The study surprisingly finds that GraphSAGE [11] underperforms severely under a leaky setting compared to a leakage-resistant one⁶. Leaking the graph structure in the test period to the model during training actively degrades performance. Maganti [21] also shows that an RF on raw features beats every graph model tested. In contrast, other recent models evaluated on Elliptic’s temporal split [4, 8, 19] do not isolate how much of their reported performance depends on the evaluation setting. Khaleghpour and McKinney [15] approach the problem from the feature side, proposing a general guideline for leakage-resistant feature computation⁷ for temporal transaction networks and demonstrating it on the original transaction-level Elliptic dataset. They construct graphs and compute features using only edges observed up to each time step. Under a strict temporal split, an RF classifier reaches a ROC-AUC of 0.85 and an average precision of 0.54, but this performance comes almost entirely from Elliptic’s original transaction features. The leakage-resistant graph features alone reach an average precision of only 0.05, and adding them to the original features leaves it unchanged. Working earlier in the same direction, Nicholls et al. [24] similarly found that an RF trained on raw features outperforms several GNN baselines once the data split respects chronological order. Concurrently, Šafář et al. [31] audit the construction of Elliptic itself. They reverse-engineer most of the features, and show that some features are computed once with information that includes the test period, that these features link training and test transactions through shared addresses, and that the normalisation procedure used statistics of the whole dataset. They also note that the address-level information added by Elliptic++ was already largely present among Elliptic’s local features. This overlap was difficult to see at the time, since Elliptic’s features are released without clear definition or computation process. As a solution to improve Elliptic, they propose leakage-resistant features and splits that share no addresses, and release a tool for constructing such datasets. Their finding also limits what some transaction-level re-evaluations can show. Maganti [21] and Khaleghpour and McKinney [15] both still use Elliptic’s original features, which contain the leaky address aggregates, so neither a strict inductive protocol nor leakage-resistant graph features layered on top of them makes the whole setting leakage-resistant by themselves. Together, these studies advocate leakage-resistant evaluation design and show that results reported on the Elliptic family need to be re-evaluated under it.

Same as for studies utilising the Elliptic dataset, also for Elliptic++ based studies, frequently a positional split is utilised, leading to high performance metrics [9, 23, 34]. However, only a temporal split would allow for a leakage-resistant evaluation. The strong depreciation in performance when switching from a positional to temporal split reported for the Elliptic dataset, calls for a re-evaluation of performance metrics achieved under positional split in the Bitcoin Forensics literature.

In summary, leakage-resistant design has been advocated for the transaction-level data [15, 31], whereas the address level, the natural next step given the leakage channel of repeated addresses identified by Šafář et al. [31], has seen neither a leakage-resistant reconstruction of its features nor a re-evaluation of its reported performance. This paper provides both for the address-level Elliptic++.

Public ledger data

This paper takes Elliptic++ as the starting point, which supplies the list of labelled addresses, the licit and illicit labels, the Elliptic time step of each address, and the values of 55 summary features of local transaction activity.

An address-level evaluation is leakage-resistant when both leakage channels of Section 1 are closed. Closing the split channel requires a temporal split, with a cutoff placed on the time line of the blockchain so that every training address is observed before the test period starts. Closing the feature channel requires that each address’s features be computed only from its transactions up to its observation point, which in turn requires the individual transactions of the address, their amounts, and the blocks in which they were confirmed. The second requirement also presupposes exact feature definitions, since a feature can only be recomputed up to a cutoff if its definition is known. Once these conditions hold, the leakage channel of repeated addresses, identified by Šafář et al. [31], is closed as well. Each address enters the sample once, on one side of the split, and its features summarise its own activity rather than aggregates shared with other samples.

Elliptic++ does not meet these requirements on its own. The time steps in its wallet file suffice to place each address on one side of a temporal split, but the released split is positional, and two properties of the Elliptic family prevent the features from being recomputed up to a cutoff. First, the underlying transactions are anonymised. The original Elliptic dataset releases its transactions as numerical indices rather than on-chain identifiers (i.e. transaction hashes), and Elliptic++ inherits this, releasing the 55 feature values but not the per-transaction amounts and block heights from which they are computed. A leakage-resistant recomputation, which restricts each address to the transactions observed at or before a temporal cutoff, requires those raw transactions together with their block heights.

Second, the features are described but not defined. Elliptic++ gives a verbal description of each of the 55 features, yet it does not provide their exact mathematical form or the per-transaction conventions needed to reproduce them on-chain. The verbal descriptions in what follows are taken from Elmougy and Liu [9], but the precise mathematical definitions, including the per-transaction conventions and the handling of edge cases such as self-transfers and fee attribution, are formalised in this paper and listed in full in Section A.

Two further public datasets supply what is missing, a full Bitcoin ledger and a deanonymisation map. The ledger data come from the Bitcoin transaction network deposited by Kondor et al. [18], a full parse of the Bitcoin blockchain extracted with a modified Bitcoin Core client and originally built to study the structure of the Bitcoin transaction network [17]. The deposit holds several releases, and we use the 2020 release, which covers every transaction up to February 2020 and therefore the whole Elliptic window from January 2016 to October 2017. Blocks, transactions, and addresses carry integer identifiers, and the release is organised as relational tables: a block table with timestamps, a transaction table that places each transaction in its block, input and output tables that record the address and the amount of every transaction input and output, and dictionaries that map the integer identifiers back to on-chain transaction hashes and address strings. The release lists 609,963,452 addresses and about 1.22 and 1.33 billion transaction inputs and outputs. These tables provide exactly what the Elliptic family withholds. The amount each address sends to or receives from a transaction determines the value features, and the block of each transaction determines the timing features and places the transaction before or after the cutoff, so that each address’s history can be truncated at its observation point, which closes the feature channel.

To recompute the Elliptic++ features in a leakage-resistant manner, we have to link the anonymised Elliptic transactions with the Kondor ledger data. We follow the procedure of Elmougy and Liu [9] and use the public deanonymisation map released on Kaggle [2]. This map links each anonymised Elliptic transaction identifier to its on-chain transaction hash. Its author located the Elliptic features for transaction volume, fee, and the numbers of inputs, outputs, and unique addresses, and matched them against the blockchain using the known collection window and graph structure of the dataset [31]. The map covers 202,804 of the 203,769 Elliptic transactions (99.53%), and every mapped transaction is found in the Kondor ledger. Because Elliptic++ reuses Elliptic’s transaction identifiers, the map joins the Elliptic++ addresses and time steps to Kondor’s transactions and blocks. It restricts the ledger to the Elliptic transactions, so that features are recomputed over the same transaction set as the original construction, and it assigns every Elliptic time step its range of blocks, from which the cutoff block of the temporal split is read. The map closes no leakage channel on its own, but without it neither the feature channel nor the split channel could be closed at the address level.

Leakage-Resistant Construction

This section describes how the Elliptic++ files, the deanonymisation map, and the Kondor ledger are joined into a single address-level dataset with a temporal split (§ 3.1), and how the 55 features are recomputed in a leakage-resistant way (§ 3.2). The validation of the recomputed features against the released values is shown later in § 4.2. Figure 1 traces the full pipeline. Every step is implemented as SQL in DuckDB [29], which queries Parquet files directly without loading them into memory, with PyArrow and pandas used for file conversion and bookkeeping. The pipeline was executed on a Snellius⁸ compute node with 192 threads and 336 GB of memory.

Linking Elliptic++ to the ledger

From the Kondor 2020 release [18], six compressed files are used, namely the address dictionary, the transaction-hash dictionary, the block table, the transaction table, and the input and output tables. The block table records the height, hash, timestamp, and number of transactions of each block. The transaction table records the identifier of each transaction, its block, and its numbers of inputs and outputs. The output table records, for each transaction output, its transaction, its position, the receiving address, and the amount in satoshis, and the input table records the same for each input together with the earlier output it spends. The two largest tables, the inputs and the outputs, hold 1.22 and 1.33 billion rows, and the address dictionary holds 609,963,452 addresses.

The labels enter through the addresses. The 265,354 labelled addresses of Elliptic++, of which 14,266 are illicit and 251,088 licit, are matched to the Kondor address dictionary by an exact left join on the address string. The join matches all 14,266 illicit and 251,086 licit addresses, resulting in a class imbalance of 5.4% illicit share. The remaining two licit addresses cannot be matched because the Elliptic++ release lists them as truncated strings rather than complete Bitcoin addresses, and they are dropped. Each matched address thereby receives its Kondor address identifier, through which all of its inputs and outputs in the ledger can be retrieved.

The transactions enter through the deanonymisation map [2], which provides transaction hashes for 202,804 of the 203,769 Elliptic transactions. The remaining 965 have no entry in the map and therefore, following the approach of Elmougy and Liu [9], they are not covered in the analysis. The 202,804 pairs of Elliptic transaction identifier and transaction hash in the map are joined in three steps: from the hash to the Kondor transaction identifier through the hash dictionary, from the transaction identifier to its block through the transaction table, and from the block to its timestamp through the block table. All 202,804 transactions are found in the ledger. Every later feature computation is restricted to these transactions, matching the transaction set over which the Elliptic++ features were originally computed.

The same procedure identifies the block range for each Elliptic time step. Elliptic++ aggregates transactions to one of 49 time-dependent samples, and joining these assignments to the Kondor dataset through the deanonymisation map gives, for each time sample, its first and last block, and their timestamps. Table 1 reports the resulting training and test periods. The Elliptic window runs from block 391,200 on 1 January 2016 to block 487,975 on 2 October 2017, and the cutoff is set at the last block of time step 34, block 457,734, which ends the training period on 18 March 2017.

Period	Blocks	Dates	Bitcoin txs	Elliptic txs	Elliptic addr. (illicit)
Training	391,200–457,734	2016-01-01 – 2017-03-18	104,577,292	135,864	172,903 (9,377)
Test	459,744–487,975	2017-03-31 – 2017-10-02	49,383,660	66,940	92,449 (4,889)
Window	391,200–487,975	2016-01-01 – 2017-10-02	157,574,858	202,804	265,352 (14,266)

Note: Training covers Elliptic time steps 1 to 34 and testing time steps 35 to 49; the cutoff is the last training block, 457,734. Bitcoin transactions are counted from the Kondor block table and include coinbase transactions; the window also includes the 2,009 blocks between the two periods, which contain no Elliptic transaction. Elliptic transactions are those recovered by the deanonymisation map. Addresses are assigned to a period by their first appearance.

Feature recomputation

The 55 features are recomputed from the Elliptic transactions, following the verbal descriptions of Elmougy and Liu [9]. As in the original construction, they summarise each address’s activity within the Elliptic transactions rather than its full history on the chain. The computation has two stages, a per-transaction table that records the stake of each labelled address in every transaction it takes part in, with 367,517 rows, and an aggregation of that table to one row per address.

The per-transaction table records, for each labelled address and each transaction it takes part in, the amount the address contributes as inputs and the amount it collects as outputs. An address that spends coins and receives change in the same transaction appears on both sides, so its stake is netted. The net amount sent is the excess of its inputs over its outputs. The net amount received is the excess of its outputs over its inputs, and the amount transacted is the absolute difference between the two. A transaction counts as a sending transaction of the address if the net amount sent is positive, and as a receiving transaction if the net amount received is positive. The fee of the transaction is the excess of its total input over its total output, and the address is attributed a share of it in proportion to the larger of its input and output amounts, relative to the total input of the transaction. All amounts are in bitcoin, and every row carries the block of its transaction.

Each of these five per-transaction quantities, the amounts transacted, sent, and received, the fee, and the fee share, is reduced over the transactions of an address to five summary statistics: the total, minimum, maximum, mean, and median, which gives 25 value features. The remaining 30 features describe activity, timing, and counterparties. The three transaction counts record all transactions of the address and its sending and receiving transactions. The block gaps are the differences between the blocks of consecutive transactions of the address, taken over all transactions and over sending and receiving transactions separately, and are zero when fewer than two such transactions exist.

The lifetime features record the first and last block of the address, their difference, the first sending and first receiving block, both zero when the address never sends or never receives, and the number of distinct time steps in which it is active. The counterparties of an address in a transaction are the addresses on the opposite side, the output addresses when it sends and the input addresses when it receives, excluding the address itself. The five summary statistics of the number of transactions shared with each counterparty, and the number of counterparties shared in more than one transaction, complete the 55 features. Table 5 in Section A gives the formula of each feature.

Feature	Computation
Per-transaction quantities, for $t \in T$
Net amount sent	$s_t = \max(\mathrm{in}_t-\mathrm{out}_t, 0)$
Net amount received	$r_t = \max(\mathrm{out}_t-\mathrm{in}_t, 0)$
Amount transacted	$v_t = s_t+r_t$
Fee	$f_t = \max(I_t-O_t, 0)$
Fee share	$\phi_t = f_t \cdot\max(\mathrm{in}_t,\mathrm{out}_t)/I_t$
Volumes (15)
Amount transacted (5)	$\operatorname{stat}_{t\in T}(v_t)$
Net amount sent (5)	$\operatorname{stat}_{t\in T}(s_t)$
Net amount received (5)	$\operatorname{stat}_{t\in T}(r_t)$
Fees (10)
Fee (5)	$\operatorname{stat}_{t\in T}(f_t)$
Fee share (5)	$\operatorname{stat}_{t\in T}(\phi_t)$
Block gaps (15)
All transactions (5)	$\operatorname{stat}\ \Delta(T)$
Sending transactions (5)	$\operatorname{stat}\ \Delta(S)$
Receiving transactions (5)	$\operatorname{stat}\ \Delta(R)$
Counterparties (6)
Interactions per counterparty (5)	$\operatorname{stat}_{c\in C}(n_c)$
Repeated counterparties (1)	$\lvert\{c\in C\mid n_c>1\}\rvert$
Transaction counts (3)
Transactions (1)	$\lvert T\rvert$
Sending transactions (1)	$\lvert S\rvert$
Receiving transactions (1)	$\lvert R\rvert$
Lifetime (6)
First block (1)	$\min_{t\in T} b_t$
Last block (1)	$\max_{t\in T} b_t$
Lifetime (1)	$\max_{t\in T} b_t-\min_{t\in T} b_t$
First sending block (1)	$\min_{t\in S}b_t$, or 0 if $S$ is empty
First receiving block (1)	$\min_{t\in R}b_t$, or 0 if $R$ is empty
Time steps (1)	number of distinct Elliptic time steps of $t\in T$

The two output feature sets in Figure 1 come from the same computation and differ only in which rows of the per-transaction table enter the aggregation. The lifetime set uses every Elliptic transaction of each address, which reproduces the construction of Elliptic++ and serves as the leaky baseline. The leakage-resistant set keeps, for each training address, only its transactions up to the cutoff block, and for each test address its transactions up to the end of the test period. Every feature is therefore computable at the observation point of its address, and since models are fitted or scored immediately after these points, the legitimacy rule of Kaufman et al. [14] holds.

Some features are identical or linearly dependent by construction. The total block gap equals the lifetime, since the gaps between consecutive transactions of an address sum to the difference between its last and first block, and the lifetime is itself the difference between the last and first block. The totals and means of the amounts transacted, sent, and received satisfy $transacted = sent + received$ for every address, and the number of transactions equals the numbers of sending and receiving transactions combined. Table 2 lists these identities and the share of training addresses that satisfy them in the features released by Elmougy and Liu [9] and the leakage-resistant features computed here.

Identity	Released	Leakage-resistant
Total block gap = lifetime	99.971% (50)	100%
Lifetime = last block − first block	100%	100%
Transacted = sent + received, totals	99.998% (4)	100%
Transacted = sent + received, means	99.997% (5)	100%
Transactions = sending + receiving	100%	99.998% (3)

The exceptions have two sources. In the released features, the total block gap exceeds the lifetime for 50 training addresses, while their lifetimes agree with ours. Gaps between consecutive transactions can sum to more than the difference between the last and first block only if the transactions are not ordered by block when the gaps are taken, so these values are consistent with an ordering error in the original computation of Elmougy and Liu [9]. The released amounts also violate transacted = sent + received for 4 addresses in the totals and 5 in the means, which our recomputation does not reproduce. In the leakage-resistant features, three training addresses each have a transaction in which they contribute exactly what they collect. Its net stake is zero, so it counts towards the total but as neither a sending nor a receiving transaction. Elmougy and Liu [9] appear to count such a transaction as sending, since for the five addresses with such transactions in the lifetime set the released sending count exceeds ours by one or two.

Figure 2 shows the correlations among the 55 features on the training addresses, for the released features in the left panel and the leakage-resistant features in the right. Each panel correlates one feature set with itself, with Pearson correlations above the diagonal and Spearman correlations below it. The dark blocks along the diagonal reflect the redundancy of the summary statistics, the total, minimum, maximum, mean, and median of the same quantity. Spearman correlations among the five statistics of a quantity average 0.85 to 0.99 for the volumes, fees, and block gaps, since most addresses have few transactions and their totals, extremes, means, and medians often coincide. The amounts sent and received are negatively rank-correlated (Spearman −0.35), since many addresses only send or only receive within the Elliptic transactions, yet positively correlated in value (Pearson 0.88), since a few high-volume addresses both receive and send large amounts. Given the high correlation and even exact duplication among many of these 55 features, including them all in the feature set results in multicollinearity, which one should take into account.

Comparing the two panels shows that the cutoff hardly changes the correlation structure, both the redundancy within each family and the relations between families. No Spearman correlation changes by more than 0.05, and Pearson correlations, which weigh extreme values more heavily, change by up to 0.38, reflecting the 2,501 training addresses whose features the cutoff alters. The two panels, however, differ in two respects, the recomputation and the cutoff. The lifetime set separates the two, since it is recomputed in the same way but without the cutoff, so its correlations differ from those of the released features through the recomputation alone. They agree to within 0.006 for Spearman and 0.013 for Pearson. The recomputation therefore barely changes the correlations, and the differences between the two panels can be attributed to the cutoff.

Model Performance

Evaluation setup

The evaluation follows the classification pipeline of Elmougy and Liu [9], so that differences in performance can be attributed to the data rather than to the models. Two classifiers are fitted, a logistic regression (LR) with the default ridge penalty and a random forest (RF) with 50 trees, both without class weighting. Features are MinMax-scaled, and predictions use the default decision threshold of 0.5. Performance is reported as precision, recall, and F1 on the illicit class. LR is fitted once with the default L-BFGS solver and L2 penalty of scikit-learn, following Elmougy and Liu [9]. They fix no random seed for the RF, so its performance is reported as the mean over 10 seeds, with the standard deviation reported below. Under the positional split, the scaler is fitted on all labelled addresses. Under the temporal split, it is fitted on training addresses only, so that no statistic of the test period enters training.

Reproduction

We first validate the recovered lifetime features against the released values for every labelled address. Each of the 55 features matches the released value to high precision⁹ for at least 99.9% of the 265,352 addresses, and the least-matching feature, the total counterparty count, still matches for 99.915%. The fee share is the one feature whose definition departs from its verbal description.¹⁰ Computed per transaction and then aggregated, it matches the released values within one percent¹¹ for 99.9% of addresses, against 7.65% when computed as a single ratio of the address’s total fees to its total amount transacted. A further 86 addresses (0.03%) differ from the released values by more than one percent on at least one of the 25 value features, but dropping them leaves model performance unchanged (Table 6 in Section B).

	All addresses			86 dropped			137 dropped
Model	P	R	F1	P	R	F1	P	R	F1
LR	0.492	0.062	0.110	0.481	0.065	0.114	0.483	0.062	0.114
RF	0.911	0.786	0.844	0.915	0.786	0.846	0.912	0.785	0.844
	(0.004)	(0.003)	(0.002)	(0.004)	(0.002)	(0.002)	(0.005)	(0.003)	(0.004)

Table 3 reports the Elliptic++ wallet classifier under its original positional 70/30 split. On the recovered lifetime features, the RF reaches an F1 of 0.844, against 0.846 on the released features and 0.845 reported by Elmougy and Liu [9], with a standard deviation of 0.002 across seeds. LR reaches 0.110 on both recovered and released feature sets, above the 0.083 reported in the original study. We

Model	Recovered P	Recovered R	Recovered F1	Released P	Released R	Released F1	Elmougy and Liu [9] P	Elmougy and Liu [9] R	Elmougy and Liu [9] F1
LR	0.492	0.062	0.110	0.499	0.062	0.110	0.477	0.046	0.083
RF	0.911 (0.004)	0.786 (0.003)	0.844 (0.002)	0.916 (0.004)	0.787 (0.003)	0.846 (0.002)	0.911	0.789	0.845

Note: LR, logistic regression; RF, random forest with 50 trees. Recovered features are recomputed from the Kondor ledger as lifetime summaries; released features are those of Elmougy and Liu [9]. Both follow their pipeline, with MinMax scaling over the 265,352 labelled addresses and the original positional 70/30 split. Elmougy and Liu [9] fix no random seed for RF, and their figures are from a single run; RF here is reported as the mean over 10 seeds, with the standard deviation below. Precision, recall, and F1 are at the default 0.5 threshold.

compute the features for the labelled addresses only and therefore fit the MinMax scaler on them, whereas Elmougy and Liu [9] fit it on all wallet addresses, including those of unknown class. The choice does not affect RF, whose splits are unchanged by a monotone rescaling of each feature, and barely affects LR. On the released features, scaling over all addresses including the unknown ones gives an F1 of 0.843 for RF and 0.102 for LR, against 0.846 and 0.110 when scaling over the labelled addresses. Dropping the 86 diverging addresses leaves both models unchanged (Table 6 in Section B). The recovered features therefore reproduce the released ones in their values, their correlations, and the model results they yield, and serve as the baseline for the comparisons that follow.

Effect of leakage

Table 4 separates the two leakage channels. The first column group repeats the released-feature results of Table 3. The second keeps the released, leaky features but replaces the positional split with the temporal split of § 3.1, which closes the split channel alone. The third also replaces the features with the leakage-resistant ones, which closes both channels.

Model	Positional split released features P	Positional split released features R	Positional split released features F1	Temporal split released features P	Temporal split released features R	Temporal split released features F1	Temporal split leakage-resistant features P	Temporal split leakage-resistant features R	Temporal split leakage-resistant features F1
LR	0.499	0.062	0.110	0.199	0.520	0.288	0.198	0.506	0.285
RF	0.916 (0.004)	0.787 (0.003)	0.846 (0.002)	0.381 (0.048)	0.196 (0.033)	0.257 (0.035)	0.407 (0.074)	0.228 (0.050)	0.291 (0.058)

Closing the split channel leads to notable changes in terms of Precision, Recall, and F1 score. The RF F1 falls from 0.846 to 0.257, as precision drops from 0.916 to 0.381 and recall from 0.787 to 0.196. The drop is not an effect of a change in the illicit share, which is almost the same in the two periods, 5.4% in training and 5.3% in testing (Table 1). Under the positional split, training and test addresses come from the same periods and share their activity patterns, so the RF can score well by matching addresses to patterns it has already seen in that period. Once the test addresses all appear after the training period, this advantage disappears. The RF also becomes more unstable, with the standard deviation of its F1 across seeds rising from 0.002 to 0.035. LR moves in the opposite direction, from 0.110 to 0.288, with lower precision but much higher recall, and now matches or exceeds the RF.

Utilising the leakage-resistant features, hence closing the feature channel, results in changes in the features of 1.45% of training addresses, and of 0.52% of the illicit ones. In Elliptic++, most addresses are active for too short a time to accumulate post-cutoff information in their lifetime summaries. Consequently, we do not expect drastic changes in the Precision, Recall, and F1 score, when utilising the leakage-resistant features. Indeed, LR’s performance

Note: LR, logistic regression; RF, random forest with 50 trees, mean over 10 seeds with the standard deviation below. The first group repeats the released column of Table 3: positional 70/30 split, MinMax scaling over all labelled addresses. The temporal split trains on addresses first seen in Elliptic time steps 1–34 and tests on those first seen in steps 35–49, with MinMax scaling fitted on training addresses only. Leakage-resistant features cap each training address at the cutoff block. Precision, recall, and F1 at the default 0.5 threshold.

scores hover around the values observed under the temporal split with the released features. However, for the RF we observe an improvement in Precision, Recall, and F1 score when utilising the leakage-resistant features. Notably, the standard deviation also increases; however, the average score improves across all three metrics. A much stronger improvement would have been surprising, given that the features of only a limited number of addresses were exposed to future information leakage.

This contrasts with Elliptic transaction-level studies, whose features of address aggregates summarise each address’s activity on the whole chain up to a block well beyond the test period, so that almost every transaction carries look-ahead information [31] and the original features unsurprisingly dominate leakage-resistant features added to the feature set [15].

However, the usability of the leakage-resistant features developed in this paper naturally extends beyond Elliptic++. With the equations for their computation and the leakage-resistant pipeline provided, leakage-resistant features for any set of labelled Bitcoin addresses can be obtained. We showed that even for a small percentage of addresses affected by future information leakage, a notable effect on performance scores is visible. Furthermore, we showed the drastic effects of not using a temporal split during model training and evaluation. Under a temporal evaluation, the RF F1 is about 0.26 to 0.29 rather than 0.85 under the positional split, and the advantage of the RF over LR disappears.

Conclusion and Discussion

This paper asks whether the strong performance reported for address-level classification on Elliptic++ reflects out-of-sample detection or information leakage, and the answer is largely leakage. We recover the exact definitions of the 55 Elliptic++ address-level features by linking Elliptic transactions to a full Bitcoin ledger through a public deanonymisation map. The recovered features reproduce the released values for at least 99.9% of the labelled addresses and the reported RF performance to within 0.002 in F1. With these definitions, we recompute the features in a leakage-resistant way with a temporal split. Under this evaluation, the RF F1 on the illicit class falls from 0.846 to 0.291, and the RF no longer outperforms logistic regression.

Two implications follow. Results and model rankings reported on Elliptic++ under its released split should be re-evaluated under a temporal split before they are read as evidence of detection ability. The leakage-resistant features close both known leakage channels, so they allow for model training and development under realistic settings. Furthermore, the released definitions and code allow the same features to be computed for addresses outside Elliptic++.

Two limitations remain, both following from our decision to keep the work of El Mogy and Liu [9] so that our results are directly comparable with theirs. First, all 55 features enter the classifiers, although many of them are highly correlated or exactly collinear (Figure 2, Table 2). The five summary statistics of a quantity often coincide for addresses with few transactions, and some features are identical by construction. Such redundancy leaves RF largely unaffected but makes the coefficients of LR unstable, so feature selection or dimension reduction should precede modelling in future use of the dataset. Second, LR and RF are fitted with default hyperparameters, without class weighting, and with the default decision threshold of 0.5. Baselines against which a proposed model is judged should be tuned with the same care as the model itself, so that any reported advantage reflects the model improvement.

Ethics and Privacy Statement

This study uses only public data, the Bitcoin ledger, published as a parsed release under CC0 [18], and the released Elliptic++ dataset [9] and deanonymisation map [2]. It involves no human participants, and it attributes no address to a real-world identity beyond the pseudonymous addresses already released with Elliptic++. The main societal risk lies in the use of classification results. An address labelled illicit by a model carries statistical uncertainty. Due to false positives, model outputs should be scrutinised before supporting investigation and should not by themselves justify freezing funds or other action against an address’s owner. By showing how leakage inflates detection performance, this paper aims to reduce the risk of deploying classifiers whose reliability has been overstated.

References

Feature definitions

Table 5 gives the computation of each of the 55 features. In the leakage-resistant set, the transactions of a training address are restricted to blocks up to the cutoff, block 457,734.

Note: $t$ denotes a transaction and $c$ a counterparty address. $T$ is the set of Elliptic transactions in which $a$ appears as an input or an output, and $S=\{t\in T\mid s_t>0\}$ and $R=\{t\in T\mid r_t>0\}$ are its sending and receiving transactions. For $t\in T$, $\mathrm{in}_t$ and $\mathrm{out}_t$ are the amounts $a$ contributes as inputs and collects as outputs, $I_t$ and $O_t$ are the total input and output of $t$, and $b_t$ is its block. Amounts are in bitcoin, and $\phi_t=0$ if $I_t=0$. stat stands for the total, minimum, maximum, mean, and median, so each row containing it gives five features. The number in parentheses is the number of features in a row. $\Delta(X)$ lists the differences between the blocks of consecutive transactions of $X$ ordered by block, and is (0) if $X$ has fewer than two transactions. The counterparties of $a$ in $t$ are the output addresses of $t$ if $t\in S$ and its input addresses if $t\in R$, excluding $a$. $C$ is the set of all counterparties of $a$, and $n_c$ is the number of transactions in which $c$ is a counterparty of $a$. $\lvert X\rvert$ denotes the number of elements of a set $X$.

Validation of the recovered features

The one-percent check of § 4.2 combines a relative tolerance of 0.01 with an absolute tolerance of $10^{-4}$ bitcoin (10,000 satoshis), about one twentieth of the median transaction fee of the labelled addresses (0.00185 bitcoin). The absolute term keeps differences in very small amounts from counting as divergences. Under this rule, 86 addresses (0.03%) differ from the released values by more than one percent on at least one of the 25 value features. Replacing the absolute term with one satoshi raises the number to 137. The 51 additional addresses differ by at most 0.0003 bitcoin. Most differ only on the fee share, whose values for these addresses are of the order of $10^{-5}$ bitcoin, and 15 differ on every volume feature by the same 0.000027 bitcoin where the released value is zero. Under the stricter rule, the per-transaction fee share matches the released values for 99.96% of addresses, against 6.00% for the single ratio of total fees to total amount transacted. Dropping either set of divergent addresses leaves model performance unchanged (Table 6).

Note: LR, logistic regression; RF, random forest with 50 trees, mean over 10 seeds with the standard deviation below. Recovered lifetime features, positional 70/30 split, and the pipeline of El Moughay and Liu [9] as in Table 3. The 86 addresses diverge from the released values under an absolute tolerance of $10^{-4}$ bitcoin, the 137 under one satoshi, both with a relative tolerance of 0.01. Precision, recall, and F1 at the default 0.5 threshold.