A Temporal Graph Dataset of Bitcoin Entity-Entity Transactions

Abstract

Research on Bitcoin (BTC) transactions is a matter of interest for both economic and network science fields. Although this cryptocurrency is based on a decentralized system, making transaction details freely accessible, making raw blockchain data analyzable is not straightforward due to the Bitcoin protocol specificity and data richness. To address the need for an accessible dataset, we present ORBITAAL, the first comprehensive dataset based on temporal graph formalism. The dataset covers all Bitcoin transactions from January 2009 to January 2021. ORBITAAL provides temporal graph representations of entity-entity transaction networks, snapshots, and stream graph. Each transaction value is given in Bitcoin and US dollar regarding daily-based conversion rate. This dataset also provides details on entities such as their global BTC balance and associated public addresses.

Background & Summary

Bitcoin (BTC) is the first modern cryptocurrency. It was proposed in 2008 by a person or a group of persons known as Satoshi Nakamoto, implementing a protocol described in a white paper¹. Unlike economic activities issued by banks and other financial institutions, all details about past Bitcoin transactions are freely accessible to anyone with the skill to access it, since all the transactions are recorded in the so-called blockchain. Since the first BTC transaction happened in January 2009, the Bitcoin ecosystem has brought interest as a source of investment, speculation, and is also used to buy and sell goods and services such as dark market and gambling platforms. In order to perform BTC transactions, users use pairs of public and private keys instead of bank accounts. This pseudonymity motivates cybercriminals to use such a system.

While using networks to represent Bitcoin transactions seems natural, the raw data stored in the blockchain is not adapted for an efficient representation as such. Indeed, due to the design of the Bitcoin protocol, each transaction can involve multiple inputs and multiple outputs, thus requiring a representation as a directed and weighted hypergraph, that is complex and inconvenient. Even worse, the nodes of this network would be Bitcoin addresses, which are significantly different from Bitcoin users. The usual approach in the literature thus consists of using heuristics and other strategies to identify the multiple addresses of a single user, allowing to move from an address-to-address network to a user-to-user one.

To the best of our knowledge, no complete Bitcoin dataset designed for graph analysis has been published in the scientific literature. Among existing datasets, some provide the raw data, (e.g.,²) or enriched version of the raw data (e.g.³). Transforming this raw data into network representation is a challenge due to the specificity of the Bitcoin protocol and the scale of the data, as explained in the method section of this article. The closest work is the popular Elliptic dataset^4,5, which provides a network-based representation. This dataset is widely used in machine learning studies. Elliptic however includes only approximately 200k transactions representing a very small fraction of Bitcoin transactions, i.e., less than one thousandth of the total number of transactions. One of the most common way researchers use to access complete Bitcoin Data is through specialized open-source data extraction software^6,7. However, the extracted data still requires processing to be transformed into analyzable networks. Furthermore, the most used of them, BlockSci⁶ is no longer supported since 2020. There are also online cryptocurrency explorer and analytics services that don’t provide any dataset permitting the construction of transactions network^5,8,9.

