BitConduite: Visualizing and AnalyzingEntity Activity on the Bitcoin Network

# BitConduite: Visualizing and Analyzing Entity Activity on the Bitcoin Network

## Abstract

We present BitConduite, a visual analytics tool for explorative analysis of financial activity within the Bitcoin network. Bitcoin is the largest cryptocurrency worldwide and a phenomenon that challenges the underpinnings of traditional financial systems—its users can send money pseudo-anonymously while circumventing traditional banking systems. Yet, despite the fact that all financial transactions in Bitcoin are available in an openly accessible online ledger—the blockchain—not much is known about how different types of actors in the network (we call them entities) actually use Bitcoin. BitConduite offers an entity-centered view on transactions, making the data accessible to non-technical experts through a guided workflow for classification of entities according to several activity metrics. Other novelties are the possibility to cluster entities by similarity and exploration of transaction data at different scales, from large groups of entities down to a single entity and the associated transactions. Two use cases illustrate the workflow of the system and its analytic power. We report on feedback regarding the approach and the software tool gathered during a workshop with domain experts, and we discuss the potential of the approach based on our findings.

Bitcoin, Cryptocurrency, Temporal Visualization, Clustering.

## 1 Introduction

#### Most Active Entities

To identify entities with the highest activity in the early years, we switch to the “multi-timers” class by clicking on the associated node in the tree view. Looking at the filter view we notice that the number of transactions per entity ranges from 0 to 57,384 (as sender) and 1 to 189,951 (as recipient). We use the cluster view to cluster the multi-timers by four activity measures: number of transactions, time active, as well as largest amount received and amount sent. We obtain three clusters: one active cluster with over 35,000 entities and two clusters of entities with less activity with differences in number of transactions and average number of inputs. Because we can tell from the glyphs that the two first clusters are similar we reduce the number of clusters to two and restart clustering. The result is now a small cluster of active entities (39,043) and a large one with entities of low activity (244,532). By clicking on the glyph representing the first cluster we load the 39,043 active entities into the entity browser. Sorting by number of transactions yields four entities that are more active in relation to the others. The most active entity is tagged as “Mt. Gox”, the Bitcoin exchange platform that started in June 20104 (Fig. 7).

This simple analysis shows that from their first appearance, big platforms have dominated the blockchain. This is a phenomenon that is still valid nowadays [21].

### 5.2 Analyzing A Significant Event: Halving Day 2016

This second use case deals with the phenomenon of Bitcoin mining. The mining market has changed over the years and has become more centralized. Nowadays, large mining pools dominate the market [12]. This is of interest for researchers in economics who examine the mining market and its impacts on the Bitcoin system. Halving days (when mining rewards are cut by 50%) are deemed important because they tend to have great impact on the Bitcoin price and the mining behavior.

To see effects of the last halving day on July 9, 2016, we take a closer look at mining behavior during the months before and after this day. It is known that the Bitcoin price remained relatively stable after this day5 but not much is known about the change in mining activity. A question our economics experts found particularly interesting was if the same entities successfully mine Bitcoin after the halving day or if some give up due to decrease in profit.

To answer this question we focus on transactions from June 9, 2016 to August 8, 2016, that is, 30 days before and 30 days after the halving day. Looking at the time chooser and the tree view, we learn that during this time period, million entities took part in about million transactions (as sender, recipient or both). The histograms in the filter view reveal that although the number of transactions ranges from 0 to 1,075,326 (as sender) and 1 to 3,074,401 (as receiver) the vast majority of entities took part in a small number of transactions.

#### Identify Miners

Miners can be identified as receivers of the “coinbase” transaction, which is the first transaction in each block that rewards them for mining the block [35]. It does not have a regular input address like other transactions. That is why we can identify entities that were involved in mining activities by applying a “zero input” filter (smallest recorded number of inputs = 0). In the classification tree we label them as “miners” and the complementary group as “not miners” (Fig. 8 second row). We learn that 1,050,441 (roughly 13.8% of all) entities in this time belong to the “miners” group. Using the time chooser we find out that the number of transactions after the halving day is about 16% lower than in the month before. Does this indicate less mining activity after the halving day?

