Proximity Neighbor Selectionin Blockchain Networks
Yusuke Aoki, and Kazuyuki Shudo
Tokyo Institute of Technology
2-12-1 Ookayama, Meguro, Tokyo, Japan

A peer-to-peer(P2P) networkof participating
nodes
Node

= An application-levelnetwork

A hash chain of blocks
Block

Block

Hash value

Hash value
TX

TX

A cryptographic
hash function

TX

TX

TX

TX

Abstract—Blockchains have attracted a great deal of attention
as a technology for the distributed management of register
information at multiple nodes without a centralized system. However, they possess the drawbacks of low transaction throughput
and long approval time. These problems can be addressed byshortening the block generation interval; however, shortening thisinterval alone has the effect of increasing the frequency of forks.
In this study, we aim to shorten the block generation interval
without increasing the fork generation rate by improving the
network topology of the nodes and shortening the propagation
time. We propose a neighbor node selection method forming
a network topology with a short block propagation time. A
blockchain simulator is used to demonstrate the effect of the
proposed neighbor node selection method on the propagation
delay of the network. This result indicates that the proposed
method improves block propagation time.
Index Terms—blockchain, neighbor selection, peer-to-peer

I. I NTRODUCTION

Fig. 1. Blockchain overview.

Blockchain is a distributed ledger technology that appearedas the core technology of the cryptocurrency Bitcoin [1],which is developed by the name of Satoshi Nakamoto. In
recent years, many cryptocurrencies using blockchain havebeen ledger developed and operated, and blockchains haveattracted increasing attention. Blockchains can manage information securely and protect it from tampering, even if
multiple malicious nodes are present. Additionally, no central
management is required, and a blockchain system can operate
independently. These features have proven to be very useful,and their application is being studied not only in cryptocurrency but in a wide range of fields.
Although blockchains have many advantages, they also
have several drawbacks. The primary problems involve thelow throughput of transactions and the approval time for atransaction. These obstacles can be overcome by shortening
the block generation interval. However, if the block generationinterval alone is shortened, the block propagation time will
not be sufficiently shorter than the block generation interval;
consequently, the frequency of forks will increase, leading toincreased security risk [2].
In this study, we construct a network topology with ashort block propagation time as a policy for overcoming the
aforementioned challenges. Because a blockchain network is
a peer-to-peer network without a central management system,
the network topology is determined by each node’s selectionof neighbor nodes. Therefore, in this paper, we propose aneighbor node selection algorithm for forming a network

topology with a short block propagation time. In the proposed
algorithm, each node evaluates other nodes using a score basedon the speed of block delivery, and preferentially selects a nodewith a good score to be a neighbor node. An improved blockpropagation time can be achieved if each node dynamicallychanges neighbor nodes based on information that can beobtained during blockchain operation.
Using a simulator, we demonstrated that the proposed
neighbor node selection algorithm improves block propagationtime.
The remainder of this paper is structured as follows. Section
II provides background information on blockchains, while
Section III proposes a neighbor node selection algorithm toimprove transaction throughput. Section IV describes experiments performed using a simulator to confirm the proposed
method. Section V presents conclusions and ideas for futurework.
II. B LOCKCHAIN
Blockchain is a distributed ledger technology regarded aspart of Bitcoin, proposed by Satoshi Nakamoto. The nodesof a blockchain constitute a peer-to-peer network. Because
blockchains have no central management, a consensus algorithm has been devised to ensure a consistent ledger without
contradiction between nodes. Most blockchain consensus algorithms are Byzantine fault-tolerance [3] and have the usefulfeature that even if a malicious node intentionally propagatesfalse information, the blockchain can form a correct consensus.

A. Blockchain technology

Node B

Node A