The interest in a comprehensive Bitcoin dataset for graph analysis goes beyond the research on cryptocurrency and the economic relations between users. The temporal aspect and the large number of users and transactions make it a perfect candidate for temporal graph analysis, especially for the development of large network analysis tools and adapted algorithms for big data analysis, as well as machine learning. As a reference point, the largest temporal network in the popular Netzschleuder repository¹⁰ at the time of writing is the US-Patent Dataset (#Nodes ≈ 3M,#Edges ≈ 16M). More recently, authors have introduced large temporal datasets to use in machine learning in the popular TGB^11–15 (Temporal Graph Benchmark), as an answer to the lack of available large datasets. The largest in terms of nodes has #Nodes ≈ 1M and the largest in terms of edges has #Edges ≈ 78M. In comparison, our dataset contains #Edges ≈ 1,68B transactions between #Nodes ≈ 364M users.

Aware of the importance of the economic network of Bitcoin and the necessity for a comprehensive dataset, we propose ORBITAAL¹⁶ (comprehensive Bitcoin dataset for temporal graph analysis), a readily analyzable dataset, structured in a standard formalism, i.e., a temporal graph. ORBITAAL requires no specific Bitcoin-related knowledge to be used, and covers the period 2009 to 2021, representing 13 years of Bitcoin transactions. It is also the first dataset proposing two temporal graph representations: the stream graph, as described in¹⁷, and snapshots using different timescales, namely year, month, day, and hour. All transactions present in the dataset are expressed in both BTC and daily-based US dollar (USD) converted values. In addition to the snapshots and stream graph, we also provide the list of all Bitcoin users with their name, first and last period of activities, and global BTC balance. Since these users have been inferred from aggregation techniques and a set of addresses found in walletexplorer.com, we also give the list of all users’ pool of addresses.

Methods

Due to the decentralized nature of cryptocurrencies such as Bitcoin, the data stored in their blockchain is accessible by anyone. Therefore, researchers can access it without any cost and limitations. The data stored in the Bitcoin blockchain is rich, containing information such as public addresses, transaction hash, amount of BTC exchanged, timestamp of the transactions, fees paid by senders, etc. We describe in this section the methods used to build ORBITAAL from the extraction of the blockchain to the construction of the temporal graphs. The whole process is represented in Fig. 1. The final dataset captures a total of 364 million users performing 1.68 billion transactions within 667, 223 distinct timestamps.

Fig. 1.

ORBITAAL dataset construction pipeline. Procedure steps colored in blue are associated with third-party data, and the ones colored in green are associated with DataFrame present in ORBITAAL repository.

From binary data to human readable blockchain contents

The first step of the data collection was to download the full content of the Blockchain. To do so, one has to install the Bitcoin Core software and launch the synchronization of the full Blockchain. At the time of download, the full weight of the blockchain was about 207 GB.

The second step consists of transforming the raw data, provided in an efficient Binary format, into an easily parsable and interpretable format. We used Bitcoin-etl python library¹⁸ to transform this raw data into json format. After transformation, the full data weighs 1.6 TB.

The next step consists of enriching the data with input Bitcoin addresses. Indeed, in Bitcoin, each input is an output from a previous transaction. In the original format, inputs are thus identified by a pair (TxID, N), with TxID the unique hash of the input transaction, and N an integer identifying which output of TxID is used as input. Since we need to know the identity of the sender, we retrieve the Bitcoin address information for each input of each transaction.

Address clustering

In the ORBITAAL dataset, Bitcoin users are first inferred using the common-input heuristic¹⁹. This task has been performed efficiently by using a graph approach: 1) We first create a graph in which each node is an address, 2) For each transaction, we add an edge between the input address in position x and the one in position x + 1, 3) finally, we compute the connected components of this graph using an efficient graph framework, namely NetworKit²⁰. Each connected component constitutes a group of addresses considered as belonging to the same user. This heuristic has been repeatedly considered efficient in the literature¹⁹ and is the most commonly used, despite its known limits²¹. Note that this transformation leads to some information loss, thus the results of user identification must always be interpreted with caution. It is considered as having a high precision²² (if two addresses are in the same cluster, they belong to the same user), but a low recall (it is common that two addresses belonging to the same user are identified as belonging to different ones). Additionally to this heuristic, we also use a well-known website, WalletExplorer²³, that provides a database linking Bitcoin addresses to the real identity of their owner. We use it for two tasks: 1) Enrich the data with 360 user identities, including Exchange platforms, mining pools, gambling services, etc., and 2) Further merge clusters of addresses that are known to belong to the same user based on this external knowledge.

User to user transactions