#### Activity of Miners around the Halving Day

To get a better overview about the activities of the miners we cluster them by number of transactions as recipient and the time they were active in the selected time period. Starting with three clusters, the cluster view shows a large group of entities with low activity (905,732 / 86.2%), a smaller group of high activity (115,373 / 11.0%) and a tiny one in between (29,336 / 0.03%). We decide to cluster again with only two groups because the two clusters with low activity are similar and mainly differ in the average number of input addresses, which is not of interest here. The result is a large cluster (922,245 / 87,8%) with low activity and a much smaller one with high activity (128,196 / 12,2%). Looking at the glyphs in the cluster view and retrieving the exact values by hovering over them reveals that, beside the number of transactions, the two groups mostly differ in terms of the range of amounts received and sent and the number of input addresses per transaction.

One hypothesis regarding the halving day is that some miners stop their activity afterwards because of the much lower reward. To examine this we need to find miners that were active in the weeks before the halving day and remained active afterwards. As a first step, we apply a filter by time of first transaction before the halving day yielding a group of 7.9% of all entities we name “active before”. We further filter this subgroup setting the time of last transaction filter to the time period after the halving day. This yields the group of miners that were active before the halving day and remained active afterwards (1.2% of all entities). As a complementary group we get those that “gave up”, i.e., they were active before but not in the 30 days afterwards (6.7% of all entities) (Fig. 8).

This analysis shows that a large fraction (roughly 85%) of the miners that were active before the halving day did not receive mining rewards in the following 30 days. The reason could either be that they stopped mining after the halving day because the lower reward made their work no longer profitable, or that they still took part in the mining competition but were simply not successful. The blockchain does not provide information about this and without further information we can only speculate about the reasons. However, indeed, the number of miners seems to have decreased significantly after the halving day.

Looking at the entity browser lets us identify the most active entities before the halving day that remained active after. The transaction view shows that one of the most active miners from before the mining day was inactive during the 30 days after the halving day. From this observation we can conclude that the halving day had a relevant impact on mining behavior.

The use cases showed that BitConduite can support a range of complex explorations and insights. Still, we have to keep in mind the uncertainty inherent to our method due to the heuristics used for extracting entities from addresses. At the same time, the lack of ground truth prevents us from estimating this uncertainty.

## 6 Expert Workshop

We conducted a workshop with Bitcoin experts to receive feedback on how BitConduite supports exploratory analysis of entity behavior on the blockchain based on real analysis questions. We first describe the setup of the workshop and then report on the results.

### 6.1 Setup, Procedure, and Data Collection

We set up six workstations (standard desktop computers with Windows 10 / Ubuntu and Chrome / Chromium web browsers) in a large shared office in our lab. Participants interacted with BitConduite running in the web browser while data was delivered from a database and web server in our local network. We provided participants with data about the early years of Bitcoin from 2009–2011. Three co-authors of this paper were present at the workshop to take notes, pictures, and help with participants’ questions.

Before the start of the workshop, participants answered a questionnaire on demographics and their experience with Bitcoin. They then proceeded to a 30 minute training phase in which we presented the system using a slideshow and gave participants three hands-on exercises to complete. We answered participants’ questions throughout the training. We stopped the training after participants confirmed that they understood the BitConduite workflow.

After the training, participants filled out a second questionnaire, in which we asked them to write down questions they wanted to explore during the free exploration phase. Next, participants began the 60 minute free exploration phase during which they used BitConduite to answer their own questions about the Bitcoin blockchain. Throughout the free exploration phase the three experimenters answered questions about BitConduite if help was needed. The last questionnaire, after the free exploration phase, contained questions about BitConduite to receive more structured feedback about its usability. All three questionnaires are part of the supplemental material, as well as the introduction slides to BitConduite that contain the hands-on-exercises.

During the free exploration, we recorded participants’ actions with the tool, i. e., all events such as filtering, clustering, defining and selecting entity groups in the tree view, sorting, and selecting entities in the entity browser, as well as switching the mode (input / output) in the transaction view. Similar to other researchers [9, 13, 20], we used the interaction logs to learn about behavior and reasoning processes trying to understand how our experts arrive at insights during the study. Collecting interaction data allowed us to analyze which views participants interacted with the most and if they used BitConduite the way we intended (Fig. 4).