1) Transaction propagation: Data to be recorded inblockchains are called transaction, and they are broadcast to
the network through nodes participating in the blockchain
network. The broadcasted transactions are stored in the transaction pool of each node; however, they are not approved yet
and are not recorded in the ledger.
2) Consensus: Transactions are only approved by being
included in a block. A block contains multiple transactions,
including the hash value of the immediately preceding block,and a freely settable variable called nonce. As illustrated inFig. 1, the hash value of the previous block is included in eachblock; therefore, all blocks are connected in a chain referred
to a blockchain. This series of blocks is a ledger that records
transactions.
Each node generates a block that includes transactions in its
transaction pool. The generated block is propagated throughthe network and accepted and shared by other nodes. At thispoint, the transaction is accepted for the first time and recordedin the ledger.
At this time, it is important that the method to decide
which node generates the block. Because blockchains lackhave a central management mechanism, it is necessary toautonomously select a node to generate a block. Furthermore,even in a blockchain network in which multiple malicious
nodes participate, it is necessary to design so that the malicious
nodes can not falsify the ledger data by monopolizing theblock generation right. Several algorithms have been proposedfor deciding which nodes generate a block. The Proof of Work
(PoW) system used in Bitcoin is one of the most widely known
algorithms.
3) Proof of Work: In PoW, a node for generating a new
block is selected based on its computing power. Each blockincludes a value that is freely set by each node called a nonce,and each node locates a block whose hash value is below
a certain threshold while changing this nonce. Only blocks
below the threshold are regarded as formal blocks. Therefore,
a node that discovers a nonce satisfying the aforementioned
condition can generate a new block. The difficulty of block
generation can be adjusted by changing the threshold value.
The process of calculating the hash value of an entire block
while changing the nonce is called mining. In PoW, each node
can generate a new block with a probability proportional toits computing power.
4) Network: The nodes involved in a blockchain form apeer-to-peer network in which transactions and blocks arebroadcasted.
A blockchain peer-to-peer network is an unstructured network, and there are no rules for structurally defining connections. When a node creates a new connection, it selects
a destination node from the list of participating nodes looselyshared throughout the network. Nodes participating in the
network exchange information regarding nodes that are known
to them. When a new neighbor node is required, a node selects
one using this node information.

INV

ATA
GETD

BLO
CK

Fig. 2. Block propagation from node A to node B.

In Bitcoin’s reference implementation, Bitcoin Core [4],new connections are generated on limited occasions, such as
when a node joins the network or when an existing neighbornode is disconnected. Therefore, the topology of Bitcoin’s
network does not change significantly in a short period of time[5]. A connection that a node actively decides the destinationand creates is called Outbound, while a connection created in
response to other node’s Outbound is called Inbound. Bothconnections send and receive blocks and transactions in thesame way. By default, eight Outbounds are created, and no
more than 125 Inbounds are created.
In simple protocols, block transmission/reception takes
place using the protocol presented in Fig. 2. Before sending
a block, a node sends an INV message and verifies whether
the destination node already possesses the block. If the node
receiving the INV message does not possess the block, it
responds with a GETDATA message and waits for block
reception. By using this protocol, the unnecessary transmissionof blocks containing a large amount of data is prevented.
5) Fork: If the next block is generated before one blockpropagates the entire network, tow different blocks get propagated through the network, which is called a fork. A fork
result in each node possessing a different block as the latest
block, which leads to a loss of data consistency. Additionally,a high incidence of forks often allows attacks such as selfish
mining [6], and it is a large security risk. To prevent forks
from appearing in existing blockchains, the difficulty of block
generation is increased, and the block generation interval islengthened to ensure that multiple blocks are not generated
simultaneously. In the case of Bitcoin, the difficulty of block
generation is adjusted to allow one block to be generated every
10 min.
B. Transaction approval speed
Two challenges faced by blockchains are the interval between the occurrence of a transaction and the approval is longand that the throughput of the transaction is low [7].
1) Long approval interval: Transactions are not approved
until they are included in a block. Therefore, they are notapproved immediately upon being issued, but only after thefollowing block is generated. For Bitcoin, the block generation interval is 10 minutes; therefore, on average, it takes
approximately 5 minutes for a transaction be approved. Additionally, the approval interval experiences a further increase

Proc. 2nd IEEE Int'l Conf. on Blockchain(IEEE Blockchain 2019), pp.52-58, July 2019