After performing address clustering, each Bitcoin transaction becomes a one-to-one or one-to-many transaction: all addresses in input by definition belong to the same user, but addresses in output might belong to 1) the same user (self-spent), 2) one different user, 3) multiple different users, including or not the sender. We convert these Bitcoin transactions into simpler, one-to-one payments: for a Bitcoin transaction from user u₁ having p different outputs to users (u₂, u₃, …, u_1+p)., we create a corresponding number of payments (u₁, u₂), (u₁, u₃), …, (u₁, u_p+1). The amount associated with this payment is the sum of all payments from the source to the destination at that particular timestep. This construction procedure is standard in the literature. It has been used for instance in⁴.

Note that the transformation from an address network to a user network, although simplifying greatly the data, comes at the price of some information loss compared with the raw data. Namely, there are two sources of information loss: 1) We lose the details of the addresses used, which might contain useful details such as the fragmentation of coins in multiple accounts, etc. 2) We lose the information of multiple payments between the same actors occurring at the same time. However, we think that most of this information constitutes noise, which is not relevant to the analysis. To take a concrete example (see Fig. 2), the raw data contains all details about sources and destinations, e.g., if a user u₁ makes a transaction to pay user u₂, one could observe that the transaction has 2 inputs, one coming from user u₃ and another from user u₄, although user u₁ also received coins from u₅. One could therefore trace coins from u₃/u₄ to u₂ through u₁, and not from u₅ to u₂ through u₁. When performing the user-aggregation, this information is lost, and we only see that u₁ received coins from u₃,u₄, and u₅ before making the payments to u₂. However, it is very likely that those details were in fact misleading: if for instance, u₁ is using a wallet software to manage its activities, they are not aware of the details of those transactions as described above, the wallet automatically chooses the right sources to make its payment while minimizing the fees to pay. In most cases, we can therefore assume that this information loss is acceptable, or even beneficial to the interpretation of user activity.

Fig. 2.

Illustrations of the change of representation between the original Blockchain Data and our Stream Graph representation. Note the loss of information: the original data keeps track of the exact flow, e.g., that coins sent by U3 to U4 in Tr4 come from two different previous transactions, Tr3 and Tr2. On the contrary, in the user stream-graph representation, this information is lost. However, in most cases, this information can be considered as noise, and the user-network representation is more faithful to how users behave in the network, since they manage a pool of transaction outputs, without conscious knowledge of their sources. For simplicity, we did not represent the mining and fees in these transactions.

Mining-node and non-standard transactions

In Bitcoin and many other cryptocurrencies, the validation of transactions and their inclusion in the blockchain is performed by specific users, known as miners. When a set of transactions (bloc) is mined and added to the blockchain, the actor who solved the required cryptographic puzzle earns rewards in the form of newly minted Bitcoins. Additionally, the miner also receives payments from senders in the form of transaction fees. This is because the Bitcoin protocol has a fixed, limited bandwidth, requiring users to compete for their transactions to be included. Users spending Bitcoin have thus to pay fees, acting as incentives to miners for including these transactions in the blockchain, as Miners can choose which transaction they want to include in the next block. To represent these fee transactions while keeping a graph-only representation, we introduce a formalism using a dedicated node, called Miner-Node. Its outgoing transactions encode miners’ rewards, and its incoming transactions for paid fees.

Bitcoin transactions can be associated with so-called nonstandard addresses. Such addresses are associated with transaction outputs that were not validated during the Bitcoin transaction validation protocol and received 0 BTC. This can happen for a variety of reasons, from mistakes when forming the transaction to vanity reasons. We therefore remove those outputs from the dataset.

At this stage, we have a complete dataset of user-user transactions. To make it easily reusable, we convert it into two standard temporal graph formats, stream graph and snapshot sequences.

Stream graph construction

Stream graph formalism was proposed by Latapy et al. in 2018¹⁷. This temporal graph representation is the most natural for data composed of interactions, such as payments between users. We note G = (T, V, W, E) the stream graph consisting in a set of times T (every instant at which at least a transaction has been added to the blockchain), a set of vertices V corresponding to users that have been involved in at least one transaction, the set of temporal nodes W, pairs (u, t), u ∈ V, t ∈ T, representing the existence of node u at time t, and the set of temporal links E, 3-tuples (u, v, t) corresponding respectively to the spender, receiver and time of the payment. The mining dedicated node is also present in the stream graph and handles both the paid fees and mining rewards.