### 6.2 Background Information

We invited six participants, most of them with an economics background, to a half-day workshop in our lab. Five participants were male, one was female, and their age ranged from 25 to 51 years (average: 34.7 years). Among them, two participants were students (PhD in Economics and MSc in Acturial Finance) and the other participants were professional researchers: a senior researcher, research engineer, assistant professor, and associate lecturer.

We also asked participants about their familiarity with Bitcoin, visual data representations, clustering, and statistics; the results are summarized in Table II. All participants confirmed to have been working with Bitcoin data, specifying their experience between one month and five years (average: 1.9 years, one participant did not provide this information). We also asked what kind of Bitcoin data the experts worked with, and research questions they studied. Overall, participants were interested in many different topics regarding Bitcoin:

P1

understand what kind of people use Bitcoin and why

P2

model the market for mining and proof-of-stake

P3

find out if exchanges have liquidity issues and hat kind of smart contracts people use

P4

define a sentiment index on Bitcoin using alternatives data

P5

P6

study the dynamics of miners’ pools

### 6.3 Results

In this section we report on the results from the research questions, interaction logs, and user experience questionnaire.

#### Research Questions

Before the free exploration, we asked participants to write down questions they would like to explore with BitConduite. Participants wrote down 18 questions. We coded and clustered these questions into three general areas (linking, entities, trends) and five more specific topics (linking, single person entities, specific entities, behavior trends, temporal trends). Table III lists questions and categories.

#### Tool Use and User Experience

Next, we discuss results on how participants used BitConduite and their experience of trying to answer their own research question(s).

Interaction Logs. Interaction logs for each participant provide a first approximation of which system features they did or did not use. The logs consisted of a list of events per participant: the type of event (“interaction”), the timestamp, the object that was interacted with (“timechooser_filter”), and the value (e.,g., filter criteria). We extracted the number of times participants executed an event (through a mouse click), compared to the overall number of clicks, and compiled these proportions in an overview (Fig. 9).

Given that participants were interested in a large variety of different research questions it is not surprising that Fig. 9 shows a large variety in the proportions of interactions for each participant. While 5 out of 6 participants interacted with all views, participant P2 did not interact with the entity browser and the transaction view at all. The reason might be that this participant had questions (see Table III) for which detailed data on single entities and transactions was not useful. The filter view exhibited a large variety in the proportion of interactions (10%–50%); similarly for the entity browser (0%–55%). Overall, the transaction view was interacted with the least. There are several possible explanations for its diminished use: research questions may not require studying individual entities and their transactions; the view was at the bottom of the page; and we did not log all interactions with the timeline (e.g., changing the time range).

The interaction patterns show that all participants exhibited repeated sequences of switching between the filter and tree view (filter tree filter tree filter). This is not surprising because the filter view modifies the tree view but does show that our choice to place them visually next to each other worked well to reinforce the connection. Looking at our intended workflow for BitConduite (filter tree cluster; Fig. 4), we find that all participants used this sequence except P4. This participant exhibited technical difficulties and long delays and, therefore, his/her workflow was interrupted. Another typical sequence participants P3, P4, and P6 applied was filter cluster entity browser, meaning that they skipped modifying the tree view and just used the automatically selected group. From this data, we conclude that the participants used BitConduite the way we intended and participants used similar interaction strategies to analyze the data.

To complement the interaction log data, we also asked participants to write down their exploration strategies. Two participants (P4, P5) mentioned that they followed the tutorial instructions. Participant P1 used the filter view to find specific entities and groups as well as explored clusters and used these to drill down into the transactions of one entity. Participant P6 tried to focus on specific entities they had already identified (e.g., Bitminter and Mt. Gox). These strategies are reflected in the interaction logs. Participant P2 and P3 did not answer this question.