when considering the possibility that forks occur and blocks
become invalid. In most cases, if approximately six blocks are
generated as a subsequent block, it is considered that the block
will not be invalidated. Therefore, the approval of a transaction
may take up to an hour or more.
A method for reducing the time required for approving atransaction involves shortening the block generation interval.
there is a method to shorten the block generation interval.
However, simply shortening this interval increases the incidence of forks.
2) Low throughput: The throughput of a blockchain is obtained by dividing the number of transactions in a block by theblock generation interval. For Bitcoin, the upper limit of thenumber of transactions in one block is approximately 4,000,
and the block generation interval is 10 min (600 s). Therefore,
the upper limit of the throughput is approximately seventransactions per second. This is a very small value comparedto the average throughput of Visa, which is approximately
1,700 transactions per second [8], or the average throughput
of PayPal, which is approximately 350 transactions per second[9].
There are two methods for improving the throughput: increasing the number of transactions in one block and shortening the block generation interval. Using the former method, as
the block size increases, the block propagation time between
nodes also increases [10] and it becomes necessary to increase
the block generation interval to suppress the occurrence offorks. Consequently, the throughput does not improve. Using
the latter method, shortening the block generation interval isalso problematic because it increases the incidence of forks.
C. Reducing block propagation time
Although the long approval interval and low throughout canboth be addressed by shortening the block generation intervala problem occurs whereby the incidence of forks increases.
To shorten the block generation interval without increasing theincidence of forks, it is necessary to simultaneously shorten theblock propagation time. This, in turn, influences the scale ofthe number of nodes in a blockchain network. As the numberof nodes in the network increases, the block propagation timethrough the entire network becomes longer, and the incidenceof forks increases. To safely scale the number of nodes, it isnecessary to reduce the block propagation time.
In this paper, we attempt to improve the efficiency ofthe network topology by shortening the block propagation
time. Because blockchain networks are peer-to-peer networks
without a central administrator, the topology of the network
is dependent on the manner in which neighbor nodes are
selected. We aim to decrease the propagation time of the
network by improving the neighbor selection algorithm.
III. P ROPOSED A LGORITHM
Proximity neighbor selection [11], [12] is a proven technique to improve propagation performance in peer-to-peer
networks. This section describes our proposed algorithm to to
perform proximity neighbor selection in blockchain networks.

In the proposed algorithm, we designed each node to connect
with the node that sent the INV message earlier to it. It is
possible to construct a network topology in which nodes withgood network conditions such as bandwidth can efficiently
deliver blocks.
A. Node scoring
In the proposed algorithm, each node rates the node that sent
it an INV message and determines the connection priority. The
score is based on the amount of time between block generationand the receipt of the INV message. Each time a node receives
an INV message from another node, it updates that node’s
score.
In (1), SCOREN is the score of node N when an INV
message from that node is received. The block creation timeis denoted TBlock , and the arrival time of the INV message isdenoted TIN V . If INV message of any block has not been
received from node N until then, the score is updated asfollows:
SCOREN ⇐ TIN V − TBlock(1)

However, If INV message of any block has been received fromnode N until then, the score is updated as follows.
SCOREN ⇐ (1 − P ) × SCOREN + P × (TIN V − TBlock )(2)Here, P is a weighting parameter in the range of [0 1]. The
appropriate value of P is determined experimentally in Section
IV.
In a regular blockchain, blocks contain the block generation
time information, and each node can obtain the reception timeof an INV message. Therefore, additional information is not
required to calculate the node score.
B. Update neighbor nodes
Each node reselects all of its neighbor nodes at regularintervals using the aforementioned node score. In this paper, neighbor nodes are reselected whenever 10 blocks arereceived. Each node selects new neighbor nodes in order ofincreasing scores.
However, K neighbor nodes are randomly selected from allnodes in the network to obtain information on the new node.
In many blockchains, information on nodes in the network isregularly propagated through the network, making it possible
to select nodes from the entire network at random. We
conducted an experiment that involved changing the value ofparameter K in order to determine the appropriate parameters;
this is described in more detail in Section IV.
The connection created by the neighbor node selection is
an Outbound connection, which is an active connection. To
prevent the concentration of Outbound connections on only
several nodes, the number of Inbound connections generated
corresponding to The Outbound connection of other nodes is
set to 30 or less.

Proc. 2nd IEEE Int'l Conf. on Blockchain(IEEE Blockchain 2019), pp.52-58, July 2019

Parameter# of the nodes
Block interval
Block size
# of connections
Geographical distribution
Bandwidth
propagation delay