In the stream graph, edges are directed, and information is associated with nodes (name, list of addresses) and edges (BTC amount, US Dollar value).

This Bitcoin user transaction network represents all BTC transactions at the finest timescale —being  ≈10 minutes, the average time between two validated blocks. An illustration of a stream graph representing Bitcoin transactions is given in Fig. 3 panel (a).

Fig. 3.

Illustrations of the stream graph (left panel) and snapshot (right panel) temporal network representation of Bitcoin transfers between users. In the case of the stream graph, blue dashed horizontal lines represent the period of activity of each node. The snapshot representation is based on an aggregating window of 2 time steps, therefore the left layer is based on [0, 1] time window, while the right layer is based on the [2, 3] window. In both representations, the orange-colored node represents the mining node and dotted links are associated with fee transactions.

Snapshot construction

Although the stream graph representation is the most natural for this data, it is not the most common formalism to work with temporal graphs. Indeed, most existing algorithms and tools rather expect a representation as sequences of static graphs, known as snapshots. To facilitate reusability, we also provide the data as snapshot representations, aggregated at typical timescales. Let us note τ a set of discrete times or continuous period of times, we have G_τ(E, V) the snapshot covering period τ with V the set of Bitcoin users performing at least one transaction in τ and E the set of directed links representing the direction of Bitcoin from spenders to receivers. The weight of each link is the sum of Bitcoins exchanged over τ. As presented before, a dedicated mining node is added to these networks with specific ID 0 such that the link 0 → m and s → 0 represent respectively Bitcoin earned by miners m and fees paid by spender s. A toy network is presented in Fig. 3 panel (b).

We provide different temporal scales for Bitcoin user transaction snapshots. The largest encodes the snapshot covering the whole period of data (13 years), other resolutions are associated with year, month, day, and hour scales.

Additional information related to users and addresses

Additionally to the network representation, we also provide important data about users’ life cycles. In the Bitcoin protocol, there is no user creation or removal from the system, one only observes them when they are involved in a transaction. For each user, we provide a period of existence corresponding to the period between its first apparition, and the latest time at which its balance was positive —or the end of the period covered by the dataset if it is still positive at that time. We also provide each user’s list of associated public addresses (list of address aggregates), their identity as known from WalletExplorer if available, and their final BTC balance. The BTC balance is measured as the difference between the total quantity of BTC spent and received over the whole period.

Data Records

ORBITAAL dataset¹⁶ is available on the Zenodo open repository at 10.5281/zenodo.12581515.

Dataset contents

The files containing the main ORBITAAL dataset are the following:

• orbitaal-stream_graph.tar.gz contains the stream graph representation, split in one file per year.

  Dataframe columns with data types:

  • SRC_ID: Transaction’s source entity ID (int).
  • DST_ID: Transaction’s target entity ID (int).
  • TIMESTAMP: Transaction’s unix time timestamp (int).
  • VALUE_SATOSHI: Transaction’s amount of Bitcoin exchanged in Satoshi (10⁻⁸ BTC) (int).
  • VALUE_USD: Transaction’s amount of Bitcoin exchanged in US dollar regarding daily conversion coefficient (float).

• orbitaal-snapshot-all.tar.gz contains a single static graph, corresponding to the total cumulated graph.

  Dataframe columns with data types:

  • SRC_ID: Transaction’s source entity ID (int).
  • DST_ID: Transaction’s target entity ID (int).
  • VALUE_SATOSHI: Transaction’s amount of Bitcoin exchanged in Satoshi (10⁻⁸ BTC) (int).
  • VALUE_USD: Transaction’s amount of Bitcoin exchanged in US dollar regarding daily conversion coefficient (float).