User Experience. In our exit questionnaire, we asked participants to rate BitConduite regarding different aspects (Fig. 10). No participant found the system unnecessarily complex. One participant agreed and one was neutral that they would need further support to use the tool. Similarly, one participant agreed with the statement that they needed to learn many things before its use. All but one participant were confident with using the system, found it easy to use, its functionality well integrated, and would use BitConduite more frequently. We also asked participants what they saw as the strength of the tool and whether they had suggestions for improving BitConduite. Participants answered that one strength of BitConduite was the “exploration of huge amounts of data” (P1); that it is “easy to understand and to use” (P3); it shows “a lot of data and information on screen” (P4), that it has “a workflow which makes sense” (P4); it has “[m]any small charts that help having an overall visualization” (P5); and “[i]t provides cluster analysis on already identified entities” (P6).

Participants also mentioned that BitConduite could be improved by adding “…filters based on frequency…” (P1); “a geographical origin for all transaction to get a map” (P3); “when presenting the tools, tell a discovery story” and “explain k-mean” (P4); as well as adding a “network visualization” and “the possibility to export data” (P6). These results are encouraging for future development.

In addition to their effectiveness answering their research questions, we also wanted to know if participants identified data that was new and surprising to them. Participant P1 “found specific outliers and …was amazed by the amounts of BTC exchanged.” This participant (P1) also mentioned that “there [were] a lot of one time entities” and wondered if “they [were] one time users or errors on entity clustering.” Participant P6 replied that “[c]oncerning Bitminter [a supposed pool of miners], there is always 1 outgoing address. I expected that block rewards were spread across all miners of the pool.” Participant P3 found that especially the clustering offered new and surprising results. Despite the inability of BitConduite to help with several of the participants’ questions, it is interesting to note the positive responses to the user experience-related questions reported above. It is likely the ability to see data in new ways and perhaps discover new aspects of the Bitcoin blockchain that led to positive responses about the system.

## 7 Discussion

BitConduite’s preliminary evaluation revealed the usefulness of its approach for answering questions related to entities rather than addresses—as well as questions that require larger-scale instead of small-scale analyses only as other tools provide. Still, we identified two major limitations related to our approach. One refers to the correctness and expression power of the data, the other to our analysis approach in the current form.

Data. The first limitation when it comes to the data we used is the role of entity building. We cannot expect the entities to be entirely correct and it is hard to estimate the quality of this information because the amount and quality of ground truth data are not sufficient. Tagging with information about known entities, however, can be useful to make sense of the activity of specific entities. However, most tags refer to the big players only, as Lischke and Fabian [26] pointed out in their analysis of the first four years of Bitcoin: “Even though 54% of all transactions could be related to a business tag and category, only 1.5% of them are not associated to the major businesses SatoshiDICE, Mt.Gox, or Deepbit.” Looking at the compression ratio of using entities vs. using addresses, during 2009–2001, the ratio is only . However this ratio is misleading because most of the entities (85%) were “one-timers”, something that an address-based analysis would not have revealed so easily.

Approach. The goal of BitConduite’s development was to support exploratory analysis of entity activities. Technically, this approach requires flexible computation of activity measures, which causes limitations with respect to scalability. While we tried to keep data processing times in the range of a few seconds the main bottleneck is the on-the-fly clustering that can take minutes in the worst case (if many entities are clustered at once). Here, a progressive clustering strategy may help where entities are not clustered all at once but intermediate clustering results are being displayed [18].

A major challenge in our approach is the aggregation of entities, which is computationally expensive and has a large memory footprint in our implementation. In the future, data providers could perform the aggregation operation. Google, for example, has recently started to distribute blockchain data maintained directly from its cloud infrastructure [15]. When aggregated entities become recognized as important for analysis, cloud data providers might similarly make regularly updated clustered data easily available.

Participants asked for additional data and certainly further information could be added to enrich analyses. For instance, other approaches (Sect. 3) included information about geographic locations of addresses or entities. We did not include this information in BitConduite because of its questionable quality. Geographic information is usually derived from the IP address of the last gateway before access of the blockchain. This is highly vague because the last address before the blockchain does not have to belong to a Bitcoin user. In addition, only a low fraction of transactions can be geotagged with existing strategies (e.g., in an analysis by Lischke and Fabian [26] around 1.6% of all transactions). There are other strategies such as recursive scanning of Bitcoin nodes [8] but in general, geographic information about Bitcoin nodes is not a reliable source for analyses.