BitcoinLitecoin
Dogecoin
6000
800
600
10 min2 min 30 sec
1 min
534 KiB
6.11 KiB
8 KiB
Distribution according to Miller et al. [5]Distribution according to actual blockchains
6 regional bandwidth and propagation delay

Median block propagation time (msec)

TABLE IPARAMETERS OF SIMULATOR PROPOSED BY G ERVAIS ET AL .

8500

8404

8400
8246

8300
8200
8100

8314

8105

8073
7954

8000

7835 7834 7845

7900
7800
7700
7600
7500

C. Impact on security

0.05

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

𝑃

IV. E XPERIMENTThe proposed algorithm is evaluated using a blockchain
simulator developed by Aoki et al. [14], [15]. In all theexperiments, the unlisted parts of parameters simulate the
Bitcoin environment in 2015 examined by Gervais et al. [16].
The parameters in Table I were reproduced in a similar manneras in the simulator proposed by Gervais et al.
A. Preliminary experiment
In the proposed algorithm, there are two parameters, theweight of score P and the number of neighbor nodes K
selected randomly. We performed a preliminary experiment
to determine the appropriate values for these two parameters.
1) Weighting parameter P : In the proposed algorithm,
upon each receipt of an INV message, the node score is
updated using (2), defined in Section III-A. In this experiment,
we changed the weighting parameter P and determined theappropriate P value.
We performed the simulation until 5,000 blocks were generated; we then measured the median value of the blockpropagation time, which is the average value of all 5000

Fig. 3. Median block propagation time for different values of parameter P .
Median block propagation time (msec)

Because our proposed algorithm imparts regularity on theblockchain network topology, close attention must be paid toattacks such as the Eclipse attack [13], in which malicious
nodes make use of topology. The Eclipse attack is an attack
that occupies replaces all of the neighbor nodes of a target
node or a target group of nodes with malicious nodes, thereby
separating the target from the network. Lowering the randomness of neighbor node selection thus increases the risk ofthe malicious manipulation of neighbor nodes. However, in
our proposed algorithm, the node that sends the block fasteris selected as the neighbor node. In other words, the nodethat wins the block distribution competition between nodes
is preferentially selected as the neighbor node. Therefore, because maliciously occupying neighbor nodes involves winninga competition between other nodes, the cost of the attack
increases. Additionally, an existing solution [13] that evaluates
individual connections such as the Ban system and Feeler
connection, can be applied to the connections determinedby the proposed algorithm. Furthermore, because K nodes
are randomly selected as neighbor nodes, many of the samemeasures used in regular blockchains can be used for theseneighbor nodes.

6900

6830

6800
6700
6600

6542

6500

6507

6499
6445

6400
6300
6200
0.1

0.2

0.3

0.4

0.5

𝑃

Fig. 4. Median block propagation time for different values of parameter P(1,000 nodes).

blocks. In this experiment, K = 1,. Fig. 3 presents the medianblock propagation times for different parameters P . It can beseen that the median block propagation time is shortest (7.83
seconds) when P = 0.3
Next, we confirmed that the optimal parameters did notchange depending on the number of nodes participating in
the network. Fig. 4 presents the experimental results when thenumber of participating nodes was changed to 1,000.
The results confirmed the same tendency for 1,000 nodes
as for 6,000 nodes.
2) Number of randomly selected node K: In the proposed
algorithm, K nodes are randomly selected as neighbor nodes
from the entire network. In this experiment, we changed
parameter K and compared the median block propagation
times to identify an appropriate K.
As in the parameter P , we performed the simulation until
5,000 blocks were generated; then, we measured the medianvalue of the block propagation time and compared the averagevalue of all 5,000 blocks. In this experiment, P = 0.3 Fig.
5 presents the block propagation time for different values ofparameter K. It can be seen that the block propagation timeis shortest for K = 1.
It can be seen that the block propagation time is the shortest
at K = 1.
Next, we confirmed that the optimal parameters did notchange depending on the number of nodes participating in

Proc. 2nd IEEE Int'l Conf. on Blockchain(IEEE Blockchain 2019), pp.52-58, July 2019

8341

8300
8200

P

8116

8100

K
1
2
3

8000
7900

7834

7800

0.1

0.2

0.3

0.4

0.5

7954
8085
8159

7835
8117
8290

7834
8116
8341