• orbitaal-snapshot-year.tar.gz, orbitaal-snapshot-month.tar.gz, orbitaal-snapshot-day.tar.gz and orbitaal-snapshot-hour.tar.gz contain respectively snapshots aggregations every year, month, day and hour. Each file is a compressed archive, containing one graph file per aggregation window.

  Dataframe columns with data types:

  • SRC_ID: Transaction’s source entity ID (int).
  • DST_ID: Transaction’s target entity ID (int).
  • VALUE_SATOSHI: Transaction’s amount of Bitcoin exchanged in Satoshi (10⁻⁸ BTC) (int).
  • VALUE_USD: Transaction’s amount of Bitcoin exchanged in US dollar regarding daily conversion coefficient (float).

• orbitaal-nodetable.tar.gz contains the node details, i.e., for each user ID, its estimated lifetime period, final balance, and list of Bitcoin addresses. The IDs used are coherent over each network representation.

  Dataframe columns with data types:

  • ID: ID of the entity (int).
  • NAME: Name of the entity if provided by walletexplorer, else ID (string).
  • FIRST_TIMESTAMP: Unix time timestamp of the first activity time of the entity (int).
  • LAST_TIMESTAMP: Unix time timestamp of the last recorded activity time of the entity (int).
  • BALANCE_SATOSHI: Balance in Satoshi of the entity (received - sent) (int).

It contains additional data giving a list of Bitcoin addresses and respecting network node ID and name.

Dataframe columns with data types:

• ID: ID of the entity (int).

• NAME: Name of the entity if provided by walletexplorer, else ID (string).

• ADDRESS: Address owned by the entity (string).

Additionally to the data files, the repository includes a Readme file in MarkDown and 4 short CSV files representing transactions at the day resolution before and after the Bitcoin halving that occurred in July 2016. These CSV files can serve as quick-starting examples to get used to the dataset, without the difficulty of handling large data. Table 1 gives details on the 12 archives present in the dataset. We can note that the weights of our graph representations are much smaller than the original files extracted from the blockchain. This is because we removed a lot of information not directly related to transactions (e.g., transaction hashs), concentrating on the essential transactional aspect of the Bitcoin data.

Table 1.

List of archives in the ORBITAAL repository from Zenodo platform with associated details.

File name / Archive name	Size in Bytes	Total number of files	Total number of transactions (millions)
orbitaal-nodetable.tar.gz	24 GB	2	—
orbitaal-stream_graph.tar.gz	24 GB	13	1679
orbitaal-snapshot-all.tar.gz	10 GB	1	616
orbitaal-snapshot-day.tar.gz	25 GB	4401	1466
orbitaal-snapshot-hour.tar.gz	27 GB	104824	1594
orbitaal-snapshot-month.tar.gz	23 GB	145	1304
orbitaal-snapshot-year.tar.gz	23 GB	13	1258
orbitaal-stream_graph-2016_07_08.csv	26 MB	1	0.5
orbitaal-stream_graph-2016_07_09.csv	22 MB	1	0.5
orbitaal-snapshot-2016_07_08.csv	17 MB	1	0.5
orbitaal-snapshot-2016_07_09.csv	15 MB	1	0.4
orbitaal-readme.md	10.3 KB	1	—

Format

Each graph data is provided in .parquet format, which is an efficient tabular data storage, similar to .csv but offering better performance: 1) it uses less space on disk, 2) retains original data types, and 3) allows loading only some of the columns to save memory space. .parquet is a standard format that can be directly loaded in libraries such as Pandas²⁴ or Pyspark²⁵.

Each network is provided in an enriched edge list format, i.e., each row contains an edge corresponding to a payment (or a summary of payments over a period), described by source and destination nodes ID, a timestamp in the case of stream graphs, and values in BTC and US Dollar.

Technical Validation

This section presents validation tests assessing that the ORBITAAL dataset¹⁶ accurately captures Bitcoin transaction data in the form of temporal graphs (e.g. snapshots and stream graph). We also provide a quantitative description of several aspects of the provided data, demonstrating that the data can be used to perform temporal network analysis.