Implications. Based on BitConduite and future extensions, we are hopeful that more research can reveal how cryptocurrencies are used in the real-world, beyond the vague and sensational information reported in the news only based on aggregated statistics or anecdotes from police reports. Yet, BitConduite relies heavily on the capability of aggregating addresses meaningfully, which can become harder due to the development of complex mechanisms to increase anonymity in Bitcoin. As a reaction to anonymity issues, there are mixing services or tumblers (e.g., Coinmixer [14]) that redistribute Bitcoins in a pool of users so that the sending addresses of a transaction are not directly linked to the target addresses anymore. Past research has shown that this strategy can be an effective way to increase anonymity [33]. We believe these mechanisms will merely increase the uncertainty related to certain entities, but because our goal is not to detect crime, BitConduite might still be usable for exploring transactions not related to criminal activity.

## 8 Conclusion and Future Work

We presented BitConduite, a tool for exploratory visual analysis of activity on the Bitcoin blockchain. It consists of a data back end and a graphical browser-based interface as a front end comprising five linked views (filter view, tree view, cluster view, entity browser, and transaction view, see Fig. 1).

Our main novel contribution is to make in-depth visual exploration of Bitcoin entity activity possible, lowering the threshold for analyses especially for analysts without the technical background to prepare and handle the data for analysis. In addition, instead of providing the raw data, we facilitate analyses based on aggregated addresses (entities) over large-scale time periods. An important part of our workflow involves systematic and reproducible classification of entity activities using filtering coupled with a tree representation of to characterize groups of entities. Human-assisted clustering helps to group entities with similar activity. Starting with large scale analyses it is possible to drill down and retrieve detailed information on single entities and display their transactions on a timeline.

In two use cases we demonstrated how BitConduite can help characterize entity activity in two different settings. The first use case focused on the early years of Bitcoin and compared the amount of entities with only a single transaction per year. Analysis of the most active entities showed that the concentration of activity already took place in the first years. The second use case dealt with a specific event, the halving day in 2016. A closer look at the months before and after this day revealed that about 85% of the active miners before the halving day did not continue in the month after this event. This revealed the impact of the event on mining behavior. Both use cases demonstrate that BitConduite makes rather complex analyses relatively straightforward for the analyst, compared to existing approaches.

During a workshop with Bitcoin experts we learned that several research questions they had could easily be answered using the BitConduite tool (e.g., about trends and outliers in activities, or mining behavior). Questions regarding temporal trends could not be answered (e.g., seasonality in the use) and pointed out a limitation of the approach. Ratings concerning BitConduite’s usability (confidence, ease-of-use, learnability) were predominantly positive. In particular, the integration of functionality in the GUI obtained high ratings and overall, five out of six experts claimed they would like to use BitConduite more frequently.

Several limitations of our approach stem from the limited expressiveness of the data. Aggregation of addresses to entities provides a new perspective but introduces uncertainty that cannot be quantified reliably at this stage due to missing ground truth information. One way to decrease the uncertainty would be to include more external information such as tagging of entities. However, at the moment tagging has limited expression power.

The workshop showed that the most important extension of our work is a more convenient comparison of temporal patterns. An additional view could be integrated into the workflow, for instance in form of a radial chart or similar to facilitate comparison of activity patterns over different time periods. Another useful extension would be to provide similarity search, i.e., suggestion of entities that are similar to a specific entity of interest. Lastly, future work will be to add the capability to track addresses and individual entities by integrating the functionality we demonstrated in a separate tool called the Blockchain Entity Explorer [23].

### References