7845
8120
8315

8105
8252
8296

7700
7600
7500
1

2

3

𝐾

Fig. 5. Median block propagation time for different values of parameter K.

Median block propagation time (msec)

TABLE II
M EDIAN BLOCK PROPAGATION TIME ( MS ) FOR PARAMETERS P AND K.

6900

6829
6764

6800
6700
6600
6500

6445

6400

Fixed neighborMedian block propagation time (msec)

Median block propagation time (msec)

8400

9400

Proposed algorithm

8900

8400

7900

7400

0

6300

2000

4000

6000

8000

10000

The number of blocks

6200
1

2

3

𝐾

Fig. 6. Median block propagation time for different values of parameter K(1,000 nodes).

the network. Fig. 6 presents the experimental results when thenumber of participating nodes was changed to 1,000.
1,000. The results confirm that the tendency was identicalfor 1,000 nodes and 6,000 nodes.
3) Modifying both P and K: Table II presents the averagevalue of the median block propagation times measured whilechanging both P and K.
It can be seen that the propagation time is shortest whenK = 1, regardless of the value of P . In subsequent experiments in this study, we use P = 0.3 and K = 1, as they
produce the shortest propagation time.
B. Evaluation of proposed algorithm
We compared a network with fixed neighbor nodes to a
network with the proposed neighbor selection algorithm interms of their median block propagation times. The former
network reproduces a regular Bitcoin network. Fig. 7 illustrates
the comparison.
The experimental results reveal that the block propagation
time is improved using the proposed neighbor node selection
algorithm. Additionally, the propagation time is sufficiently
improved by replacing a small number of neighbor nodes.
After it is improved in the first several neighbor node updates,
the propagation time exhibits no further changes.

Fig. 7. Comparison of median block propagation times for a fixed-neighbornetwork and a network using the proposed neighbor selection algorithm. The
horizontal axis denotes the number of generated blocks and the vertical axis
indicates the median of the block propagation time. The median of the blockpropagation time is averaged every 100 blocks and then plotted.

Fig. 8 presents a comparison of the median propagation
times between the proposed algorithm and the fixed-neighboralgorithm.
It can be seen that many propagation times are distributed
between 6,700 ms to 6,900 ms, which at to the lower end of
the time range, and that the proposed algorithm has a greater
distribution near the lowest value than the fixed-neighboralgorithm does. This is likely the case because the proposed
algorithm allows more nodes to be concentrated in the central
part of the network topology. Additionally, for the proposed
algorithm, a concentrated distribution also appears in the range
of approximately 7,900 to 10,000 ms, while for the fixedneighbor algorithm, a concentrated distribution appears in therange of approximately 10,200 to 12,000 ms. The ranges ofconcentrated distribution reflect the propagation time of blocks
generated at nodes far from the center of the network. It canbe seen that the proposed algorithm reduces the propagation
time in this case.
Fig. 9 presents a comparison between algorithms for therange of 6,700 to 7,000 ms.
It can be seen that the proposed algorithm results in lower
propagation times than the fixed-neighbor algorithm. This
indicates that with the proposed method, the propagation timeof blocks generated at nodes near the center of the network isalso improved.

Proc. 2nd IEEE Int'l Conf. on Blockchain(IEEE Blockchain 2019), pp.52-58, July 2019

50%

50%

45%

45%

6%

6%

5%
4%

5%

3%

4%

2%

3%

1%

2%

0%
6700

7700

8700

9700

10700

11700

Median block propagation time
Proposed algorithm
Fixed neighbor

12700(msec)

1%
0%06600 7200 7800 8400 9000 9600 10200 10800 11400 12000 12600(msec)Median block propagation time

Fig. 8. Comparison of median propagation times for proposed algorithm andfixed-neighbor algorithm.

Proposed algorithm

Fixed neighborFig. 10. Median of the propagation time for uniform block generation
performance.

18%
16%
14%
12%
10%
8%
6%
4%
2%
0%
6700

6750

6800

6850

6900

Median block propagation time
Proposed algorithm

6950 (msec)

Fixed neighborFig. 9. Comparison of median propagation times (6,700 ∼ 7,000 ms) for
proposed algorithm and fixed-neighbor algorithm.