Sanity check

In order to assert the validity of our data processing steps, we compare some key data descriptors with an external ground truth. We use as reference blockchain.com⁸, a popular cryptocurrency explorer, providing various statistics about the Bitcoin blockchain. Global measures are based on the stream graph data. To compare the results with the ground truth, we use the relative error δ_r, with δ_r ∈ [−1, ∞], defined as

$${\delta }_r\left(v_1,v_2\right)=\frac{v_1-v_2}{v_2}$$ 1

where v₁ (resp. v₂) is the measure obtained from ORBITAAL (dataset of reference). A value close to 0 means an exact similarity, while a positive (resp. negative) value of δ_r indicates a higher (lower) coverage of bitcoin transactions in ORBITAAL compared to the dataset of reference.

The first Bitcoin feature we consider is the overall amount of transaction fees paid by all users daily. In our dataset, this information is captured by transactions to and from the dedicated mining node. Figure 4 shows strong similarities between datasets with an average relative error $\overline{{\delta }_r}=0.0021\%$. This means that our representation is faithful to the original data, i.e., no data was lost or erroneously added during the processing steps.

Fig. 4.

Comparing the daily paid fees (top left panel) and its cumulative (top right panel) obtained from ORBITAAL dataset (blue) with data from blockchain.com (red). The bottom panels represent the relative error between both datasets such that positive (resp. negative) δ_r value indicates a higher accuracy for ORBITAAL (the dataset of reference).

The second global measure is the total transactions’ outputs in BTC representing all exchanged Bitcoin —not including transaction fees. Comparison with the dataset of reference is presented in Fig. 5. We observe that our dataset is faithful to the reference, with $\overline{{\delta }_r}=-0.034\%$. The differences occurring during the 2009-2010 period are due to non-standard transactions that were common in Bitcoin’s early period.

Fig. 5.

Comparing the daily total transaction outputs in BTC (top left panel) and its cumulative (top right panel) obtained from ORBITAAL dataset (blue) with data from blockchain.com (red). The bottom panels represent the relative error between both datasets such that positive (resp. negative) δ_r value indicates a higher accuracy for ORBITAAL (the dataset of reference).

The final global measure is the number of distinct transaction outputs. This measure is directly related to the number of links in temporal graphs provided by ORBITAAL. Since our dataset provides user-to-user transaction networks, we expect that the dataset of reference, which is related to address-address transactions, give a higher number of distinct outputs. Comparison is presented in Fig. 6. Although the average relative error is negative ($\overline{{\delta }_r}=-32\%$), it remains stable, indicating that the differences come mainly from address clustering and that the ORBITAAL data set remains accurate.

Fig. 6.

Comparing the daily number of distinct transactions (top left panel) and its cumulative (top right panel) obtained from ORBITAAL dataset (blue) with data from blockchain.com (red). The bottom panels represent the relative error between both datasets such that positive (resp. negative) δ_r value indicates a higher accuracy for ORBITAAL (the dataset of reference).

These checks validate the accuracy of the ORBITAAL dataset in providing Bitcoin transaction networks and ensure that there is no significant lack of information compared to the data that can be found in commercial reference services.

Description of ORBITAAL’s temporal graphs

This section presents important properties of temporal graph data provided in ORBITAAL dataset. These properties validate that the dataset can be analyzed as a temporal network. We first recall important definitions introduced in Latapy et al.¹⁷ to describe link streams.

Node contribution

In a stream graph, G = (T, V, W, E) a living period τ_i is associated with a node i such that for every time instants t ∈ τ_i, the pair (i, t) exists in the set of temporal nodes W. We define contribution of the node i, noted n_i, as the living period of i expressed as a fraction of all time instants (τ), we have

$$n_i=\frac{\mid {\tau }_i\mid }{\mid \tau \mid }$$ 2