1. E. Androulaki, G. Karame, M. Roeschlin, T. Scherer and S. Capkun (2013) Evaluating user privacy in bitcoin. In Conference on Financial Cryptography and Data Security, pp. 34–51. Cited by: §2, §3.1.
2. S. Athey, I. Parashkevov, V. Sarukkai and J. Xia (2016) Bitcoin pricing, adoption, and usage: theory and evidence. Technical report Technical Report Research Paper No. 16-42, Stanford University Graduate School of Business. External Links: Link Cited by: §3.1.
3. S. Bistarelli and F. Santini (2017) Go with the—bitcoin—flow, with visual analytics. In Conference on Availability, Reliability and Security, pp. 38:1–38:6. External Links: Document Cited by: §3.2.
9. T. Blascheck, M. John, K. Kurzhals, S. Koch and T. Ertl (2016) VA: a visual analytics approach for evaluating visual analytics applications. IEEE Transactions on Visualization and Computer Graphics 22 (1), pp. 61–70. Cited by: §6.1.
12. J. Bonneau, A. Miller, J. Clark, A. Narayanan, J. Kroll and E. Felten (2015) SoK: research perspectives and challenges for bitcoin and cryptocurrencies. In IEEE Symposium on Security and Privacy, pp. 104–121. External Links: Document Cited by: §2.2, §5.2.
13. E. Brown, A. Ottley, H. Zhao, Q. Lin, R. Souvenir, A. Endert and R. Chang (2014) Finding Waldo: learning about users from their interactions. IEEE Transactions on Visualization and Computer Graphics 20 (12), pp. 1663–1672. Cited by: §6.1.
14. Coinmixer - bitcoin mixing service. External Links: Link Cited by: §7.
15. A. Day and C. Bookman (2018) Bitcoin in BigQuery: blockchain analytics on public data. Note: Google Cloud Blog External Links: Link Cited by: §7.
16. G. Di Battista, V. Di Donato, M. Patrignani, M. Pizzonia, V. Roselli and R. Tamassia (2015) Bitconeview: visualization of flows in the bitcoin transaction graph. In IEEE Symposium on Visualization for Cyber Security, pp. 1–8. External Links: Document Cited by: §3.2.
17. D. Di Francesco Maesa, A. Marino and L. Ricci (2017) Data-driven analysis of bitcoin properties: exploiting the users graph. International Journal of Data Science and Analytics 6 (1), pp. 63–80. External Links: Document Cited by: §3.1.
18. J. Fekete and R. Primet (2016) Progressive analytics: a computation paradigm for exploratory data analysis. CoRR abs/1607.05162. Cited by: §7.
19. M. Fleder, M. Kester and S. Pillai (2015) Bitcoin transaction graph analysis. CoRR abs/1502.01657. Cited by: §3.1.
20. H. Guo, S. Gomez, C. Ziemkiewicz and D. Laidlaw (2016) A case study using visualization interaction logs and insight metrics to understand how analysts arrive at insights. IEEE Transactions on Visualization and Computer Graphics 22 (1), pp. 51–60. Cited by: §6.1.
21. M. Harrigan and C. Fretter (2016) The unreasonable effectiveness of address clustering. In Conference on Advanced and Trusted Computing, pp. 368–373. Cited by: §5.1.2.
22. J. Herrera-Joancomartí (2015) Research and challenges on bitcoin anonymity. In Data Privacy Management, Autonomous Spontaneous Security, and Security Assurance, Cited by: §3.1.
23. P. Isenberg, C. Kinkeldey and J. Fekete (2018) Exploring entity behavior on the bitcoin blockchain. Note: VIS 2017 - IEEE Conference on VisualizationPoster Cited by: §8.
24. C. Kinkeldey, J. Fekete and P. Isenberg (2017-06) BitConduite: Visualizing and Analyzing Activity on the Bitcoin Network. Eurographics. Note: EuroVis 2017 - Eurographics Conference on Visualization, Posters TrackPoster External Links: Link Cited by: §1.
25. Wikipedia: legality of bitcoin by country or territory. External Links: Link Cited by: §1.
26. M. Lischke and B. Fabian (2016) Analyzing the bitcoin network: the first four years. Future Internet 8 (1). External Links: Document Cited by: §3.1, §7, §7.
27. D. McGinn, D. Birch, D. Akroyd, M. Molina-Solana, Y. Guo and W. Knottenbelt (2016) Visualizing dynamic bitcoin transaction patterns. Big data 4 (2), pp. 109–119. Cited by: §3.2.
28. S. Meiklejohn, M. Pomarole, G. Jordan, K. Levchenko, D. McCoy, G. Voelker and S. Savage (2013) A fistful of bitcoins: characterizing payments among men with no names. In Proceedings of the Conference on Internet Measurement, pp. 127–140. Cited by: §3.1.
29. M. Mettler (2016) Blockchain technology in healthcare: the revolution starts here. In Conference on e-Health Networking, Applications and Services, pp. 1–3. Cited by: §1.
33. M. Möser (2013) Anonymity of bitcoin transactions. In Proceedings of the MÃ¼nster Bitcoin Conference, Cited by: §7.
34. S. Nakamoto (2008) Bitcoin: a peer-to-peer electronic cash system. External Links: Link Cited by: §1.
35. A. Narayanan, J. Bonneau, E. Felten, A. Miller and S. Goldfeder (2016) Bitcoin and cryptocurrency technologies: a comprehensive introduction. Princeton University Press. Cited by: §1, §2.1, §5.2.1.
36. NetworkX Software for Complex Networks. External Links: Link Cited by: §4.2.1.
37. M. Ober, S. Katzenbeisser and K. Hamacher (2013) Structure and anonymity of the bitcoin transaction graph. Future Internet 5 (2), pp. 237–250. Cited by: §3.1.
38. Pandas python data analysis library. External Links: Link Cited by: §4.2.
39. Python interface to bitcoin json-rpc api. External Links: Link Cited by: §4.2.
40. F. Reid and M. Harrigan (2013) An analysis of anonymity in the bitcoin system. In Security and Privacy in Social Networks, External Links: Document Cited by: §2, §3.1, §4.2.1.
41. D. Ron and A. Shamir (2013) Quantitative analysis of the full bitcoin transaction graph. In International Conference on Financial Cryptography and Data Security, pp. 6–24. Cited by: §3.1.
42. Scikit-learn machine learning in python. External Links: Link Cited by: §4.3.3.
43. B. Shneiderman (1996) The eyes have it: a task by data type taxonomy for information visualizations. In Symposium on Visual Languages, pp. 336–343. External Links: Document Cited by: §4.4.
44. M. Spagnuolo, F. Maggi and S. Zanero (2014) Bitiodine: extracting intelligence from the bitcoin network. In International Conference on Financial Cryptography and Data Security, pp. 457–468. Cited by: §3.1.
45. M. Swan (2015) Blockchain: blueprint for a new economy. O’Reilly Media, Inc.. Cited by: §3.
46. I. Takashima (2018) Litecoin: the ultimate guide to the world of litecoin, litecoin crypocurrency, litecoin investing, litecoin mining, litecoin guide, cryptocurrency. CreateSpace Independent Publishing Platform. Cited by: §1.
48. S. Underwood (2016) Blockchain beyond bitcoin. Communication of the ACM 59 (11), pp. 15–17. External Links: Document Cited by: §1.
49. WalletExplorer: bitcoin block explorer. External Links: Link Cited by: §2.1, §4.2.2.
50. G. Wood (2014) Ethereum: a secure decentralised generalised transaction ledger. Ethereum Project Yellow Paper 151, pp. 1–32. Cited by: §1.
51. J. Yli-Huumo, D. Ko, S. Choi, S. Park and K. Smolander (2016) Where is current research on blockchain technology? A systematic review. PloS one 11 (10), pp. e0163477. Cited by: §1.
52. X. Yue, X. Shu, X. Zhu, X. Du, Z. Yu, D. Papadopoulos and S. Liu (2018) BitExTract: interactive visualization for extracting bitcoin exchange intelligence. IEEE Transactions on Visualization and Computer Graphics 25 (1), pp. 162–171. External Links: Document Cited by: §3.2.
You are adding the first comment!
How to quickly get a good reply:
• Give credit where it’s due by listing out the positive aspects of a paper before getting into which changes should be made.
• Be specific in your critique, and provide supporting evidence with appropriate references to substantiate general statements.
• Your comment should inspire ideas to flow and help the author improves the paper.

The better we are at sharing our knowledge with each other, the faster we move forward.
The feedback must be of minimum 40 characters and the title a minimum of 5 characters

402447

How to quickly get a good answer:
• Keep your question short and to the point
• Check for grammar or spelling errors.
• Phrase it like a question
Test
Test description