18%
16%
14%
12%
10%
8%
6%
4%
2%
0%

Proposed algorithm
Fixed neighbor

6700

6750

6800

6850

6900

6950

(msec)Median block propagation time

C. Influencing factors

Fig. 11. Median of the propagation time for uniform block generation
performance (6700 ∼ 7000 ms).

The proposed algorithm selects appropriate neighbor nodes
using only the local information that each node can obtain,
and the topology of the network changes. Although the speedof block delivery is used as an indicator of neighbor node
selection, it can be affected by both the network environmentand block generation performance of nodes. A node with afavorable network environment has a short waiting time forreceiving blocks from other nodes and a short time for transmitting to other nodes; thus, the block delivery speed tends
to be highter. Nodes with high block generation performance
have a high probability of generating blocks themselves. The
blocks that they generate can be delivered earlier than any
other node. Below, we investigate how the block propagation
time is affected by the network environment and block generation performance respectively.
1) Effect of network environment: Here, we investigate theeffect of the network environment of each node on the blockpropagation time for the proposed algorithm. We eliminatedthe effect of block generation performance by setting the block
generation performance of each node to a uniform value. The
other environmental conditions were the same as in the pre-vious experiment. The experiment was performed until 5,000
blocks were generated, and the median block propagation time
was measured. Fig. 10 presents a comparison of the medianpropagation times for the proposed algorithm and the fixedneighbor algorithm, and Fig. 11 presents a comparison in therange of 6,700 to 7,000 ms.
These experimental result is similar to the previous one in
Fig. 8 and Fig. 9. It can be concluded that network environment has a large impact on improving the block propagation
time of the proposed algorithm.
2) Effect of block generation performance: Here, we investigate the effect of the block generation performance ofeach node on improving the block propagation time for the
proposed algorithm. The effect of network environment waseliminated by setting the propagation delay and bandwidthof each node to a uniform value. The other environmental
conditions were the same as in the previous experiment. The
experiment was performed until 5,000 blocks were generated,
and the median block propagation time was measured. Fig. 12
presents a comparison of the median propagation times for theProc. 2nd IEEE Int'l Conf. on Blockchain(IEEE Blockchain 2019), pp.52-58, July 2019

45%
40%
35%

Proposed algorithm

30%

Fixed neighbor

25%
20%
15%
10%
5%
0%
8750

8800

8850

8900

8950

Median block propagation time

9000~
(msec)

Fig. 12. Median of the propagation time for uniform network enviroment.

proposed algorithm and the fixed-neighbor algorithm.
It can be seen that the block propagation times are distributed in a very narrow range for a uniform network, andthere is no improvement in propagation efficiency with the proposed algorithm. In this experiment, the median propagation
time of the top 100 nodes with the highest block generation
performance was slightly lower than the median overall propagation time. Nodes with high block generation performanceare considered to be concentrated at the center of the network.
If nodes with a favorable network environment participate ina blockchain network, efficient block propagation may occur
because nodes with high block delivery speed tend to belocated near the center of network, where nodes with highblock generation performance are concentrated.
V. C ONCLUSION
The major drawbacks of blockchains include low transaction
throughput and the long approval times. These problems canbe addressed by shortening the block generation interval;
however, if the block generation interval alone is shortened, theoccurrence of forks rises and the security risk increases. Thus,
it is necessary to shorten the block propagation time in orderto shorten the block generation interval while suppressing theoccurrence of forks. In this study, we developed a neighbornode selection algorithm to form a network with a short blockpropagation time. In a blockchain network, each node rates
other nodes according to the speed of block delivery, andpreferentially selects a node with a good score to be a neighbornode. With our proposed algorithm, a network with hight blockpropagation efficiency can be formed using only informationthat each node can obtain locally. Using a simulator, we
confirmed that the proposed neighbor node selection algorithm
improves block propagation time.
Future work should examine additional block propagation
protocols used in existing blockchains. Protocols other than
the traditional ones used in this paper have been proposed.
A famous example is the compact block relay [17]. In a
traditional block propagation protocol, if the transaction in a
received block is already present in the transaction pool, this
implies that the same transaction has been received twice In