with |x| the size of the set x. We also define n = ∑_i∈V n_i, the total node contribution, with V being the set of nodes (all users involved in at least one transaction).

Period of activity

A user is considered active from its birth date, the first timestamp of activity, to its death date. The death date is either its last transaction timestamp if its final balance is zero, or the last date of the dataset if it keeps a positive balance.

Living node

A living node at time t is any user having a non-zero BTC balance at time t. Therefore any node is considered as a living node during its period of activity.

Node degree

The node degree informs on the nodes’ local neighborhood. In the case of directed static networks, such as snapshots, we have two measures of degree, the node’s incoming degree and outgoing degree. In the context of stream graphs, we consider an intuitive adaptation of node degree such that the incoming degree k_in, and outgoing degree k_out, of a node is the number of incoming, respectively outgoing, transactions per unit of time during this node living period. We have

$$k_{in}\left(j\right)=\frac{Nt{r}_{in}\left(j\right)}{\mid {\tau }_j\mid }$$ 3

with Ntr_in(j) the number of transactions j is an output of.

$$k_{out}\left(j\right)=\frac{Nt{r}_{out}\left(j\right)}{\mid {\tau }_j\mid }$$ 4

with Ntr_out(j) the number of transactions j is an input of. We note $\overline{k_{in}}$ and $\overline{k_{out}}$ the incoming and outgoing degree averaged over all nodes. While these two measures are identical in the case of snapshots, they are not with stream graphs.

Strongly connected component

A strongly connected component (SCC) of a directed network is defined as a partition of the network (sub-network) such that any node composing it can be reached from each other node that is part of it. The largest SCC is the SCC containing the highest number of nodes. Since the largest SCC captures the largest connected part of the network, analyzing its evolution is a relevant indicator for structural changes. Although there is a stream graph equivalent of SCC, the large size of Bitcoin transaction graphs makes its extraction difficult. Therefore we believe that ORBITAAL is a perfect candidate for large network analysis tools development and considering stream graph equivalent for SCC is part of further research.

Diameter and average shortest path

Let i and j be two nodes from a directed network, the path from i to j is the sequence of links used to reach j from node i. The shortest path between these two nodes will be the path presenting the lowest length (number of edges composing the path sequence). We can define two global distance metrics from it, the diameter which is the highest shortest path between any pair of nodes, and the average shortest path. In the context of the Bitcoin transaction network, these two metrics give access to typical distances between any users, in terms of the number of transactions. The equivalent for stream graphs are temporal paths and distances, but they were not considered in this article due to the lack of scalable implementations.

ORBITAAL snapshots and stream graph properties

Global statistics of snapshots and stream graph are provided in Fig. 7. Both graph data demonstrate that the data permits to observe the rapid burst of Bitcoin activity during the 2010-2012 period (Fig. 7 left panels). Considering finer time resolutions such as daily and hourly snapshots gives insight on periods of high activity, associated with much more local peaks. Since the definition of node degrees in the context of stream graph and snapshot are different, comparing them is not straightforward. However, both cases present a rapid increase in average degrees (Fig. 7 right panels). Average degrees related to ORBITAAL’s stream graph is stable after 2010-2011. During this stability period, a gap between incoming and outgoing degrees is present, with $\overline{k_{out}}>\overline{k_{in}}$. This gap indicates denser outgoing transactions (spent BTC) by unit of time and sparser incoming transactions (received BTC). While $\overline{k_{in}}$ remains stable from 2011-2020, $\overline{k_{out}}$ evolution shows a period of decreasing from 2011 to 2014. ORBITAAL’s snapshots present three distinct phases regarding average degree evolution. The first is related to an increasing phase from 2009 to 2014, then a stable phase occurs from 2014 to the end of 2016. The last phase depicts a smooth decrease. Snapshots based on finer time resolutions provided by ORBITAAL dataset reflect a large peak in July 2015 which can be due to historical Bitcoin events. This high-level description of the dataset validates that ORBITAAL captures and allows the description of global trends of Bitcoin activity as a temporal network.

