Creating A Fake Cryptocurrency Unit
Creating A Fake Cryptocurrency Unit
Creating A Fake Cryptocurrency Unit
12-2018
Recommended Citation
Pabba, Sai Venkatesh, "Creating A Fake Cryptocurrency Unit" (2018). Culminating Projects in Information Assurance. 72.
https://repository.stcloudstate.edu/msia_etds/72
This Starred Paper is brought to you for free and open access by the Department of Information Systems at theRepository at St. Cloud State. It has been
accepted for inclusion in Culminating Projects in Information Assurance by an authorized administrator of theRepository at St. Cloud State. For more
information, please contact [email protected].
Creating a Fake Cryptocurrency Unit
by
A Starred Paper
Master of Science
in Information Assurance
December, 2018
Page
Chapter
I. Introduction......................................................................................................... 7
Introduction .................................................................................................. 7
Summary.................................................................................................... 11
Introduction ................................................................................................ 12
Summary.................................................................................................... 32
Introduction ................................................................................................ 33
Summary.................................................................................................... 55
Introduction ................................................................................................ 56
Results ....................................................................................................... 61
Summary.................................................................................................... 62
Introduction ................................................................................................ 63
Discussion.................................................................................................. 63
Conclusions ............................................................................................... 64
References .................................................................................................................... 65
Appendix ....................................................................................................................... 68
5
List of Tables
Table Page
Figure Page
Introduction
introduced. These cryptocurrencies have attracted many investors. Bitcoin is the most
2017 (Higgins, 2017). This surge in the price of bitcoin was due to growing popularity
among the users and miners. Due to this increased popularity of cryptocurrencies, many
bitcoin ATM was installed in a coffee shop in Canada which allows users to convert
had started accepting bitcoin for payments since 2014, and since then many other
cryptography is used to generate and distribute currency units (Farell, 2015). The main
monetary systems, there will be a central authority (usually a bank) who overlooks the
entire system. This authority is responsible for maintaining verify, validate, and process
the transactions, log them, and lets the user know about the status of the transaction.
On the other hand, decentralized monetary systems have no such centralized system to
handle and monitor the transactions (Nakamoto, 2008). The main concept behind this
8
decentralized currency is the anonymity of the transaction. These kinds of systems are
The above figure shows the shares of different cryptocurrencies in the market.
Bitcoin takes the highest share of the market with 46% of the whole share which is
followed by Ethereum with a 20% share followed by Ripple with a 16% share. NEM
holds a share of 3%, Litecoin holds 2% of the share, and the rest hold about 13%
altogether.
9
Problem Statement
Cryptocurrency units usually have a value that is higher than most traditional
currency units. For example, a single bitcoin costs around 8000 US dollars. Given the
conversion rates, fake cryptocurrency units can cause a huge amount of loss to the
economy.
This research will help explore the attacks that involve creating an illegitimate
cryptocurrency unit by analyzing the algorithms involved in the cryptocurrency, find the
flaws in them to implement and prove that a fake cryptocurrency unit can be created.
Figure 2 shows the market cap of cryptocurrencies from April 2017 to April 2018.
The figure above shows the market cap of cryptocurrencies. The market is
almost about 750 billion US Dollars. Considering the amount of money involved in these
cryptocurrencies, adding a fake cryptocurrency unit to the system creates a huge loss to
cryptocurrency unit can be duplicated, they might no longer want to hold their crypto
10
coins and might decide to sell them. Lack of users will lead to a huge downfall in the
prices of these cryptocurrency coins thereby pushing legit users and investors into a
huge loss.
find out the vulnerabilities in them and determine how they would react to an attack
duplicate crypto coin using the details found from the research.
Research Questions
What are the different algorithms that are being used in cryptocurrency systems?
networks?
Are there any known vulnerabilities in the mechanisms that are being used to
If an attack is made on a node, how does the network handle the situation to solve
the problem?
Cryptocurrency networks are usually very huge and involve some thousands of
nodes forming the backbones of the network. These nodes usually have high
illegal and might incur a loss to some user to the cryptocurrency network.
Definition of Terms
duplicate cryptocurrency unit is something that gets added to blockchain against the
cryptocurrency protocol and gets into circulation in the network. It also talks about the
final objective.
Summary
cryptocurrency is and how important they are by introducing their market cap. It talks
about the research work that the paper concentrates on and the hurdles that should be
overcome for the research to succeed. The next chapter talks about the previous work
Introduction
networks, mechanisms involved in them and their working. This chapter also talks about
the previous literature related to the research area and provides an opinion about those
works.
The blockchain is a database which stores the transactions that were performed
blocks. These blocks contain the data related to the transaction and are linked to each
hashing algorithm. Every block in the chain contains the hash value of its previous block
thereby linking the blocks together. A single block can have multiple child blocks but can
have only one parent block (Singh & Singh, 2017). Each node on the network will
maintain a copy of this chain. In case of Bitcoin, on an average, a block gets added to
the chain for every 10 minutes (Kaushal, Bagga, & Sobti, 2017). As of 04/05/2018 19:00
The figure above shows the plot of the size of blockchain in megabytes to time in
years starting from 2009. As it can be understood from the figure, the size of blockchain
took a sudden surge from mid-2012, and since then it kept growing until it reached the
that only a minimal amount of data is put in each block along with a header. Hash of the
previous block and the hash of the entire data to be stored in the block along with the
difficulty level and the create coin transaction for the miner who added the block to the
chain.
14
The above figure shows the structure of part of a blockchain. The very first block
in the blockchain is called the Genesis block. Every block in the chain can have a
variable number of transactions. Usually, all the transactions that are generated in a 10-
minute period are put into a block. This number usually ranges from 1000 to 3000. A
Every block contains a header that describes the block, i.e., it contains the
metadata about the block, the transactions, Merkle root of the transactions. The hash is
generated from all these fields, and the block itself would be added to the chain by a
miner.
15
Table 1: Cryptocurrencies and hashing algorithms (source: https://bitcoinguide.online)
keys associated with a cryptocurrency user. These wallets are responsible for storing
the private keys of a user securely. It is very important that these private keys remain
private because anyone who knows the private key can access all the crypto coins of a
user and if a user loses access to his private key, he won’t be able to access his crypto
Every user of a cryptocurrency has a public address associated with it. This
address will be used by the blockchain to identify the user. When the user decides to
perform a transaction, which may be buying some crypto coins for himself or sending
crypto coins to some other user, the transaction will contain the public address of the
sender, receiver and the amount that must be sent. This entire transaction is then
signed by using the user’s private key which will be validated by the nodes in the
So, as explained earlier, if a user loses his private key, he will lose access to his
entire cryptocurrency as he no longer has a private key that is associated with the coins.
Once the nodes in the network have validated the transaction, it is put into a block
which in turn is added to the blockchain. To calculate a user’s balance, all the
transactions associated with the user’s address are to be collected from the blockchain
When a user who has a wallet creates a transaction, this transaction will be
verified by the nodes in the network. This process of verifying a transaction and adding
it to the blockchain is called mining. Mining is done by miners who turn a huge volume
of data into a hash of fixed length. Other miners should then accept this hash in the
17
network. If most of the miners accept this hash, only then it will be added to the
blockchain (Singh & Singh, 2017). If a person tries to create a fake transaction, this
transaction cannot be validated by other miners and will be rejected. All that it would
When a miner successfully adds a block to the blockchain, the node gets
rewarded with some Bitcoins which are generated through a coin creation transaction
with the recipient address as the node’s address (Kaushal, Bagga, & Sobti, 2017). In
turn for verifying the transactions, the miners get to keep the rewarded coins generated
during the mining process. Whenever a user wants to perform a transaction, the user
will be charged a transaction fee which is proportional to the amount to of data being
added to the blockchain, and this transaction fee goes to the miner who adds the block
to the blockchain.
All the cryptocurrencies are based on the decentralized public ledger that is
append-only. If any false data gets appended to the chain, it can’t be removed from the
determine if something that is being added to the blockchain is indeed true. Consensus
algorithms provide such mechanism (Glazer, 2014). Double spending and Byzantine
Generals Problem are the problems faced by currency systems that can be solved
currency twice. Physical currency does not have the problem of double spending
because it is an entity and it must be exchanged to make a purchase but the same
18
doesn’t apply to internet transactions. Cryptocurrencies solve this problem by verifying
the transaction by the nodes in the network (Yu, Shiwen, & Li, 2017).
It occurs when a node in the network is infected and is acting maliciously. So, there
In PoW, the miner must generate a hash using a random nonce and the data in
the transaction and the hash from the previous block satisfying a certain level of
difficulty. The network automatically adjusts the level of difficulty to compensate for the
hash rate. If the time taken to add a block takes less time than the expected time, then
the difficulty level is increased and vice versa (Sleiman, Lauf, & Yampolskiy, 2016).
The above figure shows the working of the Proof of Work consensus mechanism.
The upper part of the figure shows the working of the PoW systems at a very high level.
For a miner to add a block, he should take the hash from the previous block, the data of
the new block, Merkle root of the transactions and then the miner must select an
incremental nonce value and put it through a hashing algorithm to generate a hash. The
miner then compares this hash to the target value. If the hash value is less than the
target value then, the block is accepted and gets added to the chain. The target value is
calculated from a difficulty value which is set automatically by the network depending on
incentive that is rewarded in addition to the transaction fee. In PoW systems the
incentive rewarded to the miner gets halved for every four years, and when the
incentive is gone, the only motivation that miners will have is the transaction fee which
might lead miners to abandon mining completely (Tosh, Shetty, & Liang, 2018). The
PoW increases the wastage of computational power to make the mining difficult and it
might lead to a 51% problem and might eventually convert forging into a centralized
task.
The hashing algorithm that we will be using for this research is SHA-256 which is
the algorithm used by bitcoin. The steps involved in the SHA-256 algorithm are as
follows.
Preprocessing.
where l < 2⁶⁴, then we create the padded message M’ since SHA-256 can
3. To calculate the initial hash H0, square roots of the first eight prime numbers
are calculated. Since prime numbers never have a perfect number, the first
Hashing.
first block of Wⁱ is message block Mⁱ, and the next three blocks are variations
of Mⁱ.
22
2. The input blocks are then shuffled. The shuffle function takes a hash wi(t) and
message schedule input block W i(t) as inputs. The output of shuffle function is
the last block then, the hash Hⁱ produced can be considered as the final hash
Unlike Proof of work technique does not involve any incentive or intense
computation but instead for any user to be able to become a forger (one who mines
coins), he must hold a stake in the network by involving some of his coins. In this
mechanism, the forger puts his coins at stake and if the forger is involved in any
malicious behavior, all his coins, his ability to continue as a forger will be taken away
from him.
23
In PoS, the creator of a new block is chosen deterministically. The forger with
the highest stake will the given the highest priority to forge coins and the second priority
will be given to the one holding the second highest number of coins and so on. Simply
put, the percentage of blocks that can be forged by a forger will be the percentage of
coins that he owns in the whole network (Tosh, Shetty, & Liang, 2018).In PoS systems,
there is no incentive given to the miners. The number of currency units in the entire
network is fixed, and the same coins are circulated throughout the network. The miners
get to keep the transaction fee associated with a block upon successful addition of a
block to the blockchain. Ethereum is the most popular cryptocurrency which is switching
from PoW to PoS They designed a system namely Casper which provides some
1. Magic Number: This is a number that represents that the data contained in a
block. The number of transactions in the bitcoin block does not have any
included in the bitcoin block is limited by the size of the total block. The size of
4. Transactions: These are the transactions that are included in this block.
24
5. Block Header: This is the header that represents the block and used to
calculate the hash of the entire block by varying the nonce value.
1. Version: This indicates the version of the Bitcoin protocol being used.
3. List of Inputs: These are the list of inputs that are being used in the
transaction.
6. Lock time: Lock time is an integer and can be of two types. If its value is
greater than 500 million, it represents the time in epoch milliseconds after
which the transaction can be added to a bitcoin block. If this value is less than
500 million, it represents the number of blocks that should be added after the
2. Transaction Out-Index: This represents the index of the output the previous
3. Input Script Length: This represents the size of the input script.
4. Input Script: This is the script that proves that the output owner is legitimate.
25
5. Sequence Number: This number is used for replacement and is not currently
1. Value: This represents the amount that is being transferred for the current
3. Output Script: This is the script that that is to be satisfied by anyone who
1. Version: This represents the version of bitcoin that is used for the block.
2. Hash Merkle Root: This represents the Merkle root for the transactions.
3. Hash Previous Block: This represents the hash of the previous block to which
this block is to be linked in the blockchain. This value is the hash of the last
block in the blockchain. The hash is the field that makes the chain by linking
5. Target: The target value at the time of creation of this block. The hash of this
6. Nonce: It is an Integer and is the value that is altered by miners so that hash
of the block is less than the target. Miners typically start with a nonce value of
0 and keep incrementing it for each iteration until they obtain a hash value
specified by the Script instruction set. Below are few of the instructions used by bitcoin
scripts.
Word Description
OP_SIZE the stack. This operation does not pop the item on
the stack.
27
Results in 1 if both the items on the top of the stack
hash of each of the transactions. The order of fields for transaction hashing is version
number, input counter, list of inputs, output counter, list of outputs, lock time. The order
of fields for inputs is a previous transaction hash, output index, input script length, a
sequence number. The order of fields for outputs is value, output script length followed
by output script. All these fields are put together in the specified order, and a SHA-256
hash of the resulting string is calculated. When the miner is done calculating these
hashes, the miner calculates the hash Merkle root for all the transactions.
After obtaining the hash Merkle root for the transactions, the block header can be
hashed to get the final block hash. To calculate the block hash, the order of fields is
version, hash of the previous block, hash merkle root for the transaction set, time,
target, nonce. All these fields are put together and then they are hashed twice using
SHA-256 algorithm to get the final hash. It is important to remember that the byte
29
ordering followed by bitcoin systems is big endian. So, the byte ordering for the previous
For a block to be accepted to put in the block chain, the hash value of the block
should be less than the target value. To achieve this, miners alter the nonce and
recompute the hash every time making mining a computationally intensive task. Miners
usually start off at nonce 0 and keep incrementing it after every in-successful hash and
then calculate the hash after every incrementation until they reach the nonce when
included in the block makes the hash value lesser the target value.
Cryptocurrency Systems, the authors have explained the basics of cryptocurrencies and
the related terms. The paper starts off by explaining the origins of cryptocurrencies all
the way from Chaum creating the first anonymous electronic money system to the latest
cryptocurrencies that are based on blockchain technology. The paper talks about the
basic structure of bitcoin block, the Genesis block and how the links are formed
between the blocks at a very high level (Mukhopadhyay, Skjellum, & Hambolu, 2017).
The paper also talks about the different consensus mechanisms that can be used
mechanisms. The author talks about the working of 51% attack mechanism
(Mukhopadhyay, Skjellum, & Hambolu, 2017) and then discusses the different
involved in them.
30
In their paper, Zheng, Z., Xie, S., & Dai, H talked about cryptocurrencies and
blockchain technology on the whole. They introduced the structure of blockchain and
explained the link formation in the blockchain. The paper also talks about different
Then it discusses different issues with cryptocurrencies (Zheng, Xie, & Dai, 2017).
In Sleiman, M. D., Lauf, A. P., & Yampolskiy, R’s Bitcoin Message: Data Insertion
System (Warren, 2012). The authors chose to implement this concept by embedding
the encoded message inside the bitcoin’s blockchain by encoding the message as the
transaction amount and creating a transaction in the blockchain. This approach works
since it is a legit transaction transferring a certain number of bitcoins from one address
to another (Sleiman, Lauf, & Yampolskiy, 2016). But every time they want to send a
message, the message would be accompanied by a transaction fee that goes to the
miners for verifying the transaction and is a high cost for fulfilling the task of sending a
simple message and moreover there is no confidentiality involved as the data would be
posted to a publicly maintained blockchain and the encoding can be broken pretty
easily.
Innovations, they talked about the concept of bitcoin and its applications. The paper
introduces the concept of Blockchain powered health chain, a system where the details
data and blockchain can achieve it (Ahram, Sargolzaei, & Sargolzaei, 2017).
In Nayak, K., Kumar, S., & Miller, A’s paper Stubborn Mining: Generalizing
Selfish Mining and Combining with an Eclipse Attack, they discuss mining in a
approach and compare it to honest mining and how selfish mining affects honest
miners. They introduce the concept of stubborn mining which is an extension of selfish
mining. In selfish mining, a miner mines and keeps his blocks private when he is in the
lead and cooperates with the network if he is not in the lead. In Stubborn mining, the
miner keeps working on his private chain even when he is not in the lead (Nayak,
In Michael Bedford Taylor’s paper The Evolution of Bitcoin Hardware, the author
introduces the working of the bitcoin system. He then introduces what mining is and
how it works and how blocks are generated. The paper mainly focusses on the
hardware involved in the mining and introduces the audience to the concept of hash
rate and why it is important regarding mining and how it has a direct impact on the price
of bitcoin. The paper talks about how ASIC miners have changed the concept of mining
turning it into a race of power-hungry machines mining bitcoins (Michael Bedford Taylor,
2017).
about the consistency property of bitcoin. The paper quotes the bitcoin’s eventual
storage.” (Tseng, 2017). The paper provides a simple example transaction where
bitcoin protocol does not follow the eventual consistency property. The situation occurs
when the blockchain is empty and two miners a & b try to add transaction Ta, Tb to the
chain at the same time and the transactions get buffered at the chain and as each of
these miners have added only one block they will only have their block as the chain
Bag, S., Ruj, S., & Sakurai, K’s paper on Bitcoin withholding attack talks about
the withholding attack on bitcoin mining pools. The authors start off by explaining what
the bitcoin withholding attack is, and then they introduce a scheme which they used to
implement the withholding attack. Then they talk about the system model for sponsored
withholding attack. They provide mathematical proof for implementing the attack they
introduce their lemmas theorems, and corollaries to prove the attack is feasible. They
end the discussion by saying how a like-minded mining pool can be profited by the
Summary
how transactions are performed by the users and the involvement of miners in the
transaction to add it to the blockchain. It also explains how miners are benefitted from
mining operations. It introduces consensus mechanisms for mining and their working in
a great level of detail. The chapter ends with the past works done in the field of
cryptocurrencies.
33
Chapter III: Methodology
Introduction
This chapter describes the coin duplication attacks which will be implemented in
this study. This chapter describes how the simulation mechanism will be implemented to
create an attack environment and to implement the attack. The design and
implementation details of the attack will be discussed in detail. The chapter also
The research design is all about planning the overall strategy which can
effectively address different issues that come up during the implementation. The main
issue with implementing the duplication mechanism is the sheer number of nodes and
miners across the globe. The bitcoin mining network is gigantic regarding computing
power. All the miners involved in the network mine 24/7 to validate the chain. The
miners check each transaction that is added to the chain and ignore any fake
transactions.
To overcome this problem, the attack will be made on a simulation network which
following steps
system.
the network.
5. Install and configure the simulation on the nodes that were just created.
6. Setup the cryptocurrency system on the virtual machines and configure the
network.
7. Make a test run inserting a few blocks to make sure that the implementation
works.
The Proof of Work mechanism will be used as consensus mechanism for the
technique. In proof of work implementation, the miner gets new coins with the addition
of a new block to the blockchain in addition to transaction fees. In PoW, the miner must
generate a hash using a random nonce and the data in the transaction and the hash
from the previous block satisfying a certain level of difficulty. The hashes are tough to
generate but can be verified very easily by just computing the hash using the nonce and
comparing to the hash produced by the miner who added the block. For the simulation,
the difficulty level will be level so that the computational power of an ordinary machine
When the simulation is done, it is time to design the main attack. The design
1. There will be a node that has bitcoin daemon running on it. This will be a
2. Every node and miner in the bitcoin network communicate with each other by
4. The miner will be implemented to communicate to the node via http using the
insight-api.
5. The miner will make api calls to get the list of pending transactions from the
node. Since it is up to the miner to include any number of blocks, in this case
the list of transactions which is the block reward for mining the block
6. The miner then adds another transaction to the list of transaction which is
fake and would not be accepted by any other miners connected to the node.
In this case, there is only one miner connected to the node there by there
would be no one to complain about the fake transaction being added to the
block.
7. The miner then computes the hash merkle root of these transactions together
and then starts off by computing the hash of the block using a nonce value 0
and then keeps incrementing it until a valid hash value which is lesser than
8. When such a nonce is discovered, the miner stops and then reports the block
to the node. But there is a catch here. The amount added by these
36
transactions are valid only after the block reaches certain depth (In main-net it
9. The miner should add three more blocks to the chain before the bitcoins
added to the previous block are available for spending. Therefore, the same
process is repeated but without adding a fake transaction for three more
times. Therefore, the miner adds four blocks in total to the blockchain.
10. The node can be setup on a virtual machine running on a host because it is
just a storage node and doesn’t need much computation power. The miner on
the other hand must run on the host machine where the computational power
Stop
Yes
Add the coinbase transaction to the
obtained list of transactions.
Report the block to the node
The data needed for this research is algorithms and mechanisms that are used to
implement the cryptocurrencies. The data related to these implementations are freely
cryptocurrencies in detail. Also, the concept of a decentralized public ledger means that
all the transactions ever made are available to everyone who wants to analyze these
transactions. The details of the transaction amount, wallet address, the block hash, the
address of the miner who mined the block, the number of transactions included in a
Every year there will be conferences held on the security of cryptocurrencies and
the systems and analyze solutions to solve those vulnerabilities. IEEE is a standard
which conducts such surveys every year, and the details of conferences can be
To implement the attack, we need a target to attack. The real bitcoin network is
huge and is not easier to attack. There are miners guarding the network who are always
validating and verifying the transactions added to the network. There is a new block
being added to the blockchain for every 10 minutes and any fake transactions added to
the chain are just ignored by the miners and the transaction would never get added to
the blockchain. The bitcoin network can be attacked if the mining power of the attacker
is greater than that of all the miners combined. The miners have capacity to add a new
block every 10 minutes. If a legit miner adds a block to the chain before the attacker, the
40
node would propagate that block reported by the legit miner and the block reported by
the attacker would not be accepted because it is no longer valid as a similar block is
already added to the chain which has the hash of the same previous block and the
need to be implemented to perform transactions over the network. There are several
client applications which implemented the protocol. Anyone can join the network using
their own client application. There are several client applications that are freely available
(Bcoin, decred, btcd, Bitcore etc.). Bitcore is the most popular one that supports decent
features. Bitcore is an open source client written in java script. Bitcoin has 3 different
modes that it can run in. If Bitcore is run no additional flags, it runs in Mainnet mode.
The Mainnet is at least 160GB currently and to setup a node that uses mainnet,
all these blocks should be downloaded before any operations can be performed on the
chain. There is also a testnet which is like mainnet but only difference being that coins
from mainnet are not valid in the testnet and vice versa. The testnet is currently 16GB
which is far less than that of the mainnet. The testnet is mostly used by developers who
develop applications targeting bitcoin payments and for some other purposes. In the
test net too, there are miners who validate the transactions and it would be tough to add
fake transactions to the chain. Though attacks can be performed on the Testnet, it is
complicated and has been reset twice before. To overcome these problems, the attack
would be performed on a simulated network where there are no competitive miners and
the attacker can freely mine blocks and report them to the bitcoin node. Bitcoin also
offers one more called Simnet mode. In Simnet mode, the node is setup locally with no
41
connections to any other node from mainnet or testnet. A Bitcore node setup in simnet
mode is the perfect target for the attack as there would be no other miners involved to
Setup bitcore in simnet mode. Bitcore is a bitcoin client application written using
Nodejs. To install and to run Bitcore, we need to setup Node Version Manager
(NVM) and then install Node Package Manager (NPM) using NVM. When we have
NPM installed, we will also need python3 installed. We will also need to execute
With all the criteria met, we can install Bitcore by using npm by using the
command ‘npm install -g bitcore’. This command installs Bitcore globally across the
system. After the installation of Bitcore, we need to setup a node using Bitcore which
can be done easily using the command ‘bitcore create <node name> --simnet’. This will
make Bitcore download the block chain create a node with the given node.
42
(depends on the network type). The communication is done using some messages
these messages as we need to code all these messages and communicate over a
socket. Instead communicating over http would be easy. Insight API is a software
package that can be installed on top of Bitcore client. This provides a convenient http
API which offers different endpoints to get and post transaction and block data from the
node. Insight API can be installed using the command ‘bitcore install insight-api’ and
then when Bitcore is started, along with it starts the In-sight api.
To implement the attacking miner java language will be used. The reason for
choosing java over other programming language is due to the huge set of libraries that it
provides and making http calls using the libraries and converting the response from the
node into objects and vice versa is comparatively easy and non-clumsy. Gradle is used
43
for dependency management and as a build tool. Spring framework is used for
ApplicationContext ctx
= new AnnotationConfigApplicationContext(Miner.class);
fraudMiner.startMiners();
}
This is the main class that would be run by the gradle daemon. This class
creates the two necessary beans one of type OkHttpClient which will be used all over by
the application to make http calls. The other bean is of type ObjectMapper which is used
to convert json strings to objects and vice versa. This class also has the main method
which gets the bean of type MinerUtil which contains the code responsible for starting
the miner thread and then joins it to the main thread so that the application does not
terminate while this thread is still running. We will look at the MinerUtil class in a
moment. For now, it is class which has the miner implementation and the bean is
automatically created and managed by the spring container service. Bitcoin protocol
involves data exchange in hexadecimal format and Big-Endian byte ordering. The
application needs to convert this data back to data that can be worked with.
The application has a utility class named HexUtil that helps with these
conversions. All the methods of this class are public static methods. The first of them is
hexadecimal format. This method is used by the application to reverse the byte ordering
of a hexadecimal data and vice versa. This method works by decoding the hexadecimal
44
string to get a byte array which is reversed and then gets pushed to a byte buffer and is
then extracted from byte buffer, encoded and then converted back to string and
byte ordering of the input string and then converting the obtained value to a Long which
gets returned.
The TxIn class represents a transaction input to a transaction. The class has the
fields ‘previousTransactionHash’ which is of type String and represents the hash of the
previous transaction that is to be used as input for this transaction. The field
‘txOutIndex’ is of type String which indicates the output index in the output set of the
hexadecimal format. The field ‘txInScriptLength’ represents the length of the input script
for the specified input. This is a string that represents the length of the input script in
hexadecimal format. The field ‘txInScript’ represents the input script for the transaction.
It is a string containing the script which will be validated by the miner during the
transaction verification. The field sequence number is a string type field. In addition to
the above fields, this class overrides toString method to return the data in hexadecimal
The TxOut class is model class that represents the output of a transaction. This
class has the fields value which is of type String and represents the value of output in
satoshis (10-8 bitcoin) in hexadecimal format. This field follows Big Endian byte ordering
the size of transaction output script in bytes with big endian byte ordering. The field
txOutScript represents the output script which will be validated when a transaction
45
wants to use this output as an input. This too is in hexadecimal format with big endian
byte ordering. This class overrides the toString method from object class to combine all
the above-mentioned fields by reversing their byte ordering and returns the
concatenated string.
The Transaction class represents a bitcoin transaction. This class has the fields
versionNo which represents the version of bitcoin protocol being used in hexadecimal
format with big endian byte ordering. The field inCounter represents the number of
inputs to transaction in hexadecimal format with big endian byte ordering. The field
listOfInputs represents the inputs to this transaction. The field outCounter represents
the number of outputs from this transaction in hexadecimal format with big endian byte
ordering. The field listOfOutputs represents the outputs from this transaction. The field
lockTime is a string representing locktime and can be of two types. If its value is greater
than 500 million, it represents the time in epoch milliseconds after which the transaction
can be added to a bitcoin block. If this value is less than 500 million, it represents the
number of blocks that should be added after the block containing this transaction is
data += HexUtil.reverseByteOrdering(this.versionNo);
data += HexUtil.reverseByteOrdering(this.inCounter);
data += in.toString();
}
46
data += HexUtil.reverseByteOrdering(this.outCounter);
data += in.toString();
data += HexUtil.reverseByteOrdering(this.lockTime);
});
The class also contains a method calculateHash which is used to calculate the
SHA-256 hash of the transaction. This method works by reversing the byte ordering of
the list of inputs, the method uses the overridden toString implementation from TxIn
class which converts the fields from TxIn in the order previousTransactionHash,
get the list of outputs, the method uses the overridden toString implementation from
TxOut class which converts the fields from TxOut in the order value, txOutScriptLength,
txOutScript, and returns the concatenated string. It then applies SHA-256 on the hex
string twice and then reverses the byte ordering of the resultant hash and the final hash
of the transaction.
The BlockHeader class represents the block header of a bitcoin block. The fields
in this class are used to calculate the hash of the block. The version field represents the
47
version of bitcoin protocol used for this block. The field hashMerkleRoot represents the
hash merkle root of the transactions included in this block. The field hashPrevBlock
represents the hash of the previous block. The field time represents the time of creating
this block. The field target represents the target value during the block creation time.
The field nonce represents the nonce value used to achieve the target. All the fields
represented in this class are in hexadecimal format and follow Big Endian byte ordering.
The class also includes a method to calculate the hash of the block. This method starts
by reversing the byte order of the fields and concatenating them in the order version,
using SHA-256 hashing algorithm which in turn is encoded and byte order reversed to
get the final hash. This is the hash that is hash of the block containing this header.
data += HexUtil.reverseByteOrdering(this.version);
data += HexUtil.reverseByteOrdering(this.hashPrevBlock);
data += HexUtil.reverseByteOrdering(this.hashMerkleRoot);
data += HexUtil.reverseByteOrdering(this.time);
data += HexUtil.reverseByteOrdering(this.nonce);
});
}
48
The class Block represents a bitcoin block. The field magicNumber represents
the magic number of the bitcoin protocol. This field is always set to 0xD9B4BEF9 which
represents that the data included is bitcoin data. The field blockSize represents the size
transactions included in the bitcoin block. The field transaction represents the
transactions that are included in this block. The field blockHeader represents the header
all in hexadecimal format and follow Big Endian byte ordering. This class has method to
compute the merkle root of the transactions which is to be included in the block header.
The merkle root can be considered as the combined hash of all the transactions. To
calculate merkle root, hashes of each of the transactions are calculated and then the
hash of the first transaction is concatenated with the hash of the second transaction and
the SHA-256 of this combined hash is calculated. Then the same thing is done for the
next transactions and so on. This gives us a set of hashes once more and the same
process is continued on more levels until we end up with just one single hash and this
hash is called the merkle root for the set of transactions. It is important to remember that
bitcoin network has Big Endian byte ordering and this byte ordering of data must be
reversed before hashing. The method handles this by using the utility class’s methods.
(depends on the network type). The communication is done using some messages
these messages as we need to code all these messages and communicate over a
socket. Instead communicating over http would be easy. Insight API is a software
package that can be installed on top of Bitcore client. This provides a convenient http
API which offers different endpoints to get and post transaction and block data from the
node. To communicate with Insight-api, the application OkHttp library. The application
has a few client classes that help it communicate with the Bitcore node.
50
The TransactionClient class helps the application get the transactions from the
node. This class uses the two beans of types OkHttpClient and ObjectMapper
respectively that are maintained by the spring container. These beans are configured to
bean and managing it. This class has two methods namely getPendingTransactions and
of pending transactions and converts them into Transaction objects using the
objectmapper that was injected into the bean. The method listTransactions is
The BlockClient class has methods that help the application to get the blocks and
to report newly created blocks to the bitcoin node. The class is annotated with
spring application container. This class uses OkHttpClient to make http calls to
endpoints and this bean is configured to be autowired by the spring container. The class
has two methods namely getLastBlock and postBlock which help the application to get
the last block of the blockchain and to post a new block to the blockchain respectively.
posted to the block chain, converts the obtained JSON to Block object and then returns
51
it. The postBlock method makes a POST http call to http://ubuntuvm:8080/insight-
api/blocks with a new block data in JSON format to add a new block to the blockchain.
The class MinerUtil is the class that does the actual mining. The field
the spring container and is constructor injected into the MinerUtil bean which is also
TargetClient and is a bean managed by spring container. The field keys are a list which
contains the public and private key pairs. This list is populated by the method
creation. The fields are injected using constructor injection mechanism are autowired by
that generates two pairs of public, private keys and generates bitcoin addresses. The
first pair of keys is used to generate the script for coinbase transaction. The second set
of keys is used to generate the script for the coinbase transaction. This method is
annotated with @PostConstruct so that it gets executed soon after the MinerUtil bean’s
construction. This method uses a static method adjustTo64 which concatenates the key
with 0s before it. The method getBlockData uses the transactionClient bean to get the
list of pending transactions, current target, the lastly added block, then uses some of the
a1[i] = r2[i];
a1[20 + i] = s3[i];
Bitcoin network imposes a restriction on the block size. A block cannot exceed
1mb in size. This application limits the number of transactions to 20. The target client is
used to get the current target from the node It is a string target that gets returned from
the client and can be directly used to build the block. The method
into the block. This method uses the public key generated by
for the coinbase and fake transaction. The input script for these transactions is
OP_PUSH_DATA public key CHECKSIG. To use this output, the private key for this
that it uses the second public key to generate the script for the transaction. The method
startMining is the method which changes the nonce value in steps of 1 and calculates
the hash of the block. If this hash is more than the target value, the nonce is
incremented by 1 and hash is recalculated until a nonce which yields a hash less than
54
target is reached. This method starts off by getting the blockdata from the node and
then adds the coinbase transaction and fake transactions to the block and starts
calculating the hash starting with a nonce of 0 and incrementing in steps of 1. After
every iteration, the application compares the hash to that of the target. If the hash is
less than the target, it would be accepted by the node, so it would break out of the loop
insertCoinbaseTransaction(block);
if (i == 1)
insertFakeTransaction(block);
block.getBlockHeader().setNonce(HexUtil.formatLongAndReverseOrdering(nonce));
if (target.compareTo(hash) > 0) {
break;
}}
if (blockClient.postBlock(block).get())
}).start();
}
55
Summary
the design and approach that are taken to implement the attack. It discusses the
algorithms and consensus mechanisms that will be used to realize the objectives of the
research by overcoming the challenges. It also provides a brief walkthrough of the code
Introduction
This chapter talks focusses on analyzing the results of the attack implementation.
In the previous chapter, we discussed about the implementation design and provided a
walkthrough of it. This chapter provides details of the attack and shows screenshots of
the attack in various stages and provides a detailed information of the output produced
by the attacking miner. This chapter will also provide details related to the execution of
Data Presentation
The bitcoin node is setup on a virtual machine using Bitcore bitcoin client. The
host is named as ubuntuvm on the host machine. The miner will be run on the host
machine since it has more computational power when compared to the virtual machine.
The miner can be started by navigating to the directory and using the command java -jar
Miner.jar. This automatically starts the Mining operation and will continue running until 4
blocks are added to the blockchain. The node is setup to reduce the difficulty of mining.
Despite this lower difficulty, the mining operation takes huge amount of time
(approximately 2-3 hours for a single block). Starting the application automatically
initializes the spring application container from the main method and then gets the
MinerUtil bean from the spring application context and then starts the mining thread.
57
The application uses a separate thread to mine bitcoins since it is not considered
as a good practice to run computationally intensive tasks on the main thread. The
application spawns a new thread from the main thread and joins it with the main thread.
This thread as soon as it is started, makes api call to the Bitcore node to get the list of
transactions, creates a block using these transactions and then starts off the mining
process with a nonce 1 and then keeps incrementing it till it reaches a hash value that is
less than the target value. When the spring application context is initialized, MinerUtil’s
generateKeysAndAddresses method gets executed which generates the keys set and
the address to be used to generate the output script for the coinbase and fake
58
transactions respectively. The application logs these addresses to verify that the
The application does not log the keys used since the Bitcore node can be
queried by using the public addresses and do not need the keys for that. As explained
previously, the mining process starts off with a nonce value of 0 and keeps incrementing
for each of the rounds until a hash with lesser value is obtained.
59
Data Analysis
The application log is huge because it generates a log statement for each of the
nonce values and to generate a single block it takes at least 1 million iterations. So, it
logs at least 1 million lines for each block and four such blocks need to successfully add
a block containing fake transaction which means that in the best case it logs out 4
million lines which is a lot and the terminal buffer doesn’t have the ability to hold all
these log statements. During the development of this application, alternative options like
writing the logs to a different file was tried out but even that approach failed causing the
host system to run out of disk space. So, application was modified to printout the log
statements only when a block was successfully generated and reported back to the
node.
60
The screenshot above shows the output of the application after successful
mining of four bitcoin blocks. The target value obtained from the Bitcore node is
0000000ad1dc95ccd01aa8c835da2e8a1ebc30ac707cb991199a5d26ca652741. The
nonce value used for the blocks are 166213763, 860207930 and 1082383936
respectively. According to the bitcoin protocol, any funds added by a block are only
available only after the block containing the transaction reaches certain depth. In the
main chain, this depth should be at least 6 meaning that funds added by a transaction
are only available when the block containing this transaction is at depth 6. In the main
chain, a new block gets added to the chain every 10 minutes. So, after a new
transaction is added to the chain, it takes at least 1 hour for the funds to be available for
61
spending. In Reg test mode, this depth is 4 blocks. So, a fake transaction is added to
the chain using the first block and then, three more blocks are added to the block by the
application.
Results
Approximately running for about 8 hours, the application was able to add four
blocks to the blockchain. This was possible since there were no other miners in the
network who would verify the block reported by the fraud miner. When all the four
blocks were successfully reported to the node, these funds are readily available for
spending which can be verified by querying the node for balance of the address that
was logged by the application. The api also provides with an endpoint which enables
anyone to query the UTXOs (Unspent transaction outputs) of the node. The bitcoin
node keeps track of unspent transactions using a database that is separate from the
blockchain itself.
situation where only, a part of a transaction output is to be spent, the transaction has an
extra output which pays to the same address which contains the change from different
output. This way, there is a standardized way to keep track of un-spent outputs. The
node can be queried for the un-spent outputs using the endpoint provided by the
insight-api.
62
Summary
This chapter talks about the results of the application. In the previous chapter,
we talked about details of the implementation and some part of the code. In this section,
we looked at details of running the application and how to perform the mining operation.
This chapter also talks about the troubles that were faced during the implementation of
the application and how they were overcome during the development of the application.
63
Chapter V: Conclusions and Future Work
Introduction
This chapter talks about the overall summary of the paper. In the previous
chapter, we looked at the results of the application used to create the fake
cryptocurrency. It focused mainly about the results of the mining operation and how to
obtain the value of the fake coins that were added by using the application. This chapter
mainly focusses on the concluding the entire research and putting forth the difficulty of
adding fake coins to the main bitcoin network. This chapter also puts forth the future
work that can be done to improve the bitcoin protocol to avoid the attacks that are
Discussion
This paper talks about cryptocurrencies, the technology they depend on, the
mechanism which they to use of work, the different consensus mechanisms that are
involved in each of those cryptocurrencies. This paper also dives into the
implementation details of Proof of work and Proof of stake consensus mechanisms, how
they work and the effectiveness of the algorithms. The paper introduces the basic
concepts of Blockchains and describes how blockchain is linked together. It talks about
the SHA-256 algorithm and the different steps involved in hashing. It talks about bitcoin
transaction, how a transaction is included in a bitcoin block, it talks about hash merkle
root of a bitcoin block, and how it can be generated. Finally, it introduces a mechanism
which can be used to insert a fake transaction into the bitcoin blockchain there by
Miners are responsible for maintaining the integrity of the bitcoin network and the
blockchain itself. Miners validate transactions, verify new blocks added to the bitcoin
network thereby defending the blockchain against attackers. But in a situation where a
miner commits fraud may not be much serious trouble but if the miner possesses more
computational power than the rest of the miners put together, the miner might be able to
cause much damage to the chain as demonstrated by this research. Though it is very
unlikely to happen even by using super computers, this is still a vulnerability waiting to
be exploited.
Future Work
Blockchain and cryptocurrency technologies are brand new and there is lots of
research that can be done to improve these networks against attacks. Without miners,
these networks would cease to exist. The incentive in the form of coinbase transactions
is the main cause driving the miners towards mining but there is a limit to the number of
coins that can be mined by the miners. When this incentive is gone, miners may not be
cryptocurrency network is open to attackers and the entire network might need a reset
(Happened twice in case of bitcoin test net). The future work related to this paper would
Ahram T., Sargolzaei A., & Sargolzaei S. (2017, August). Blockchain technology
https://ieeexplore.ieee.org/document/7998367/
Bag S, Ruj S, & Sakurai K. (2016, November). Bitcoin block withholding attack.
https://ieeexplore.ieee.org/document/7728010/
repository.upenn.edu:
https://repository.upenn.edu/cgi/viewcontent.cgi?article=1133&context=wharton_
research_scholars
cryptocurrency-consensus-algorithms-9d744289378f
Griffith V. (2017, October). Casper the friendly finality gadget. Retrieved from arxiv.org:
https://arxiv.org/abs/1710.09437
Higgins S. (2017, December). Bitcoin's historic 2017 price run revisited. Retrieved from
coindesk.com: https://www.coindesk.com/900-20000-bitcoins-historic-2017-price-
run-revisited/
66
Kaushal P, K Bagga D. A, & Sobti D. R. (2017, July). Evolution of bitcoin and security
http://ieeexplore.ieee.org/document/8003959/?reload=true
https://ieeexplore.ieee.org/document/8048662/
Mingxiao D., Xiaofeng M, & Zhe Z. (2017, December 1). A review on consensus
http://ieeexplore.ieee.org/document/8123011/
https://ieeexplore.ieee.org/document/7906988/
bitcoin.org: https://bitcoin.org/bitcoin.pdf
Nayak K, Kumar S, & Miller A. (2016, May). Stubborn mining: generalizing selfish
https://ieeexplore.ieee.org/document/7467362/
Singh S., & Singh N. (2017, May). Blockchain: future of financial and cyber security.
http://ieeexplore.ieee.org/document/7918009/
67
Sleiman M. D., Lauf A. P., & Yampolskiy R. (2016, February). Bitcoin message: data
ieeexplore.ieee.org: https://ieeexplore.ieee.org/document/7398436/
Tosh D. K., Shetty S., & Liang X. (2018, January). Consensus protocols for blockchain-
ieeexplore.ieee.org: https://ieeexplore.ieee.org/document/8249088/versions
ieeexplore.ieee.org: https://ieeexplore.ieee.org/document/7920619
https://bitmessage.org/bitmessage.pdf
https://coinreport.net/coin-101/accepting-bitcoin/
Yu X., Shiwen M. T., & Li Y. (2017, October 19). Fair deposits against double-spending
http://ieeexplore.ieee.org/document/8073796/
Zheng Z., Xie S., & Dai H. (2017, September). An overview of blockchain technology:
https://ieeexplore.ieee.org/document/8029379
68
Appendix
Application.java
package org.bitcoin;
import com.fasterxml.jackson.databind.ObjectMapper;
import com.google.common.collect.Lists;
import io.vavr.control.Try;
import java.util.List;
import lombok.extern.slf4j.Slf4j;
import okhttp3.OkHttpClient;
import org.bitcoin.client.TransactionClient;
import org.bitcoin.model.Transaction;
import org.bitcoin.service.MinerUtil;
import org.bouncycastle.util.encoders.Hex;
import org.springframework.boot.autoconfigure.EnableAutoConfiguration;
import org.springframework.context.ApplicationContext;
import org.springframework.context.annotation.AnnotationConfigApplicationContext;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.ComponentScan;
69
import org.springframework.context.annotation.Configuration;
@Configuration
@EnableAutoConfiguration
@ComponentScan(basePackages = {"org.bitcoin"})
@Slf4j
ApplicationContext ctx
= new AnnotationConfigApplicationContext(Miner.class);
fraudMiner.startMiners();
@Bean
@Bean
MinerUtil.java
package org.bitcoin.service;
import com.google.common.collect.Lists;
import java.io.UnsupportedEncodingException;
import java.nio.*;
import java.security.*;
import java.time.Instant;
import java.util.*;
import java.util.stream.*;
import javax.annotation.PostConstruct;
import lombok.extern.slf4j.Slf4j;
import org.apache.commons.lang3.tuple.*;
import org.bitcoin.client.*;
import org.bitcoin.model.*;
import org.bitcoin.util.HexUtil;
71
import org.bitcoinj.core.Base58;
import org.bouncycastle.jce.provider.BouncyCastleProvider;
import org.bouncycastle.util.encoders.Hex;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Component;
@Slf4j
@Component
@Autowired
this.transactionClient = transactionClient;
72
this.targetClient = targetClient;
this.blockClient = blockClient;
keys = Lists.newArrayList();
@PostConstruct
NoSuchAlgorithmException, NoSuchProviderException,
UnsupportedEncodingException {
keyGen.initialize(ecSpec);
KeyPair kp = keyGen.generateKeyPair();
String sx = adjustTo64(pt.getAffineX().toString(16)).toUpperCase();
String sy = adjustTo64(pt.getAffineY().toString(16)).toUpperCase();
keys.add(ImmutablePair.of(privateKey, publicKey));
byte[] s1 = sha.digest(publicKey.getBytes("UTF-8"));
Security.addProvider(new BouncyCastleProvider());
byte[] r1 = rmd.digest(s1);
r2[0] = 0;
r2[i + 1] = r1[i];
byte[] s2 = sha.digest(r2);
byte[] s3 = sha.digest(s2);
a1[i] = r2[i];
a1[20 + i] = s3[i];
switch (s.length()) {
case 62:
return "00" + s;
case 63:
return "0" + s;
case 64:
return s;
default:
75
throw new IllegalArgumentException("not a valid key: " + s);
exception))
.getOrElse(Lists.newArrayList())
.stream().limit(20).collect(Collectors.toList());
exception));
exception))
.getOrElse(Block.builder().build());
.magicNumber("D9B4BEF9")
76
.blockHeader(BlockHeader.builder()
.hashPrevBlock(lastBlock.getBlockHeader().calculateHash().getOrElse(""))
.target(targetValue)
.time(HexUtil.formatLongAndReverseOrdering(Instant.now().getEpochSecond()))
.version("02000000")
.build())
.build();
block.setTransactions(transactions);
return block;
+ "ac";
String outputScriptLength =
HexUtil.formatIntegerAndReverseOrdering(outScript.length() / 2);
77
String lockTime =
HexUtil.formatLongAndReverseOrdering(Instant.now().getEpochSecond());
block.getTransactions().add(Transaction.builder()
.inCounter("01000000")
.listOfinputs(Collections.singletonList(TxIn.builder()
.previousTransactionHash("000000000000000000000000000000000000000000000000
0000000000000000")
.txOutIndex("00000000")
.txInScript("")
.txInScriptLength("00000000")
.sequenceNumber("FFFFFFFF")
.build()))
.outCounter("01000000")
.listOfOutputs(
Collections.singletonList(
TxOut.builder()
.txOutScript(outScript)
.value(HexUtil.formatLongAndReverseOrdering(5000000000L))
78
.txOutScriptLength(outputScriptLength)
.build()))
.versionNo("02000000")
.lockTime(lockTime)
.build());
block.setTransactionCounter(HexUtil.formatIntegerAndReverseOrdering(block.getTrans
actions().size()));
+ "ac";
String outputScriptLength =
HexUtil.formatIntegerAndReverseOrdering(outScript.length() / 2);
String lockTime =
HexUtil.formatLongAndReverseOrdering(Instant.now().getEpochSecond());
block.getTransactions().add(Transaction.builder()
79
.inCounter("01000000")
.listOfinputs(Collections.singletonList(TxIn.builder()
.previousTransactionHash("000000000000000000000000000000000000000000000000
0000000000000000")
.txOutIndex("00000000")
.txInScript("")
.txInScriptLength("00000000")
.sequenceNumber("FFFFFFFF")
.build()))
.outCounter("01000000")
.listOfOutputs(
Collections.singletonList(
TxOut.builder()
.txOutScript(outScript)
.value(HexUtil.formatLongAndReverseOrdering(1000000000L))
.txOutScriptLength(outputScriptLength)
.build()))
80
.versionNo("02000000")
.lockTime(lockTime)
.build());
block.setTransactionCounter(HexUtil.formatIntegerAndReverseOrdering(block.getTrans
actions().size()));
insertCoinbaseTransaction(block);
if (i == 1) {
insertFakeTransaction(block);
block.getBlockHeader().setNonce(HexUtil.formatLongAndReverseOrdering(nonce));
if (target.compareTo(hash) > 0) {
break;
if (blockClient.postBlock(block).get()) {
}).start();
HexUtil.java
package org.bitcoin.util;
import java.nio.ByteBuffer;
82
import java.nio.ByteOrder;
import org.bouncycastle.util.encoders.Hex;
import org.spongycastle.util.Arrays;
buffer.order(ByteOrder.LITTLE_ENDIAN);
buffer.put(Arrays.reverse(Hex.decode(value)));
buffer.order(ByteOrder.LITTLE_ENDIAN);
buffer.put(Arrays.reverse(Hex.decode(value)));
buffer.putInt(value);
buffer.order(ByteOrder.LITTLE_ENDIAN);
buffer.putLong(value);
Block.java
package org.bitcoin.model;
import io.vavr.control.Try;
import java.security.MessageDigest;
import java.util.List;
import java.util.stream.Collectors;
import lombok.AllArgsConstructor;
84
import lombok.Builder;
import lombok.EqualsAndHashCode;
import lombok.Getter;
import lombok.NoArgsConstructor;
import lombok.Setter;
import lombok.ToString;
import lombok.extern.slf4j.Slf4j;
import org.bitcoin.util.HexUtil;
import org.bouncycastle.util.encoders.Hex;
@ToString
@EqualsAndHashCode
@Builder
@Slf4j
@NoArgsConstructor
@AllArgsConstructor
@Getter
@Setter
85
private String magicNumber;
@Getter
@Setter
@Getter
@Setter
@Getter
@Getter
@Setter
this.transactions = transactions;
this.transactionCounter =
HexUtil.formatIntegerAndReverseOrdering(transactions.size());
if (this.blockHeader == null) {
this.blockHeader = BlockHeader.builder().build();
86
}
this.blockHeader.setHashMerkleRoot(calculateMerkleRoot().getOrElse(""));
.stream()
.map(transaction ->
HexUtil.reverseByteOrdering(transaction.calculateHash().get()))
.collect(Collectors.toList());
digest.reset();
hashes.remove(i - 1);
hashes.add(i - 1, HexUtil.reverseByteOrdering(combinedHash));
return hashes.get(0);
});
Transaction.java
package org.bitcoin.model;
import com.google.common.collect.Lists;
import io.vavr.control.Try;
import java.nio.ByteBuffer;
import java.nio.ByteOrder;
import java.security.MessageDigest;
import java.util.Collections;
import java.util.List;
88
import lombok.AllArgsConstructor;
import lombok.Builder;
import lombok.EqualsAndHashCode;
import lombok.Getter;
import lombok.NoArgsConstructor;
import lombok.Setter;
import lombok.ToString;
import lombok.extern.slf4j.Slf4j;
import org.bitcoin.util.HexUtil;
import org.bouncycastle.util.encoders.Hex;
@ToString
@EqualsAndHashCode
@Getter
@Setter
@Builder
@AllArgsConstructor
@NoArgsConstructor
@Slf4j
89
public class Transaction {
data += HexUtil.reverseByteOrdering(this.versionNo);
data += HexUtil.reverseByteOrdering(this.inCounter);
data += in.toString();
data += HexUtil.reverseByteOrdering(this.outCounter);
data += in.toString();
90
}
data += HexUtil.reverseByteOrdering(this.lockTime);
});
TxIn.java
package org.bitcoin.model;
import java.nio.ByteBuffer;
import java.nio.ByteOrder;
import lombok.AllArgsConstructor;
import lombok.Builder;
import lombok.EqualsAndHashCode;
import lombok.Getter;
import lombok.NoArgsConstructor;
91
import lombok.Setter;
import lombok.extern.slf4j.Slf4j;
import org.bitcoin.util.HexUtil;
import org.bouncycastle.util.encoders.Hex;
import org.spongycastle.util.Arrays;
@EqualsAndHashCode
@Getter
@Setter
@Builder
@Slf4j
@AllArgsConstructor
@NoArgsConstructor
try {
buffer.order(ByteOrder.LITTLE_ENDIAN);
data.append(previousTransactionHash);
if (this.txOutIndex != null) {
data.append(HexUtil.reverseByteOrdering(this.txOutIndex));
if (this.txInScriptLength != null) {
data.append(HexUtil.reverseByteOrdering(this.txInScriptLength));
if (this.txInScript != null) {
data.append(HexUtil.reverseByteOrdering(this.txInScript));
if (this.sequenceNumber != null) {
data.append(HexUtil.reverseByteOrdering(this.sequenceNumber));
93
}
return data.toString();
} catch (Exception e) {
e.printStackTrace();
throw e;
TxOut.java
package org.bitcoin.model;
import java.nio.ByteBuffer;
import java.nio.ByteOrder;
import lombok.AllArgsConstructor;
import lombok.Builder;
import lombok.EqualsAndHashCode;
import lombok.Getter;
import lombok.NoArgsConstructor;
import lombok.Setter;
94
import lombok.extern.slf4j.Slf4j;
import org.bitcoin.util.HexUtil;
import org.bouncycastle.util.encoders.Hex;
import org.spongycastle.util.Arrays;
@EqualsAndHashCode
@Getter
@Setter
@AllArgsConstructor
@NoArgsConstructor
@Builder
@Slf4j
@Override
data += HexUtil.reverseByteOrdering(this.txOutScriptLength);
data += HexUtil.reverseByteOrdering(this.txOutScript);
return data;
BlockHeader.java
package org.bitcoin.model;
import com.google.common.collect.Lists;
import io.vavr.control.Try;
import java.nio.ByteBuffer;
import java.nio.ByteOrder;
import java.security.MessageDigest;
import java.time.Instant;
import java.util.Collections;
import java.util.List;
import lombok.AllArgsConstructor;
import lombok.Builder;
96
import lombok.EqualsAndHashCode;
import lombok.Getter;
import lombok.NoArgsConstructor;
import lombok.Setter;
import lombok.ToString;
import lombok.extern.slf4j.Slf4j;
import org.bitcoin.util.HexUtil;
import org.bouncycastle.util.encoders.Hex;
@ToString
@EqualsAndHashCode
@Getter
@Setter
@Builder
@Slf4j
@NoArgsConstructor
@AllArgsConstructor
data += HexUtil.reverseByteOrdering(this.version);
data += HexUtil.reverseByteOrdering(this.hashPrevBlock);
data += HexUtil.reverseByteOrdering(this.hashMerkleRoot);
data += HexUtil.reverseByteOrdering(this.time);
data += HexUtil.reverseByteOrdering(this.nonce);
});
98
}
BlockClient.java
package org.bitcoin.client;
import com.fasterxml.jackson.core.type.TypeReference;
import com.fasterxml.jackson.databind.ObjectMapper;
import com.fasterxml.jackson.datatype.jsr310.JavaTimeModule;
import io.vavr.control.Try;
import lombok.extern.slf4j.Slf4j;
import okhttp3.MediaType;
import okhttp3.OkHttpClient;
import okhttp3.Request;
import okhttp3.RequestBody;
import okhttp3.Response;
import org.bitcoin.model.Block;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Component;
@Component
99
@Slf4j
@Autowired
this.httpClient = httpClient;
this.objectMapper = objectMapper;
.url("http://ubuntuvm:8080/insight-api/blocks/last")
.get()
.build();
objectMapper.registerModule(new JavaTimeModule());
});
});
charset=utf-8"), objectMapper.writeValueAsString(block));
.url("http://ubuntuvm:8080/insight-api/blocks")
.post(body)
.build();
response.close();
return true;
});
}
101
}
TargetClient.java
package org.bitcoin.client;
import io.vavr.control.Try;
import okhttp3.OkHttpClient;
import okhttp3.Request;
import okhttp3.Response;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Component;
@Component
@Autowired
this.httpClient = httpClient;
.url("http://ubuntuvm:8080/insight-api/target")
.get()
.build();
response.close();
return body;
});
TransactionClient.java
package org.bitcoin.client;
import com.fasterxml.jackson.core.type.TypeReference;
import com.fasterxml.jackson.databind.ObjectMapper;
import io.vavr.control.Try;
import java.util.List;
import okhttp3.OkHttpClient;
103
import okhttp3.Request;
import okhttp3.Response;
import org.bitcoin.model.Transaction;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Component;
@Component
@Autowired
objectMapper) {
this.httpClient = httpClient;
this.objectMapper = objectMapper;
.get()
.build();
response.close();
});
});
.url("http://ubuntuvm:8080/insight-api/transactions")
.get()
.build();
response.close();
});
});
}}