Campbellsville University Cryptocurrencies Bitcoin Economics Discussion Please review attached articles and In 500 words Discuss the, “Bitcoin Economics”Co

Campbellsville University Cryptocurrencies Bitcoin Economics Discussion Please review attached articles and In 500 words Discuss the, “Bitcoin Economics”Content: Sufficient detail and you provided to support assertions; factually correct.Analysis: Organizes and synthesizes evidence to reveal insightful patterns, differences, or similarities related to the question.Conclusions & References: States a conclusion that is a logical extrapolation from the analysis of evidence/data presented.Use a minimum of 2 references from google scholar, APA format rsos.royalsocietypublishing.org
Toward Open Data
Blockchain Analytics: A
Bitcoin Perspective
D. McGinn, D. McIlwraith and Y. Guo
Research
arXiv:1802.07523v1 [cs.CR] 21 Feb 2018
Article submitted to journal
Subject Areas:
e-Science, Analysis
Keywords:
Bitcoin, Blockchain, Open Data,
Graph Database, Data Mining,
Knowledge Discovery
Author for correspondence:
Dan McGinn
e-mail: d.mcginn@imperial.ac.uk
Data Science Institute, Imperial College London
Bitcoin is the first implementation of what has
become known as a ‘public permissionless’ blockchain.
Guaranteeing security and protocol conformity
through its elegant combination of cryptographic
assurances and game theoretic economic incentives, it
permits censorship resistant public read-write access
to its append-only blockchain database without
the need for any mediating central authority. Not
until its advent has such a trusted, transparent,
comprehensive and granular data set of digital
economic behaviours been available for public
network analysis. In this article, by translating
the cumbersome binary data structure of the
Bitcoin blockchain into a high fidelity graph
model, we demonstrate through various analyses
the often overlooked social and econometric benefits
of employing such a novel open data architecture.
Specifically we show (a) how repeated patterns
of transaction behaviours can be revealed to link
user activity across the blockchain; (b) how newly
mined bitcoin can be associated to demonstrate
individual accumulations of wealth; (c) through
application of the naïve quantity theory of money that
Bitcoin’s disinflationary properties can be revealed
and measured; and (d) how the user community
can develop coordinated defences against repeated
denial of service attacks on the network. All of the
aforementioned being exemplary benefits that would
be lost with the closed data models of the ‘private
permissioned’ distributed ledger architectures that
are dominating enterprise level development due to
existing blockchain issues of governance, scalability
and confidentiality.
1. Introduction and Prior Work
Bitcoin’s release in 2009 [1] heralded the introduction of
a novel distributed database technology that has become
known as blockchain. Reaching a fault tolerant
c
2018 The Authors.
Published by the Royal
Society under the terms of the Creative Commons
Attribution
License
http://creativecommons.org/licenses/
by/4.0/, which permits unrestricted use, provided the original
author and source are credited.
2
……………………………………………………
rsos.royalsocietypublishing.org R. Soc. open sci. 0000000
consensus on state has been a well researched distributed systems problem. But reaching such
a consensus without the need for any centralized identity management system is the solution
to this surprisingly overlooked problem that the invention of Bitcoin has presented. Bitcoin’s
resilience relies upon public read and write access to its blockchain database where such a
distributed store of publicly shared data presents many opportunities for increased access,
transparency and trust without the need for any further reconciliation effort between users
of the shared data. The Bitcoin protocol specification is defined by its open-source reference
implementation and its precise workings are well explained in many sources such as Bonneau et
al. [2] or Antonopoulos [3]. However, these pseudonymous trustless blockchain architectures as
currently implemented in Bitcoin or Ethereum come with significant challenges, such as their
inherent difficulty to scale and their leakage of (albeit obfuscated) private information.
In a fully trustless blockchain system, each participant must verify the activity of every
other participant – an inbuilt O(n2 ) scalability problem. It is well known that the Bitcoin
network currently suffers confirmation delays and becomes congested at ~4 transactions per
second (tps) and the Ethereum network becomes congested at ~17tps (compared to Paypal
which claims to handle 450tps on Cybermondays or Visa which claims to have tested up to
56,000tps). Proposals to scale Bitcoin to these global levels in the future involve a compromise
of its fully trustless nature by maintaining the original blockchain as a consolidated settlement
layer only, and introducing a second layer process of off-chain transaction verification between
trusted centralised counterparties known as the Lightning Network.
The leakage of private information on the Bitcoin blockchain is well studied and has, to date,
focussed on the deanonimization of pseudonymous bitcoin transactions. Reid & Harrigan[4]
first took the approach of associating bitcoin address tokens to unique users by splitting the
blockchain into two graph structures: a transaction network and an address network, using
the former to abstract the latter into an implied user network. Both Androulaki et al.[5] and
Meiklejohn et al.[6] took a similar approach by splitting the blockchain into two graphs and using
the associative information leaked by the shared inputs of multi-input transactions, along with
information derived from ‘shadow’ addresses used for change amounts, to derive a consolidated
graph of unique entity transactions. Ron & Shamir[7] also collapsed the transaction and address
graphs into an abstract entity graph whose purpose was to explore its network properties rather
than deanonimization. The literature in this area has become notably more sparse as the data
has grown to become more unwieldy. Such established privacy deficiencies have however led
to the development of more private systems such as ZCash that, whilst maintaining a public
permissionless blockchain architecture, employs a zero knowledge protocol to guarantee privacy,
albeit at increased computational cost. However whilst ZCash aims for the computationally
secure secrecy of shielded transactions, Qesnelle [8] showed how its transactions can be associated
together through behavioural patterns of usage.
To mitigate against these scaling and privacy problems, whilst also avoiding the additional
resources required for zero knowledge protocols or the expensive consensus mechanisms
associated with public permissionless architectures, enterprise-level blockchain solutions
currently in development are gravitating towards a private permissioned blockchain model of
walled-garden data-silos with access controlled by gatekeepers, as shown by the brief review
shown in Table 1.
Corda (R3)
Digital Asset
Holdings
Hyperledger
Fabric
Hyperledger
Sawtooth
Monax
a
Limited public information although the Utility Settlement Coin project is
limited to 12 members of a private consortium. a
“Corda is designed for semi-private networks in which admission requires
obtaining an identity signed by a root authority…There is no global broadcast
at any point.” b
“The Digital Asset Platform Distributed Ledger layer is a permissioned ledger
accessible (for reading or writing) only by known and pre-approved parties.”c
“Hyperledger Fabric is a platform for distributed ledger solutions…is private
and permissioned…the members of a Hyperledger Fabric network enrol through
a Membership Service Provider.” d
“Hyperledger Sawtooth is an enterprise blockchain platform for building
distributed ledger applications and networks…Sawtooth is built to solve the
challenges of permissioned (private) networks.” e
“Monax was the first to market with a permissionable blockchain which
kick started enterprise interest…Permissioned blockchain networks differ from
unpermissioned blockchain networks solely based on the presence of an access
control layer built into the blockchain nodes.” f
https://www.clearmatics.com/utility-settlement-coin-pioneering-form-digital-cash/
b
https://docs.corda.net/_static/corda-technical-whitepaper.pdf
c
http://www.the-blockchain.com/docs/Digital%20Asset%20Platform%20-%20Non-technical%20White%20Paper.pdf
d
https://hyperledger-fabric.readthedocs.io/en/latest/blockchain.html#what-is-hyperledger-fabric
e
f
https://sawtooth.hyperledger.org/docs/core/releases/latest/introduction.html
https://monax.io/use_cases/finance/
These commercial private permissioned approaches, however, negate many of the prime
benefits of blockchain technology: namely the trust, transparency and socio-econometric benefits
of an open data model, some of which we demonstrate here.
In this article we demonstrate the full advantage presented by the open data nature of
the Bitcoin blockchain: never before has a financial transaction data set of such granularity
and longevity been available for public study. We present our exploration of this open data
to develop the new field of ‘blockchain analytics’ in order to understand dynamic behaviours
within blockchain systems. By modelling the cumbersome native blockchain data as a high
fidelity graph described in Section 2, we demonstrate how traversals of the public Bitcoin data
set can derive socially useful personal and econometric information not envisaged by the original
data model. In Section 3 we make the first attempt to visualize and detect associated patterns
of transactional behaviour across the entire blockchain using a path dependent query facilitated
only by the adoption of the graph model we describe. We then deploy our graph in consideration
of the ‘coinbase’ transactions of each block: transactions specially crafted by the successful miner
creating new amounts of bitcoin awarded to themselves as a reward for their validation work
and the method by which the bitcoin economy is inflated. Through a combinatorial analysis
of coinbase-spending transactions and their disposable extranonce bytes buried deep in the
coinbase raw data, Section 4 shows how confidence in wealth accumulation attributed to the
founder and early adopters can be increased. In Section 5 we develop a simple measure to explore
the velocity of circulation within the bitcoin economy and examine its impact on future price
moves. We round off our set of analyses in Section 6 by demonstrating how transaction patterns
associated with denial of service attacks on the bitcoin network can be identified and used by
the community to defend against such attacks.
……………………………………………………
Clearmatics
3
rsos.royalsocietypublishing.org R. Soc. open sci. 0000000
Table 1. At the enterprise level, there is a clear design evolution toward a private permissioned distributed
ledger architecture for reasons of governance, commercial confidentiality, regulatory compliance and
computational simplicity.
The core of the Bitcoin system is the blockchain: a continuously appended publicly distributed
database storing immutable, verified records of all bitcoin transactions since system inception. A
copy of this data structure is stored and grown locally by each full network peer in a sequential
series of proprietary format binary data files exemplified by the de facto reference implementation
of the Bitcoin protocol. Whilst the raw blockchain presents a complete and granular transactional
data set for analysis, the binary and sequential nature of this unindexed data makes direct
analysis impossible and we must look for an appropriate secondary data store informed by the
structure of the data itself. To appreciate the task at hand, an example dissection of a block of
this raw binary data with its non-trivial encapsulation, lack of primary keys, implicit metadata
and heterogeneous byte ordering is presented at Appendix A.
We now turn to look at the relationships presented by the components of the data set. The
integrity of the blockchain is predicated upon the computational work done by the miners in
solving each block, adding upon the work having already been expended in solving the previously
mined block, and each other block before it. Thus each new block is related to each prior block
in the chain. Each valid transaction broadcast into the system becomes related to the particular
block into which it is first successfully mined. Furthermore each transaction is composed of any
number of inputs and outputs, and each input is related to a corresponding and pre-existing
unspent output belonging to its own transaction and block, ordered at a prior point in the
blockchain. Each spending output/input pair is also necessarily related to one or more bitcoin
addresses representing the public key component of the private key required to authorise a change
of ownership. Each output records an amount of bitcoin and a cryptographic challenge expressed
in an executable, stack-based script which is required to be married to the cryptographic solution
contained in a corresponding script of the input to the valid spending transaction. There is no
limit to the number of transactions that miners may decide to include in a block, but historically
an arbitrary limit on the size of data in a block has applied to prevent abuse of the system
(originally 32MB, reduced to 1MB in 2010, and a cap of similar order exists currently after the
introduction of Segregated Witness).
This unstructured tangle of data relationships between blocks, transactions, inputs, outputs
and addresses naturally lends itself to a graph representation for efficient query traversal
and pattern recognition. Indeed previous work has analysed sub-graphs of the full data set,
particularly with regard to the associations of identities through the abstracted relationships
between addresses and transactions [4–6]. For the purposes of knowledge discovery we propose
the graph model described in Figure 1, which refrains from abstracting information away and
retains the full fidelity of the raw binary data of the blockchain whilst making for efficient query
traversals that would be computationally limiting for a tabular relational database. Also stored
in our graph model (not shown in Figure 1) are vertices to represent each of the data files and
the corresponding byte offset of each block and transaction within those files for easy recourse
to the raw binary data and a graphical time tree to enable temporal analyses. The graph was
implemented in the popular open source graph database Neo4j Community Edition.
……………………………………………………
2. High Fidelity Graph Model
4
rsos.royalsocietypublishing.org R. Soc. open sci. 0000000
In conducting these analyses we highlight examples of the transparent benefits of the public,
yet secure, open data model that blockchain technology can afford, which would be lost in any
private permissioned blockchain implementation.
5
……………………………………………………
rsos.royalsocietypublishing.org R. Soc. open sci. 0000000
Figure 1. Example portion of the graph model of the Bitcoin blockchain showing the relationships between
blocks, transactions, their inputs, outputs and associated addresses. The figure shows the source and
destination components reflecting the spending of B61 in the second transaction mined into Block#496,
whose identifying hash is highlighted in red.
Implementation
The first step in implementing the graph model was to parse the raw binary data files, each
sequentially containing around 128MB of blockchain data such as that at Appendix A. To this
end we wrote a custom C++ parser to consume and quickly deserialize the binary data files in
parallel on a 400 core HPC cluster[9] into an intermediate format in preparation for import into
Neo4j.
The period of the blockchain data in which we are interested is from its genesis, to shortly after
the second halving of the block reward (each halving event occurring according to the Bitcoin
protocol every 210,000 blocks). Constrained by resources we arbitrarily chose to model 425,000
blocks given the second halving event occurred shortly before at Block#420,000, therefore
extracting almost 8 years of transactional data to 13 August 2016. In our particular local
copy of the blockchain, Block#425,000 was written into the data file blk00596.dat, standing
Number of Blocks
Number of Transactions
Number of Inputs
Number of Outputs
Number of Addresses
Data size binary (MB)
Data size Neo4j (MB)
425,000
148,967,063
386,925,089
428,714,233
196,560,158
79,924
519,792
In the following sections we demonstrate how such a granular graph model can be traversed
and interrogated to reveal less obvious insights into the relationships within the Bitcoin data
set.
3. The Bitcoin Blockchain: A Visual History
Our aim in this section was to stress the graph database with a single query that would be
forced to touch most vertices in the graph, and in so doing to create the first visualization of
patterns of activity across the whole blockchain.
The query considers each input to each transaction in each block, and asks from which
historical block did each input amount of bitcoin originate? This allows us to inspect the source
block (and approximately therefore the time at which it last changed hands) of each amount
of bitcoin transacted in each block, which allows the examination of anomalous patterns of
behaviour and as we will see in Section 5 to explore the velocity of circulation characteristics
within the Bitcoin economy.
Referring to Figure 1 it is easy to see how this query is built in the pattern matching query
language ‘Cypher’ native to Neo4j, as shown in Figure 2:
Figure 2. Cypher graph query touching all vertices to visualize source/destination flows between blocks
across the entire blockchain.
……………………………………………………
Table 2. Summary statistics of vertices in the graph model.
6
rsos.royalsocietypublishing.org R. Soc. open sci. 0000000
atop an accumulation of 80GB of raw data files. The files naturally exhibit data parallelism
since the blocks and transactions they contain are unique and relate to each other through
unique identifiers. It is only the address data that occurs across multiple files, and this can be
rationalised in a simple post-processing step to remove data duplication.
Summary statistics of the scope of the resulting graph are shown in Table 2, which can
be considered a large graph on which to compute. The Neo4j instance was run on a 12core
virtual machine with 64GB RAM, with the allocated heap space configured to sustain concurrent
operations at 16GB, and 24GB allocated for the page cache. Inevitably the memory available
for the page cache results in a performance degradation due to swapping of data from disk, but
to avoid this would have required a recommended 595GB of RAM for the cache to hold the
entire graph resident in memory.
7
……………………………………………………
rsos.royalsocietypublishing.org R. Soc. open sci. 0000000
Figure 3. Full Bitcoin blockchain visualization as an adjacency matrix representation (edge-weighted by
colour) of the flow of bitcoin amounts between all blocks of the entire Bitcoin blockchain to Block#425,000,
designed for interrogation on our 130 megapixel data visualization facility, a navigable interactive version
of which is available at https://www.doc.ic.ac.uk/~dmcginn/adjmat.html
In order to avoid self-edges, we do not consider newly generated coinbase transactions nor
high frequency transactions whose inputs point to transactions within the same block. We also
normalize the amounts of bitcoin to be expressed as the percentage contribution to the whole
amount transacted within a block in order to account for large changes in volumes transacted
over time.
Since the Bitcoin blockchain of transactions is a directed acyclic graph it naturally lends itself
to an adjacency matrix representation, and since we only consider inputs from transactions prior
to the current block, it takes a strictly upper triangular form. We can now visualize this strictly
upper triangular adjacency matrix, with a logarithmically coloured heat-map by the percentage
contribution to each block, …
Purchase answer to see full
attachment