Fig. 7.

Time evolution of snapshots and stream graph properties. The top panels are related to snapshot representations for all available time resolutions, and the bottom panels are to stream graphs. In the case of snapshots, the left panel presents evolution in terms of the number of nodes (red lines) and the number of edges (blue lines). In the right panel, the average out-degree evolution is shown. In both top panels, the line type and color brightness represent the time resolution, from yearly (solid line), monthly (dashed line), daily (dotted line), and hourly (dots) resolutions. The colors are darker for the higher resolution and brighter for the finest ones. In the case of stream graphs, the left panel shows the evolution of the total node contribution (red) and the average number of transactions at the hour level. The right panel shows, with red and blue lines, the evolution of the average out-degree and in-degree, respectively, as defined for stream graphs.

Statistics related to snapshots’ largest SCC sizes and distances are presented in Fig. 8. Yearly and monthly snapshots reflect a rapid increase in the largest SCC relative size up to 80% (resp. 70%) in case of year (month) resolution, during the early period of Bitcoin activity, from 2009 to 2013 (see Fig. 8 left panel). ORBITAAL’s snapshots present stable largest SCC relative sizes for the rest of the period. Considering finer time resolution snapshots (hour and day) is associated to smaller largest SCCs, therefore Bitcoin users’ strong connectivity could be a phenomenon emerging at a large time scale. ORBITAAL’s proposed snapshots reflect the largest SCC structure changes when the diameter and average shortest path are considered (Fig. 8 middle and right panels respectively). Large and localized peaks can be further investigated. They correspond to the year 2012, the 2015-2016 period, and the 2018-2019 period in case of diameter, and, the years 2010, 2012, and 2015 in case of average shortest path. These peaks are related to changes in network typical distances indicating a longer chain of transactions.

Fig. 8.

Time evolution of snapshots largest strongly connected component (SCC) properties. The left panel is associated with SCC relative size, the central panel is to diameter, and the right panel is to average shortest path. In every panel, the color brightness depicts the snapshot time resolution, with the darkest colors representing the largest resolutions and the brightest the finest resolution.

The node table DataFrame provided in ORBITAAL contains information permitting to calculate node living period, as well as their death period. The distribution of nodes’ death period, as a heatmap, is given in Fig. 9. Among Bitcoin users present in the dataset, the majority of them spent all their BTC a few months after their first activity (short living period). Data also reflects higher mortality rates periods, independent of users’ birth date. Among these dates we can figure out the pre-2018 Bitcoin crisis, validating that ORBITAAL accurately captures user’s activity patterns.

Fig. 9.

Heatmap representation of users death period. Each row (resp. column) consists in a birth date (death date) at the month resolution. The matrix elements are read such as the (i, j) element gives the proportion of users born at date/row i that died at date/column j. Each row sums to one. Color code is logarithmic with the darkest cells associated with the period with the highest death and the brightest cells associated with the lowest mortality period.

Usage Notes

Loading ORBITAAL’s dataframe

ORBITAAL dataset contents are data files in .parquet and .csv formats that can be loaded with Python’s packages such as Pandas²⁴ and Pyspark²⁵. A readme MarkDown file is also provided with a Quick Start guide containing examples about the dataset usage.

ORBITAAL’s temporal graph analysis

Due to the large size of stream graphs and snapshots present in ORBITAAL, large network analysis packages are required for most analyses. Researchers can use, for instance, SNAP²⁶, Networkit²⁰, or Raphtory²⁷.

Author contributions

R.C. supervised the project, wrote codes for Blockchain data extraction, and address clustering. C.C. wrote codes for temporal graph construction and entity information tables. C.C. performed the data analysis and technical validation. C.C. and R.C. equally contributed to drafting and revising the manuscript.

Code availability

Code used to construct ORBITAAL dataset is available at https://github.com/ccoquide/OrbitaalBuild.

Competing interests

The authors declare no competing interests.