the compact block relay protocol, when receiving block, thebandwidth used in suppressed by receiving only transactions
that are not included in the transaction pool. When the
proposed algorithm is used in a blockchain employing compact
relays, the influence on bandwidth of neighbor node selection
is reduced, and the propagation delay and block generation
performance are expected to improve.
Future work should also investigate changes to the securityof the network resulting from the proposed neighbor node
selection algorithm. Because the proposed algorithm alters the
network topology, we must investigate what influence it has on
resistance to fragmentation and other attributes by analyzing
the graph of the network.
ACKNOWLEDGMENT
This work was supported by SECOM Science and Technology Foundation.
R EFERENCES[1] Satoshi Nakamoto. Bitcoin: A peer-to-peer electronic cash system. 2008.
[2] Yonatan Sompolinsky and Aviv Zohar. Secure high-rate transaction
processing in Bitcoin. In Proc. FC’15, 2015.
[3] Leslie Lamport, Robert Shostak, and Marshall Pease. The Byzantine
generals problem. ACM Transactions on Programming Languages andSystems (TOPLAS), 4(3):382–401, 1982.
[4] Bitcoin Core: Bitcoin. https://bitcoincore.org, (accessed May. 30, 2019).
[5] Andrew Miller, James Litton, Andrew Pachulski, Neal Gupta, Dave
Levin, Neil Spring, and Bobby Bhattacharjee. Discovering Bitcoins
public topology and influential nodes. 2015.
[6] Ittay Eyal and Emin Gün Sirer. Majority is not enough: Bitcoin mining
is vulnerable. Communications of the ACM, 61(7):95–102, 2018.
[7] Kyle Croman, Christian Decker, Ittay Eyal, Adem Efe Gencer, Ari Juels,
Ahmed Kosba, Andrew Miller, Prateek Saxena, Elaine Shi, Emin GünSirer, et al. On scaling decentralized blockchains. In Proc. Financial
Cryptography and Data Security 2016 (FC16), pages 106–125. Springer,
2016.
[8] Visa acceptance for retailers. https://usa.visa.com/run-your-business/
small-business-tools/retail.html, (accessed May. 30, 2019).
[9] PayPal, Inc — PayPal reports first quarter 2019 results.
https://investor.paypal-corp.com/news-releases/news-release-details/
paypal-reports-first-quarter-2019-results, (accessed May. 30, 2019).
[10] Christian Decker and Roger Wattenhofer. Information propagation in
the Bitcoin network. In Proc. IEEE P2P 2013, pages 1–10, 2013.
[11] Takehiro Miyao, Hiroya Nagao, and Kazuyuki Shudo. A method fordesigning proximity-aware routing algorithms for structured overlays.
In Proc. IEEE ISCC’13, 2013.
[12] K. Gummadi, R. Gummadi, S. Gribble, S. Ratnasamy, S. Shenker, and
I. Stoica. The impact of DHT routing geometry on resilience andproximity. In Proc. ACM SIGCOMM 2003, August 2003.
[13] Ethan Heilman, Alison Kendler, Aviv Zohar, and Sharon Goldberg.
Eclipse attacks on Bitcoin’s peer-to-peer network. In 24th USENIX
Security Symposium, pages 129–144, 2015.
[14] Yusuke Aoki, Kai Otsuki, Takeshi Kaneko, Ryohei Banno, and Kazuyuki
Shudo. SimBlock: A blockchain network simulator. In Proc. 2nd
Workshop on Cryptocurrencies and Blockchains for Distributed Systems(CryBlock 2019), 2019.
[15] Ryohei Banno and Kazuyuki Shudo. Simulating a blockchain networkwith SimBlock. In Proc. 2019 IEEE Int’l Conf. on Blockchain and
Cryptocurrency (IEEE ICBC 2019), pages 3–4, 2019.
[16] Arthur Gervais, Ghassan O Karame, Karl Wüst, Vasileios Glykantzis,
Hubert Ritzdorf, and Srdjan Capkun. On the security and performanceof Proof of Work blockchains. In Proc. ACM CCS 2016, pages 3–16,
2016.
[17] bip-0152.mediawiki.
https://github.com/bitcoin/bips/blob/master/
bip-0152.mediawiki, (accessed May. 21, 2019).

Proc. 2nd IEEE Int'l Conf. on Blockchain(IEEE Blockchain 2019), pp.52-58, July 2019