Research Article Understanding Block and Transaction Logs ...

18
Research Article Understanding Block and Transaction Logs of Permissionless Blockchain Networks Hwanjo Heo 1,2 and Seungwon Shin 1 1 Korea Advanced Institute of Science and Technology (KAIST), Daejeon, Republic of Korea 2 Electronics and Telecommunications Research Institute (ETRI), Daejeon, Republic of Korea Correspondence should be addressed to Seungwon Shin; [email protected] Received 15 April 2021; Revised 18 June 2021; Accepted 15 July 2021; Published 4 August 2021 Academic Editor: Wenjuan Li Copyright © 2021 Hwanjo Heo and Seungwon Shin. is is an open access article distributed under the Creative Commons Attribution License, which permits unrestricted use, distribution, and reproduction in any medium, provided the original work is properly cited. Public blockchain records are widely studied in various aspects such as cryptocurrency abuse, anti-money-laundering, and monetary flow of businesses. However, the final blockchain records, usually available from block explorer services or querying locally stored data of blockchain nodes, do not provide abundant and dynamic event logs that are only visible from a live large- scale measurement. In this paper, we collect the network logs of three popular permissionless blockchains, that is, Bitcoin, Ethereum, and EOS. e discrepancy between observed events and the public block data is studied via a noble analysis model provided with the soundness of measurement. We share our key findings including a false universal assumption of previous mining-related studies and the block/transaction arrival characteristics. 1. Introduction Since the inception of Bitcoin, the first peer-to-peer dis- tributed ledger system invented by Nakamoto [1] in 2009, many blockchain systems have undergone development in the public. Ethereum [2] has started its mainnet in 2015 to enhance the vision of blockchain by featuring the idea of smart contracts; it is recognized as the first decentralized computing platform for decentralized applications (dApps). Public blockchains have evolved afterwards to provide better privacy [3], scalability [4, 5], and financial service special- ization [6] and even for a particular application environment such as Internet of ings [7]. Among others, EOS [8] has been recognized for its technical endeavor of pursuing a scalable dApp platform with a governance model via Del- egate Proof-of-Stake (DPoS) consensus; it is, however, often denounced for not being truly decentralized [9]. Information recorded in permissionless (A blockchain system is permissionless if no permission is required to access or participate in the network.) blockchains, beyond their original utility of being transaction ledgers, is publicly available and commonly studied in the literature. For example, block explorer services [5, 10–16] have emerged to provide transaction information stored in blockchains with additional analytics and user-friendly interfaces. Similarly, historical block and transaction data have become a popular subject not only for economic aspects of cryptocurrencies such as cryptocurrency abuse [17], anti-money-laundering [18], and monetary flow of businesses [19] but also to evaluate the security of underlying mechanisms of block- chains [20–22]. However, historical blockchain data is limited to provide block and transaction records in historical view, that is, the eventual ordered set of transaction records, which are only the final product of the consensus mech- anism among distributed blockchain network nodes. Live block and transaction records exchanged by the network nodes are more abundant and dynamic so that observing them in measurement view plays an important role in understanding the systematic aspects of permissionless blockchain systems. Figure 1 describes an illustrative time series of trans- action and block arrival events in two different view models. Historical blockchain data only provides a historical view in Hindawi Security and Communication Networks Volume 2021, Article ID 9549602, 18 pages https://doi.org/10.1155/2021/9549602

Transcript of Research Article Understanding Block and Transaction Logs ...

Research ArticleUnderstanding Block and Transaction Logs of PermissionlessBlockchain Networks

Hwanjo Heo 12 and Seungwon Shin 1

1Korea Advanced Institute of Science and Technology (KAIST) Daejeon Republic of Korea2Electronics and Telecommunications Research Institute (ETRI) Daejeon Republic of Korea

Correspondence should be addressed to Seungwon Shin claudekaistackr

Received 15 April 2021 Revised 18 June 2021 Accepted 15 July 2021 Published 4 August 2021

Academic Editor Wenjuan Li

Copyright copy 2021 Hwanjo Heo and Seungwon Shin is is an open access article distributed under the Creative CommonsAttribution License which permits unrestricted use distribution and reproduction in anymedium provided the original work isproperly cited

Public blockchain records are widely studied in various aspects such as cryptocurrency abuse anti-money-laundering andmonetary flow of businesses However the final blockchain records usually available from block explorer services or queryinglocally stored data of blockchain nodes do not provide abundant and dynamic event logs that are only visible from a live large-scale measurement In this paper we collect the network logs of three popular permissionless blockchains that is BitcoinEthereum and EOS e discrepancy between observed events and the public block data is studied via a noble analysis modelprovided with the soundness of measurement We share our key findings including a false universal assumption of previousmining-related studies and the blocktransaction arrival characteristics

1 Introduction

Since the inception of Bitcoin the first peer-to-peer dis-tributed ledger system invented by Nakamoto [1] in 2009many blockchain systems have undergone development inthe public Ethereum [2] has started its mainnet in 2015 toenhance the vision of blockchain by featuring the idea ofsmart contracts it is recognized as the first decentralizedcomputing platform for decentralized applications (dApps)Public blockchains have evolved afterwards to provide betterprivacy [3] scalability [4 5] and financial service special-ization [6] and even for a particular application environmentsuch as Internet of ings [7] Among others EOS [8] hasbeen recognized for its technical endeavor of pursuing ascalable dApp platform with a governance model via Del-egate Proof-of-Stake (DPoS) consensus it is however oftendenounced for not being truly decentralized [9]

Information recorded in permissionless (A blockchainsystem is permissionless if no permission is required toaccess or participate in the network) blockchains beyondtheir original utility of being transaction ledgers is publiclyavailable and commonly studied in the literature For

example block explorer services [5 10ndash16] have emerged toprovide transaction information stored in blockchains withadditional analytics and user-friendly interfaces Similarlyhistorical block and transaction data have become a popularsubject not only for economic aspects of cryptocurrenciessuch as cryptocurrency abuse [17] anti-money-laundering[18] and monetary flow of businesses [19] but also toevaluate the security of underlying mechanisms of block-chains [20ndash22]

However historical blockchain data is limited toprovide block and transaction records in historical viewthat is the eventual ordered set of transaction recordswhich are only the final product of the consensus mech-anism among distributed blockchain network nodes Liveblock and transaction records exchanged by the networknodes are more abundant and dynamic so that observingthem in measurement view plays an important role inunderstanding the systematic aspects of permissionlessblockchain systems

Figure 1 describes an illustrative time series of trans-action and block arrival events in two different view modelsHistorical blockchain data only provides a historical view in

HindawiSecurity and Communication NetworksVolume 2021 Article ID 9549602 18 pageshttpsdoiorg10115520219549602

which transactions are flattened that is appear as if si-multaneously arriving at the time of block arrival and onlythose included in the main chain blocks are visible Forexample the arrival times of t0 and t1 can be only bound tothe timestamp of b10 in the historical view as there are noseparate timestamps for transaction records Transactionsand blocks can also be stale that is not included in blocks ornot part of the main chain respectively or not even ex-plicitly advertised if observed under the hood For examplethe stable block b11 which is not the part of the main chaincannot be found on the historical record the stale trans-action t2 that fails to be included in a block will not berecorded either e measurement view can provide a richand dynamic transaction and block arrival event logs on theother hand

In this paper we conduct an in-depth analysis of large-scale block and transaction arrival event measurement of thethree popular blockchains Bitcoin Ethereum and EOSeblock and transaction logs which are not visible from themain chain block data are investigated to reveal our findingsthat shed light on the understanding of how permissionlessblockchain systems work Specifically we make the fol-lowing major contributions

(i) Transaction and block arrival events of the threepopular permissionless blockchains are measured ineight geographically dispersed locations Ourmeasurement is underpinned by a noble analysismodel and supporting results of measurementsoundness

(ii) We perform a quantitative analysis on the dis-crepancy between observed events and the publicblock data We further study the block discrepancyin terms of blockchain forks to show that the as-sumption universally adopted by mining-relatedresearch does not hold for Ethereum

(iii) We analyze transaction arrival processes to findthat they indeed exhibit LRD (Long-Range De-pendence) We provide analytical distributionsthat fit best the permissionless blockchains westudy

2 Background

21 Blockchain e blockchain stores transactions in theunit of blocks Transactions are defined differently perblockchain system it commonly represents a single transferof cryptocurrency values Ethereum further defines that atransaction is an action initiated by an externally owned

account to modify the state stored in the blockchain network[23] An EOS transaction is the set of one or more suchactions [24]

A miner (or a block producer) can add a block to thechain by publishing it over the network hoping that herpublished block will become the part of the canonical chain(We also call it the main chain in this paper) upon suc-cessful mining (or block production) she gets rewarded inits native cryptocurrency

We call the blockchain permissionless if anyone canparticipate in the mining process Consequently there canbe temporarily more than one candidate block to be in-cluded in the main chain and we call such cases blockchainforks e main chain refers to the longest [1] heaviest-subtree [25] and irreversible [26] chain for BitcoinEthereum and EOS respectively

Bitcoin and Ethereum adopt PoW (Proof-of-Work)consensus mechanism where mining of a block is performedby solving the computationally demanding cryptopuzzlesOn the other hand EOS adopts DPoS (Delegate Proof-of-Stake) consensus mechanism where the set of block pro-ducers who later produce scheduled blocks in turn iselected by EOS stakeholders Table 1 summarizes the threeblockchains we study in this paper

22 ResearchQuestions Our study aims to shed light on theunderstanding of various aspects of blockchains obscuredfrom a historical view Specifically we have focused on threeresearch questions

RQ1 Are network-advertised transaction logsconsistent with the transactions included in mainchain blocks

(i) (Preview on our findings) No Basically theblockchain transaction arrival processes are moreLRD (Long-Range Dependent) than those of theblocks (Section 51) ere are unadvertised trans-actions that are directly inserted by miners im-plying privatization of transaction fees Advertisedtransactions also may end up being stale that is notincluded in blocks mostly due to conflict transac-tions which instead get placed in blocks (Section42)RQ2 Do miners behave rationally (or selfishly) tomaximize their profit (Do miners endorse earliestpropagated blocks in the event of blockchain forks)

(ii) (Preview on our findings) No Bitcoin fork eventsnow have become too rare (004) implying that

b10 b13

t1t0 t5

Timeb12

t4t3

b14

t7t6Transaction

arrivalsBlock

arrivals

(a)

b10 b13b11

t0 t1 t2 t5t3 t6

Time

TransactionarrivalsBlock

arrivalsb12

t4

b14

t7 t8

(b)

Figure 1 Two viewmodels of blockchain events ti are transaction arrival events and bi are block arrival events grey-colored events are onlyobservable in the measurement view (a) Historical view (b) Measurement view

2 Security and Communication Networks

selfish mining is not the preferred strategy for Bitcoinminers On the other hand the majority of Ethereumminers add blocks to their own mined blocks ratherthan the earliest propagated ones that are mined byother pools this contradicts the unarguably adoptedassumption of previous studies (Section 41)RQ3 Do blockchain nodes effectively get away frompartitioning attacks by virtue of information re-dundancy from multiple peers (Are they stillvulnerable to partitioning attacks)

(iii) (Preview on our findings) Yes e referenceimplementations of PoW blockchains have in-creased the number of (outbound) peer connectionsand consequently the up-to-date nodes benefitfrom redundant block advertisement from 14 to 46peers for Bitcoin and Ethereum respectively (Sec-tion 52) tampering with a small number of peerswill not successfully partition or make a node un-synchronized for minutes [27]

23 AnalysisModel Although the three blockchains operatedifferently (as summarized in Table 1) in many ways theycan be commonly modeled with the following

(i) Blocks are produced by miners (or block producers)and are broadcast to the network by peer connec-tions A block b is uniquely identified with itsblockhash and refers to its parent block bp (ieprev(b) bp) e arrival time of b at a measure-ment point m (ie arrival(b)m) is the arrival time ofb from one of mrsquos peers who delivers b for the firsttime e block b can be included in the main chain(ie Bmain) or it can be stale (ie b notin Bmain)

(ii) Transactions are composed and propagated by usersthrough a P2P network A transaction t is uniquelyidentified with its txid e arrival time of transac-tion t at a node m (ie arrival(t)m) is the arrival timeof t from one of mrsquos peers who delivers t for the firsttime e transaction t can be included in block b

(ie t isin transactions(b)) or be stale (iet notin transactions(b)forallb isin Bmain)

e set of notations is summarized in Table 2 and thefunctions used in the definition are listed in Table 3

Our model comprises the two arrival events that isblock and transaction arrival events where a single block

arrival event is mapped to zero or more transaction events(ie ti isin transactions(b)) by the function transactions(middot)

(Bitcoin coinbase transactions are excluded in our analysis asthey are not advertised to the network)

Figure 2 depicts how we analyze our measurements Instudying the discrepancy in block and transaction events(Section 4) the arrival events near the measurement bound-aries significantly affect our quantitative analysis For exampleincluding or excluding a single Bitcoin block around themeasurement boundary can produce more than two thousandstale or unobserved transactions To this end we crop themeasurement to the observation period by carefully choosingtwo anchor blocks the preamble block bm and the concludingblock bn for each dataset of blockchains so that our mea-surement satisfies the two following conditions (i) ere is noloss of measurement data (due to the reasons described inSection 31) at any of our eight (Due to unreliable peeringservices of candidate BPs (block producers) of EOS we haverelaxed the conditions to six for EOS) locations in the timeperiod of one week before the arrival of bm and one week afterthe arrival of bn (ii) Both bm and bn belong to the main chain

3 Measurement

31 Data Collection We have modified the referenceimplementations of three popular pieces of blockchainsoftware Bitcoin Core [28] Go Ethereum [29] and EOSIO[8] to facilitate logging of all received transactions andblocks from peers Our monitoring pieces of software aredeployed to eight geographically dispersed regions of theGoogle cloud platform [30] Asia-East Asia-South Europe-North Europe-West North America-Northeast US-Cen-tral US-East and US-West Each VM is configured to havetwo vCPUs 185GB of memory and 800GB of standardpersistent disk Measurements were performed between July2019 and December 2019 by having our monitors which areindeed full nodes on the three blockchain mainnets con-nected to the peers As regards EOS the full node softwarethat is nodeos is neither bundled with default seed peers norfacilitated with a peer discovery mechanism We havemanually collected available peers and fed them Also asnodeos only accepts transaction and block advertisements inIn-Sync mode [24] a recent snapshot [31] is inputted toquickly catch up without throttling CPU and networkbandwidth by syncing from scratch that is the genesisblock Unfortunately we experienced several problems thatresulted in suspension of our monitoring processes For

Table 1 Blockchain summary

Blockchain Consensusmechanism

Blocktime

Transactions per second(all-time high)

Balancemodel

Transactionfee

Peer-to-peer management

Discovery Max peers (Outgoing)

Bitcoin PoW sim10minutes 7 UTXO Yes Random from

seeder list 125 (8)

Ethereum PoW sim10seconds 15 Account Yes Kademlia-like 50 (16)

EOS DPoS 05seconds 4000 Account No (staking) mdash mdash

Security and Communication Networks 3

example the Google cloud platform endeavors to detectcryptocurrency-mining-related activities Once detected theVM instance immediately gets suspended and is reinstatedonly if a reasonable explanation is provided

Furthermore we have noticed a few software crashesVM suspensions by other reasons or temporary lack of diskspace causing loss of measurement data Lastly a majority of

EOS candidate BPs who have provided the peering servicehave gradually stopped their services and only several are leftat the end of our measurement period To eradicate inac-curacy due to the above problems our measurement datasetis trimmed as described in Section 23 Table 4 summarizesour choice of the two anchor blocks and consequent ob-servation period statistics

Table 2 Transaction and block set notation of our measurement framework

Notation Description Definition

Bobse set of blocks observed in the observation

periodbi bi+1 bjminus2 bjminus11113966 1113967 where there is no bk satisfying

arrival(bm)le arrival(bk)le arrival(bi) or arrival(bjminus1)le arrival(bk)le arrival(bn)

Bmaine set of blocks that are included in the

main chainbm+1 bm+2 bnminus1 bn1113864 1113865 where bi prev(bi+1) for all mlt ilt n and bm and bn are

the preamble and concluding blocks respectivelyBstale e set of observed blocks that are stale Bobs minus Bmain

Bunseene set of blocks that are part of the main

chain but not observed Bmain minus Bobs

Tobse set of transactions observed in the

observation periodti ti+1 tjminus2 tjminus11113966 1113967 where there is no tk satisfying

arrival(bm)le arrival(tk)le arrival(ti) or arrival(tjminus1)le arrival(tk)le arrival(bn)

Tpree set of transactions observed before the

observation periodt0 t1 timinus2 timinus11113864 1113865 where there is no tk satisfying

arrival(timinus1)le arrival(tk)le arrival(bm)

Tposte set of transactions observed after the

observation period tj tj+1 1113966 1113967 where there is no tk satisfying arrival(bn)le arrival(tk)le arrival(tj)

Tstalee set of observed transactions that are

stale Tobs minus cupbisinBmain

transactions(b)

Tincludede set of transactions that are observed and

included in the main chain blocks Tobs cap cupbisinBmain

transactions(b)

Tunseene set of transactions that are included inthe main chain blocks but not observed cup

bisinBmain

transactions(b) minus Tpre cupTobs cupTpost

Table 3 Block and transaction functions

Function Descriptionblockhash(b) e hash value of block b

prevhash(b) e previous block hash value of block b

prev(b) e previous block bp of block p ie blockhash(bp) prevhash(b)

height(b) e block height of block b

miner(b) e miner of block b

children(b) e set of child blocks of block b ie height(bc) height(b) + 1forallbc isin children(b)

transactions(b) e set of transactions included in block b

arrival(e) e arrival time of event e where e can be either a block or a transactioninputs(t) e set of transaction inputs (ie vin) of Bitcoin transaction t

outputs(t) e set of transaction outputs (ie vout) of Bitcoin transaction t

nonce(t) e nonce value of Ethereum transaction t

bm bnbm+1

ti ti+1 ti+2 tj-1tj-2 tjtindash1

Time

Transactionarrivals

Blockarrivals

TobsTpre Tpost

bn+1

BobsBpre Bpost

Measurement period

Observation period

bmndash1

Figure 2 Transaction and block analysis model grey-colored events are cropped out for measurement point consistency

4 Security and Communication Networks

32 Measurement Soundness As public blockchain net-works are built on the best-effort serviced overlay network ofP2P connections complete and timed information deliveryis not guaranteed We analyze the completeness of blockarrival events transaction arrival events and their arrivaltime accuracy to underpin the soundness of ourmeasurement

321 Block Coverage Blocks can be part of the main chainor they can be staleWe test our observation against themainchain which is available from a number of block explorerservices to make sure there are no missing blocks

Table 5 shows the observed number of blocks across ourmeasurement points e main chain blocks are all observedwhile stale blocks are partially observed stale blocks beingpartially observed is expected as blockchain nodes are notobliged to propagate stale blocks e stale blocks accountfor only sim004 for Bitcoin and EOS while sim702 of theobserved blocks are stale for Ethereum e stale blockprobability of Bitcoin has been decreasing [21 32] andEthereumrsquos stale block probability is 5 sim 10 larger thanknown uncle rates (calculated only with reported uncles) asour measurement captures unreported stale blocks aswell [33]

322 Transaction Coverage Incomplete transaction mea-surement causes a subset of transactions which are includedin blocks never being observed during measurement Ag-gregating transactions observed from different monitors cancompensate for this incompletenesse unseen transactionsare acquired by subtracting the observed transactions fromthe transactions included in the main chain blocks

Figure 3 shows the probability of unseen transactions(ie n(T

1113954Munseen)n(Tobs)) as a function of the number of

combined measurement points As combining all mea-surement point transaction arrivals results in a convergedfrequency of sim005 for Bitcoin and EOS and sim05 forEthereum it implies that unseen transactions will be stillobserved even if more monitors are deployed to the networkWe further study the unseen transactions in Section 42

323 Timing Accuracy Consider an ordered arrival time-stamp of block b observed at all measurement pointsM tsi|0le ilt n(M)1113864 1113865 arrival(b)m|forallm isinM where tsi lttsj for all ilt jlt n(M) We evaluate the tightness of ourmeasured timing information with Δ(ts0 ts1) and how farthe arrival times can be dispersed among the measurementpoints with Δ(ts0 ts7) where Δ computes the timewisedifference Figure 4 depicts the distribution of the two

Table 4 Observation period statistics

BlockchainPreamble block Concluding block Population

Block height Timestamp Block height Timestamp blocks transactionsBitcoin 587500 2019-07-28 210228 597500 2019-10-02 062237 10004 21454436Ethereum 8290000 2019-08-05 100210 8620000 2019-09-25 192827 353155 36665088EOS 69900000 2019-07-21 210001 75300000 2019-08-22 040804 5402099 144198985

Table 5 Block coverage

RegionBTC ETH EOS

Longest Stale Longest Stale Irreversible StaleAS-East 10000 1 330000 23160 mdash mdashAS-South 10000 3 330000 23160 5400000 2087EU-North 10000 4 330000 23159 5400000 2094EU-West 10000 2 330000 23157 5400000 2087NA-Northeast 10000 3 330000 23160 5400000 2151

US-Central 10000 1 330000 23159 5400000 2085US-East 10000 3 330000 23160 mdash mdashUS-West 10000 4 330000 23155 5400000 2099

Bitcoin (left)Ethereum (right)EOS (left)

0

0002

0004

0006

0008

001

0012

0014

Freq

uenc

y (E

ther

eum

)

2 64 5 81 3 7 of combined measurement points

0

00001

00002

00003

00004

00005

00006

00007

Freq

uenc

y (B

itcoi

n or

EO

S)

Figure 3 Unseen transaction probability distribution

∆(ts0 ts1) Bitcoin

∆(ts0 ts1) Ethereum

∆(ts0 ts1) EOS

∆(ts0 ts7) Bitcoin

∆(ts0 ts7) Ethereum

∆(ts0 ts5) EOS

0

02

04

06

08

1

Cum

ula

tive

freq

uen

cy

1000001 1 10001 100001

Time difference (seconds)

Figure 4 Block arrival time accuracy

Security and Communication Networks 5

variables for all block arrival events It shows that thetimestamps are tight as more than 90 of the blocks arrivedwith a time difference less than 100ms Although Bitcoinblock arrivals can be delayed by another block time interval( sim 10 minutes) sim 80 of the blocks are not dispersed bymore than one second EOS blocks show an order-of-magnitude-smaller dispersion in the worst case e longtails implying that block arrival times can be very prolongedin a small number of cases are commonly observed forBitcoin in the literature [32 34]

Consider an ordered arrival timestamp of transaction t

observed at all measurement points M tsi|0le ilt n(M)1113864 1113865

arrival(t)m|forallm isinM where tsi lt tsj for all ilt jlt n(M)Figure 5 shows the distribution of Δ(ts0 ts1) Δ(ts0 ts3) andΔ(ts0 ts7) for Bitcoin transactions Similar to Bitcoin blocksthe long tail shows that the transaction arrival times can bedispersed more than 5 seconds for 5 of the transactions Inthe meantime Δ(ts0 ts1) is tight as more than 99 of thetwo earliest arrivals are not dispersed more than 1 secondEthereum and EOS transactions exhibit much tighterΔ(ts0 ts1) showing that more than 98 of the transactionarrivals are less than 100 milliseconds apart

4 Block and Transaction Discrepancies

In this section we study the discrepancies in blocks andtransactions between the main chain and our observedevents

41 Blockchain Fork As all main chain blocks are observed(ie Bunseen empty) through our measurement the discrep-ancy in blocks only appears as stale blocks (ie Bstale) Anincident of having stale blocks is also called a blockchain forkwhere one or more blocks are appended to a different branchof the main chain

411 Fork Characteristics and Examples A nonoverlappingblockchain fork episode e at block height [m n) is defined byidentifying two blocks

(i) Fork initiating block bf isin Bmain where height(bf)

m and n(children(bf))gt 1(ii) Fork resolving block br isin Bmain where height(br)

n and children(bi) empty for all bi isin Sn

Sn bi|height(bi) n and bi notin Bmain1113864 1113865 Figure 6(a) il-lustrates our fork episode model

We define three characteristic variables (i) its run lengthrun minus length(e) n minus m (ii) the weight (ie the number ofstale blocks in the episode) weight(e) 1113936

nhm(n(Sh)) and

(iii) the fork degree (ie the maximum number of forkbranches) degree(e) maxmlehlen(n(Sh) + 1) Figure 7 showshow characteristic variables are distributed and our findingsare summarized as follows

(i) Due to its long block time (ie sim10minutes) and lowstale block probability (ie lt 005) statisticalcharacterization of Bitcoin fork episodes suffers froma lack of sample events Even three years of live

measurement yield less than a hundred fork episodesas we only expect to observe less than 30 fork eventsper year

(ii) Ethereum fork episodes mostly run one block heightwith a single additional branch e fork degree (iemaximum of branches) is as high as three for sim5 of the episodes and the forks are not immediatelyresolved that is having two or more run lengths inabout 3 of the cases

EOS fork episodes run as long as 12 blocks that is theentire block schedule of a single BP (block producer) [26] asBPs can override the entire block-producing schedule of thepreceding BP

Putting Bitcoin which produces few fork episodes asideEthereum and EOS exhibit very different fork episodepatterns Figure 8 shows two example fork episodes ofEthereum and EOS We have used the commit graphdrawing tool [35] to visualize the fork episodes Figure 8(a)depicts four fork episodes that is [174 176) [177 178)[183 184) and [185 186) of Ethereum and Figure 8(b)shows two EOS fork episodes that is [290 292) and[294 302)e first fork episode [174 176) of Ethereumexhibits the run length of 3 the weight of 4 and the degree of4 with three nonreported (ie thus available only from ourmeasurement) stale blocks e second fork episode[294 302) of EOS exhibits the run length of 9 the weightof 9 and the degree of 2

412 Nonearliest Advertised Block Endorsement of EthereumMiners Our most interesting finding is that Ethereumminers often do not add blocks to the earliest advertisedblock during fork episodes Consider an illustrative forkepisode depicted in Figure 6(b) e episode begins as thethree blocks (ie b1 b2 and b3) are added to the fork ini-tiating block b0 e immediately following blocks (ie bi

and bj) will have their previous blockhash identifying one ofthe three previous blocks of the minerrsquos choice e block bimined by some miner may be added to the earliest block(ie b1) the other block bj is mined by a different miner whochooses a different block (ie b2) to add to To evaluateminersrsquo preference of blocks to which succeeding blocks areadded in the event of blockchain forks we define theconditional probability of miner ma adding a block to aprevious block mined by mb (by not adding to any of adifferent minerrsquos block) in fork episodes for all ma and mb

Pr miner bi( 1113857( mb|miner bj1113872 1113873

ma

prev bj1113872 1113873 bi

existbk height bk( 1113857 height bi( 1113857)

(1)

Figure 9(a) shows a histogram of the above probabilityma (x-axis) adds a block to mbrsquos block (label) over others infork episodes It is apparent that the top ranked minerssignificantly prefer adding blocks to their own mined blocksover other minersrsquo blocks Figure 9(b) depicts the same

6 Security and Communication Networks

bf

br

m

m + 1

n

n + 1

Height

(a)

Time

Arrival (b1)

Arrival (b2)

Arrival (b3)

b0

b1

b2

b3

bi

bj

(b)

Figure 6 Fork analysis model (a) Fork episode (b) Fork resolve example

EthereumEOS

0

02

04

06

08

1

Cum

ulat

ive f

requ

ency

2 4 6 8 10 120 14

Run length

EthereumEOS

0

02

04

06

08

1

Cum

ulat

ive f

requ

ency

2 4 6 8 10 12 140

Weight

EthereumEOS

0

02

04

06

08

1

Cum

ulat

ive f

requ

ency

40 62

Degree

Figure 7 Fork episode characteristics

∆ (ts0 ts1)∆ (ts0 ts3)∆ (ts0 ts7)

0010203040506070809

1Cu

mul

ativ

e fre

quen

cy(

of t

rans

actio

ns)

2 4 6 8 100Time difference (seconds)

(a)

BitcoinEthereumEOS

1 2 3 4 50Time difference (seconds)

0

02

04

06

08

1

Cum

ulat

ive f

requ

ency

( o

f tra

nsac

tions

)

(b)

Figure 5 Transaction arrival time accuracy (a) Transaction arrival time differences of Bitcoin (b) Δ(ts0 ts1) distribution

Security and Communication Networks 7

(a) (b)

Figure 8 Example fork episodes each dot represents a block followed by block hash (last six hexadecimals) arrival time block height (lastthree digits) block timestamp and its miner Each Ethereum stale block is tagged either R (reported uncle) or NR (not reported) Each EOSblock is tagged with the block sequence (out of 12) of the corresponding BPrsquos production schedule (a) Ethereum (b) EOS

SparkPoolEthermine

F2PoolNanopool

MiningPoolHubzhizhutop

Unconditional SparkPool Ethermine F2Pool Nanopool MiningPoolhub

zhizhutop

0

01

02

03

04

05

Freq

uenc

y

(a)

EarliestMixedNonearliest

Spar

kPoo

lEt

herm

ine

F2Po

olN

anop

ool

Min

ingP

oolH

ubzh

izhu

top

UU

Pool

Pand

aMin

erBT

POO

Lxn

pool

Huo

biM

inin

gPoo

lD

war

fPoo

lfir

epoo

lU

nkno

wn

Min

ing

Expr

ess

BTC

com

Pool

Min

eral

lPoo

lBe

ePoo

lH

iveo

nPoo

l2M

iner

sPPL

NS

2Min

ersS

OLO

Coin

otro

nW

POO

LEz

ilPoo

lpo

olin

o

f tot

al fo

rk re

solv

e

(b)

Figure 9 Ethereum fork resolve statistics (a) Probability of ma (x-axis) adding a block to mbrsquos block (b) Probability of adding to the earliestpropagated block

8 Security and Communication Networks

probability by labeling whether or not the chosen block (byma) is the earliest propagated one e ldquoearliestrdquo label in-dicates that the block to which the newly mined block (byma) is added has been observed as the earliest one to arrivecongruently among all eight measurement locations (Asblock arrival times are measured in eight different locationsthe arrival order can be conflicting e ldquomixedrdquo labelrepresents the conflicting cases) For example the topranked pool SparkPool chose the earliest arriving blocksim55 of the time 3409 out of 6234 blocks among the other2825 blocks that were added to nonearliest previous blocksSparkPoolrsquos own blocks were chosen over others 1211 timeswhile other poolsrsquo blocks were preferred to SparkPoolrsquos only24 times In the meantime Nanopool chose the earliest one amajority of the time For the top 25 ranked mining pools onlyfour of them added blocks to the earliest arriving blocks morethan 90 of the timeis contradicts the earliest propagatedblock endorsement assumption that is broadly adopted inmining-related research [36ndash38]

One possible explanation of the phenomenon is that themining pools adopt their own block preferring strategy as asimple precautionary defense against yet unknown selfishmining pools the profitability of selfish mining largelydepends on the probability of honest pools adding to theattacking poolrsquos branch

413 Cut-Tail Fork Pattern of EOS BPs We find that theEOS fork episodes occur in a way that BPs are cutting the tailof the previous BPrsquos produced blocks EOS adopts the DPoSconsensus mechanism [26] 21 block producers (BPs) areelected by voting and scheduled to produce 12 consecutiveblocks in 6 seconds (ie 500ms for each block) in the al-phabetical order of their names Figure 10 shows thenumbers of switching (by schedule) events and cut-tail forkevents of all immediate BP pairs We observe a high fre-quency of such events when bitfinexeos1 is producing blocksby appending to big onersquos blocks while there are accusationsof BPrsquos dishonest behaviors we believe that the reportedbitfinexrsquos performance problem is the compelling reason forthe phenomenon [39]

42 Unseen and Stale Transactions

421 Private Transaction Mining Unseen transactions arecharacterized by the strong evidence that implies that theunseen transactions are indeed never advertised to the net-work Table 6 categorizes 9587 of Ethereum unseentransactions by using the from addresses of the transactions(We use prefixes followed by ⋆ in presenting hash valueseg address (ie pubkey hash) and txid for brevity Weunderstand this does not entirely anonymize identity as thereaders can verify their results against ours by matching theprefixes) Public names are retrieved from Etherscan [16] Aminer is specified in the table only if all blocks that includethe unseen transactions with the from address are con-gruently mined by that single miner It shows that most ofthe unseen transactions are indeed the block minerrsquos owntransactions

Table 7 shows unseen Bitcoin transactions categorized bythe identified reasons sim 67 of the unseen transactions areeither zero-fee transactions or zero-fee-transaction-dependenttransactionsWe define a transaction t isin transactions(b) as adependent transaction if at least one of input transactions oft is included in the same block b

Bitcoin Core [28] implementation does not propagatetransactions with zero transaction fee Also a dependenttransaction cannot be mempooled until the transaction towhich it is dependent is mempooled consequently it cannotbe relayed to peers e Bitcoin Core mempool imple-mentation justifies the inexistence of zero-fee and zero-fee-dependent transactions from our measurement Existence ofa stale transaction which shares the same transaction inputwith the unseen transaction may imply a possible double-spend attempt a variant [40] involving private mining of ablock with ti while advertising a conflict transaction tj suchthat inputs(ti)cap inputs(tj)neempty we have observed 27 suchunseen transactions without a certainty of attack intentionsor if they are not indeed advertised Lastly multisig trans-action inputs often imply off-chain protocols where signedtransactions are exchanged out-of-band [41] and havingOP_RETURN transaction output implies special purposeprotocols of Bitcoin for example sidechains where theirrelationship with miners require further investigation [42]e presence of unseen transactions by either privatetransaction mining or potential out-of-band delivery oftransactions has a subtle security implication One obviousside effect is privatization of transaction fees the transactionfees of privately mined ones are exclusively obtainable by theprivate miner alone unless the network is fully utilized Ifthe network is fully utilized a miner is forced to include herprivate transactions at the expense of not including othertransactions as the block capacity is limited

422 Conflict Stale Transactions Stale transactions arenetwork-transmitted transactions that are not included inany of the blocks

Table 8 shows the stale transaction counts observed ateach location e stale transactions account for 020369 and 047 of Bitcoin Ethereum and EOS transac-tions respectively Ethereum transactions had an order ofmagnitude more chance of being stale than others

As for public blockchains with transaction fees that isBitcoin and Ethereum stale transactions are mostly at-tributable to conflict Table 9 summarizes the identifiedreasons for transactions being stale A stale Bitcoin trans-action is attributable to conflict if there are one or moretransactions sharing at least one transaction input (ie vin)

An Ethereum transaction is attributable to conflict ifthere is another transaction with the same nonce from thesame account A widely known reason for two or moretransactions being in conflict is transaction replacementsuch as replace-by-fee [43] On the other hand slightly morethan 5 of Bitcoin transactions are stale because at least oneof their transaction inputs is also stale

On the other hand roughly one out of ten staleEthereum transactions is attributable to improper ordering

Security and Communication Networks 9

of nonce (e transaction nonce should be equal to thenumber of transactions sent from the address) nonce is toohigh (983) or too low (002) Last but not least 727 ofstale transactions are not included in blocks because theaccount is not sufficiently funded (An Ethereum accountshould have balance ge value+ gastimes gas price to execute thetransaction [44]) An Ethereum account can be

insufficiently funded when executing a transaction for anumber of reasons [45]

423 EOS Transaction Discrepancy EOS exhibits unseenand stale transactions far different from those of Bitcoin orEthereum that is the PoW blockchains with transaction feeEOS software is not bundled with peer discovery rather thenode operator is required to look up for candidate BPrsquospeering services timely delivery of blockchain data andreliability of the node is dependent on the peering nodes ofchoice (Indeed we have experienced service disruption bydisconnecting from peers for unknown reasons)e notionof being conflict in two or more transactions that is themost frequent reason for transactions being stale for Bitcoinand Ethereum is not applicable to EOS (EOS adopts theaccount model without transaction ordering per accountthus there should be no conflict transaction outputs or thesame account nonce) On the other hand EOS requires

eosh

uobi

pool

-eos

infst

ones

eosfl

ytom

ars-

eosh

uobi

pool

zbeo

sbp1

1111

-atti

clab

eosb

attic

labe

osb-

big

one

hoo

com

-new

dex

bpw

hale

exco

m-z

beos

bp11

111

start

eosio

bp-w

hale

exco

meo

sdot

wik

ibp-

eosfl

ytom

ars

eosc

anno

nchn

-eos

dotw

ikib

pbi

gon

e-bi

tfine

xeos

1eo

sinfst

ones

-eos

iom

eeto

nehe

lloeo

scnb

p-ho

oco

meo

slaom

aoco

m-e

ossv

12eo

ssv

slow

mist

iobp

-sta

rteo

siobp

eoss

v12e

ossv

-hel

loeo

scnb

peo

sbei

jingb

p-eo

scan

nonc

hneo

siosg

1111

1-eo

slaom

aoco

meo

siom

eeto

ne-e

osio

sg11

111

bitfi

nexe

os1-

cert

ikeo

sorg

new

dex

bp-s

low

mist

iobp

coch

ainw

orld

-eos

asia

1111

1bi

tfine

xeos

1-co

chai

nwor

ldce

rtik

eoso

rg-c

ocha

inw

orld

eosa

sia11

111-

eosb

eijin

gbp

new

dex

bp-o

kcap

italb

p1eo

siom

eeto

ne-e

osla

omao

com

okca

pita

lbp1

-slo

wm

istio

bpco

chai

nwor

ld-e

osbe

ijing

bpne

wde

xbp

-sta

rteo

siobp

eosa

sia11

111-

eosc

anno

nchn

eosla

omao

com

-hel

loeo

scnb

pco

chai

nwor

ld-e

osca

nnon

chn

cert

ikeo

sorg

-eos

beiji

ngbp

eoss

v12e

ossv

-hoo

com

bitfi

nexe

os1-

eosa

sia11

111

eosin

fston

es-e

osla

omao

com

okca

pita

lbp1

-sta

rteo

siobp

BP switching (left)Cut-tail (right)

0

5000

10000

15000

20000

25000

BP sw

itchi

ng ev

ents

0

100

200

300

400

500

cu

t-tai

l eve

nts

Figure 10 EOS BP switching and cut-tail events

Table 6 Ethereum unseen transactions

From address Public name Transaction count Miner0xea67⋆ Ethermine 128145 (7242) Ethermine0x2a65⋆ DwarfPool 22955 (1297) DwarfPool0x8fd0⋆ Unknown 11346 (641) SparkPool0x829b⋆ F2Pool 4453 (251) F2Pool0x4c54⋆ HiveonPool 1135 (064) SparkPool0x99c8⋆ BeePool 468 (026) BeePool0xdba7⋆ Unknown 348 (020) UUPool0x464b⋆ FKPool 340 (019) FKPool0xf687⋆ Unknown 217 (012) AntPool0xa801⋆ Unknown 151 (009) AntPool0xbe7c⋆ Unknown 126 (007) AntPool0xb96f⋆ Unknown 101 (006) AntPool

Sum 169785 (9587)

Table 7 Bitcoin unseen transactions

Category Transactioncount

Zero-fee transaction 148 (5068)Zero-fee-transaction-dependent transaction 48 (1644)Multisig transaction input 43 (1473)Conflict with stale transaction 27 (925)OP_RETURN transaction output 26 (890)Sum 292 (10000)

10 Security and Communication Networks

contract users to stake tokens for CPU time that can bededucted by transaction executions A requested transactioncan be rejected thus being stale due to the lack of CPU timeor other resources similarly Replaying the entire statechanges of EOS to find out stale transactions due to lack ofresources is not possible unless all transaction and state logsof the entire BPs are available

On the other hand EOS transactions have two additionalattributes which are not available in the Bitcoin or Ethereumtransaction structures

(i) Reference block every EOS transaction refers to ablock by specifying the block number and hash notonly to prevent replay attacks but also to signal thenetwork that the userrsquos stake is on a specific fork

(ii) Expiration time EOS transactions have explicitexpiration times

If a transactionrsquos reference block is not part of the mainchain at the time of execution the transaction cannot beexecuted (and thus cannot be included in a block) We haveidentified that 18 of stale transactions apply to this case Tofurther identify unknown reasons we consider four timedevents that are relevant to transaction execution

(i) Last irreversible block arrival time arrival(blib) thearrival time of transactionrsquos reference block EOStransactions by default refer to the last irreversibleblock (LIB) [26]

(ii) Head block arrival time arrival(bhead) the scheduledtime of the head block when transaction is arrived

(iii) Transaction arrival time arrival(t) the arrival timeof transaction t

(iv) Expiration time exp(t) the expiration time oftransaction t

e three time differences that is Δexp Δincl and Δtrxare investigated to find characteristics of unseen (Tunseen)and stale (Tstale) transactions over the normal transactions(Tincluded) Figure 11 illustrates the relevant events and timedifferences of them Δexp measures the time difference be-tween the two scheduled (ie virtually timed) events Δincland Δtrx are defined by the arrival events to our monitornode Figure 12 shows the distributions of Δexp Δincl andΔtrx We find that unseen transactions have prolonged Δinclimplying that the delay of newly produced blocks can causenewly generated transactions not promptly delivered be-cause the sync manager is in the Head Catch-Up mode astransactions are only transferred in In-Sync mode by itsdesign [24] Stale transactions with relatively small Δtrx canbe attributable to problematic dApp implementations re-ferring to non-LIB blocks the chain instability caused byblockchain fork mostly due to the cut-tail behavior shown inSection 41 can cause transactions being rejected for im-mature block reference

However we do not find any reason attributable to thetransaction expiration Although the unseen transactionstend to have smallΔexp the expiration times are only as smallas 30 seconds (ie the default expiration time) Particularlyone or more EOS applications set the expiration time to180 seconds (other than the default 30 seconds) and morethan half of the stale transactions are invoked by thoseapplications

While transaction is the smallest unit of execution inBitcoin and Ethereum the unit of contract execution in EOSis action [24] A transaction consists of one or more actionsHowever the constituent actions in a single transactioncannot be separately advertised or executed accordingly weapply the identical transaction model to EOS without loss ofgenerality

5 Block and TransactionArrival Characteristics

51 Arrival Processes All three blockchains we study in thispaper are designed to publish capacity constrained blocks intargeted regular time intervals An incarnation of suchdesign is expected to exhibit a Poisson block arrival processWhile it is claimed that Bitcoin block arrivals do not entirelyexhibit a homogeneous Poisson process due to its difficultadjustment mechanism [46] transaction arrival processes ofblockchains are not studied in the literature to the best of ourknowledge A particularly meaningful step toward under-standing the arrival process of events generated by a complexsystem is examining if the arrival events are independent orexhibiting a correlated structure [47]

e variance-time log-log plots [48] of the block andtransaction arrival event time series are depicted in

Table 8 Stale transactions

Region Bitcoin Ethereum EOSAsia-East 41720 1170706 mdashAsia-South 41653 1194018 504277Europe-North 41693 1192435 470480Europe-West 41668 1123680 450140North America-Northeast 41703 1212210 588711US-Central 41683 1212389 505160US-East 41692 1186488 mdashUS-West 41672 1167627 480207Combined 42023 1351847 672999

Table 9 Identified reasons of stale transactions

Category Transaction count(a) Bitcoin

Conflict 39408 (9378)Stale transaction input 2307 (549)Conflict and stale transaction input 308 (073)Sum 42023 (10000)

(b) EthereumConflict 1208588 (8924)Nonce (skipped) 133161 (983)Nonce (used) 251 (002)Insufficient fund 9847 (727)Sum 1351847 (9982)

(c) EOSFork 12106 (180)Others 660893 (9820)Sum 672999 (10000)

Security and Communication Networks 11

Figure 13(a) As regards the block arrival processes Bitcoinblock arrivals exhibit a linear slope β minus23 e estimatedHurst parameter H 1 + β2 43 implies that the processis not a homogeneous Poisson process but LRD (Long-Range Dependent) contrary to what is expected for a regularinterval event generation [46] Ethereum block arrivalsapproximate the Bitcoinrsquos except for the high aggregationlevel due to high stale block rate EOS block arrivals incontrast follow the slope β minus1 in the low aggregation levelas the block generation is indeed regularly scheduled

Figure 14 shows the variance-time plot of Ethereum andEOS block arrival time series by taking all block arrivalevents (Bobs) and main chain block arrivals only (Bmain) Weconfirm that Ethereum block arrivals indeed exhibit astraight line (close to Bitcoin) if excluding stale blocksHowever EOS block arrivals do not exhibit a straight line

even if we exclude stale blocks due to delayed burst blockarrivals possibly due to cut-tail fork patterns (see Section41)

e transaction arrival processes of all three blockchainsappear to exhibit LRD with Hurst parameter Hgt 56 asβltminus13 To further identify analytical distributions that fitbest the empirical ones the coefficient of variation (σμ) andskewness (ie the standardized third moment) of transac-tion interarrival times are computed for every measurementdataset and compared to the relationships expected for theexponential lognormal Weibull and Gamma distributionsin Figure 13(b) We find that Bitcoin Ethereum and EOStransaction interarrival times are fit best Gamma Weibulland lognormal distribution respectively Individual datasetsare also examined for the fitness of the distribution to findthat the empirical distribution fits the analytical distribution

Virtualclock

Time

Transaction initiator

Time

Blockproducer

Time

Monitornode

Time

Scheduled block time of blib

Scheduled block time of bhead

Scheduled block time of bincl

1 Produce and propagate blib

2 Produce and propagate bhead

Expiration time of t

4 Produce and propagate bincl

Δexp

Δtrx

Δincl

3 Create and propagate t

Figure 11 EOS transaction analysis model

Tincluded

Tstale

Tunseen

0010203040506070809

1

Cum

ulat

ive f

requ

ency

100 200 300 400 5000Time difference (seconds)

(a)

Tincluded

Tunseen

01 1 10 100 1000001Time difference (seconds)

0010203040506070809

1

Cum

ulat

ive f

requ

ency

(b)

Tincluded

Tstale

0010203040506070809

1

Cum

ulat

ive f

requ

ency

01 1 10 100 1000001Time difference (seconds)

(c)

Figure 12 EOS transaction timing analysis (a) Δexp (b) Δincl (c) Δtrx

12 Security and Communication Networks

well except for the small interarrival time ranges For ex-ample Figure 15 depicts the CDF of Ethereum transactioninterarrival times observed in US-West Although the em-pirical distribution fits Weibull with parameters computedwith the maximum likelihood estimator [49] sample pointsunder several milliseconds appear to be unreliable (We areyet unaware of the reason However it is known that thetime source of commodity operating systems is not accurateand we need an external time source for accurate sub-millisecond timing measurement [50])

52AdvertisementRedundancy Bitcoin and Ethereum nodepieces of software are implemented to maintain a large

number of peer connections with multiple random remotenodes Bitcoin Core can connect up to 125 peers where 8 ofthem are outbound connections Go Ethereum maintains 50peer connections where 16 of them are outbound by default(see Table 1) On the other hand partitioning attacks aredeveloped to isolate a blockchain node from the others bytampering with all such peer connections Partitioning at-tacks usually exploit vulnerable peer management mecha-nisms of Bitcoin [51] and Ethereum [52] Such attacks arealso examined in the context of ISPrsquos BGP hijacking [53] anda stealthier variant relieving the attacker from the risk ofgetting exposed [54] e attacks often rely on imple-mentation vulnerabilities for efficient eclipsing of peerswhile known vulnerabilities are getting addressed for ex-ample the lack of parallel block download sessions causing

Slope = ndash1

Trx BitcoinTrx EthereumTrx EOS

Blk BitcoinBlk EthereumBlk EOS

ndash12

ndash10

ndash8

ndash6

ndash4

ndash2

0Lo

g no

rmal

ized

var

ianc

e

124 6 10 140 2 8Aggregation level

(a)

Lognormal

Weibull

Gamma

Exponential

BitcoinEthereumEOS

0

5

10

15

20

Stan

dard

ized

third

mom

ent

1 2 3 40Coefficient of variation

(b)

Figure 13 Transaction arrival characteristics (a) Variance-time plot of block and transaction arrivals (b) Cov versus skewness oftransaction interarrival times

Ethereum - Bobs

Ethereum - Bmain

EOS - Bobs

EOS - Bmain

ndash12

ndash10

ndash8

ndash6

ndash4

ndash2

0

Log

norm

aliz

ed v

aria

nce

2 4 6 8 10 12 140Aggregation level

Figure 14 Variance-time plot of block arrivals including staleblocks (Bobs) and excluding stale blocks (Bmain)

EmpiricalExponential μ = 0024

Lognormal μ = 00354 σ2 = 00486Pareto k = 0000212 a = 0231Weibull c = 0589 a = 00147

00001 0001 001 01 1000001Time (seconds)

0

02

04

06

08

1

Cum

ulat

ive f

requ

ency

Figure 15 Empirical and fitted analytical distributions of Ether-eum transaction interarrival times

Security and Communication Networks 13

temporary denial of blocks (reported in [27] and fixed byrecommending three concurrent download sessions in [55])let attackers successfully partition the node without eclipsingall peer connections [53] A simple countermeasure of in-creasing the number of peer connections on the other handis applied to the reference public blockchain implementa-tions [56 57] to inflate attack complexity

We investigate the degree of a peerrsquos advertisementredundancy on newly generated blocks and transactions toevaluate the efficacy of partitioning attacks and the coun-termeasure of increasing the number of peer connectionsFigure 16 shows how redundantly newly generated blockinformation is offered by peers Bitcoin nodes have main-tained sim43 peer connections that is 8 outbound and ad-ditional 35 inbound connections on average and Ethereumnodes record all 50 peer connections established during theentire observation period

For each newly generated block one-third of peersadvertised the block header to our Bitcoin node and morethan 90 of Ethereum peers signaled availability of theblocks In consequence successfully partitioning a noderequires compromise of peers proportional to the totalnumber of peer connections Increasing the number of peerconnections will burden the attacker linearly as expected

Figure 17 shows how redundantly the newly generatedtransaction information is offered by peers While one out ofthree Bitcoin peers also advertises new transactions viaINVENTORYmessage [58] half of the Ethereum peers havesent new transactions to our node in average Bitcoin andEthereum blocks are advertised with the block header(rather than the direct delivery of all block contents) Bitcointransactions are also advertised with INVENTORY messagebefore the whole contents are transferred HoweverEthereum transaction data that is the entire contents aredirectly sent by peers (Ethereum now has a pooled trans-action delivery model in its newer ETH64 protocol [30])We also find that there are cases with much less advertisedtransactions and have identified that they are indeed mostlystale ones stale transactions are mostly due to conflict (seeSection 42) and the nodes that already queued the conflicttransaction will not relay the stale one

6 Discussion

61 Implication on Mining Attacks Cryptocurrency mininghas been a popular subject in assessing the security ofBitcoin selfish mining [37] block withholding attack [36]and a mixed strategy [38] have been studied Although it isshown that selfish behavior in mining is always moreprofitable than being honest without need for a mutualagreement of not attacking each other [38] we find thatselfish mining is not the preferred strategy All selfish miningstrategies will result in blockchain forks but we observe avery low fork probability (ie 004) for Bitcoin On theother hand selfish mining on Ethereum has been studiedonly recently to unanimously claim that selfish mining isalso profitable for Ethereum miners however it is lessprofitable than Bitcoin due to its uncle reward system [59]Our result in Section 4 shows that a majority of Ethereum

miners choose to add to their own produced blocks over theearliest propagated blocks How does this affect the selfishmining strategy

e selfish mining strategy assumes a parameter c whichdefines the fraction of honest minersrsquo mines on the attackerrsquosfork branch (e parameter comes into play in case (f ) of[27]) If the attacking pool has a network-wise superiorposition in block propagation (ie cgt 05) the selfishmining strategy is profitable for pools with proportionalmining power αgt 25 [37] Absolute network inferiority(ie c 0 due to a defensive mining strategy such as the onepresented in Section 41) increases the required miningpower to 33 the 33 mining power appears to be sig-nificantly harder to achieve in the real world [20]

As for the FAW (Fork-After-Withholding) attackstrategy [38] the network capability parameter C defines theprobability that an attackerrsquos FPoW (Full Proof-of-Work)block (during infiltration mining) is selected as a main chainblock C affects both the attack reward and whether theminerrsquos dilemma holds or not in the mutual attacking gameAs an example case (Section 9 of [38]) of a two-pool gamebetween F2Pool and BitFury the absolute network inferi-ority drops C from 0914 to 03 to make it a dilemmatic gameagain Unfortunately minersrsquo own block preferences cannotbe directly transferred to a single parameter of c or C it callsfor a model change from previous mining studies

62 Conflict Transactions and Double-Spending AttacksDouble-spending attacks have been studied in the context ofBitcoin fast payments where zero or only one confirmation isrequired to complete an offline merchandise transaction[60] real-world cases where two conflict transactions dis-parately arrive at different measurement locations mayimply such attacks Table 10 shows the cases where twotransactions are in conflict (and thus only one of themis included in a block ie inputs(ti)cap inputs(ts)neemptyand existb isin Bmain ti isin transactions(b) (∄b isin Bmain ts isintransactions(b) is indisputable given a consistent transactionledger)) and two different subsets of the monitors havemempooled either one of them We also have identified 27unseen transactions implying possible one-confirmationattack variant requiring the private mining (ie not ad-vertising the double-spending transaction to the network) in

5 10 15 20 25 30 35 40 45 500 of peers

0

005

01

015

02

025

Freq

uenc

y

BitcoinEthereum

Figure 16 Peer redundancy of block advertisement

14 Security and Communication Networks

Section 42 As for the countermeasure of such attacks bydeploying monitors [60] deployment of 8 monitors in thenetwork to detect the attacks would fail at most 27 out of 95times (sim30) assuming that those 27 unseen transactionswe have identified are initially advertised to the network

63 Potential Impact on Blockchain ApplicationsEthereum and EOS are the most widely used smart contractplatforms fostering various decentralized applications Bit-coin which lacks the capability of executing complex smartcontract codes is also recently utilized to execute smartcontracts for decentralized applications [50 61] Eventhough our work focuses on the fundamental blockchainmechanisms in terms of transactionblock production andpropagation the impact of our findings on decentralizedapplications can be foresighted

According to our blockchain fork results (Section 41)the lack of selfish mining in the real world was speculated bya very low stale block rate of Bitcoin network and prevalenceof nonearliest block endorsement by Ethereum miners Asprofitability of selfish mining encourages miners to behavein a way of producing more blockchain forks the perfor-mance degradation is proportionate to the number of minerswho adopt the selfish mining strategy the key performancemetrics affecting the blockchain application performance

such as node response time or block delivery time are shownto be noticeably degraded due to the selfish mining [62] Forexample decentralized identities issued or revoked on suchblockchains [63 64] cannot be responsively finalized due toinflated blockchain forks Our results show that the selfishmining is not prevalent in the real world thus the appli-cation performance impact is overrated even though it istheoretically shown that miners have every reason to beselfish [38] As for EOS we reported cases where a sequenceof (up to 12) blocks being stale are often observed in suc-cessive mining of two BPs however the rate is too low (ie004) to impact the performance of applications (Section32)

Transaction arrival processes being LRD (Section 51)pose a technical challenge in provisioning transactionprocessing scalability especially for Layer-2 blockchain ap-plication solutions [65 66] For example Layer-2 rollupsolutions require transaction relays which aggregate indi-vidual user transactions of a given blockchain applicationdeployed in the network often without a priori knowledge ofnetwork load One way of solving the problem is a properprioritization of transactions based on the applicationcontext

Lastly blockchain network partitioning can be thebiggest concern for blockchain service providers We ob-served that the increased numbers of peer connections inblockchain reference implementations effectively provide ahigher degree of information redundancy (Section 52)However increased number of peer connections can beexploitable for an attacker who has a denial-of-service attackvector or an invalid transaction initiated by a simple ap-plication bug can flood the network [45]

64 Limitation Our measurement study has several limi-tations First of all our results may only capture only a fewmonths of blockchain network operations In the meantimethe permissionless blockchain pieces of software are in activedevelopment for example Ethereum now utilizes the pooledtransaction delivery [67] instead of unsolicited transactiondelivery which was the only mode at the time of our

Table 10 Bitcoin disparately mempooled transactions

monitors mempooledti

monitors mempooledts

Transactioncount

7 1 26 (3824)6 2 14 (2059)5 3 10 (1471)4 4 5 (735)3 5 5 (735)2 6 3 (441)1 7 3 (441)5 1 1 (147)6 1 1 (147)

Sum 68 (10000)

Tincluded

Tstale

5 10 15 20 25 30 35 40 45 500 of peers

0

005

01

015

02

025

03Fr

eque

ncy

(a)

Tincluded

Tstale

0002004006008

01012014016

Freq

uenc

y

4030 500 10 20 of peers

(b)

Figure 17 Peer redundancy of transaction advertisement (a) Bitcoin (b) Ethereum

Security and Communication Networks 15

measurement Both cryptocurrency market values andblockchain network utilizations are rapidly increasing andthus miners are getting more motivated to optimize theirperformance for example Bitcoin fork probability has be-come far smaller than what is reported previously (seeSection 41)

Second the blockchain state information is not collected inour measurement Our analysis is performed based on onlyavailable information stored in block and transaction logs Wehave utilized an Ethereum archive node [44] to query historicalstate information (eg account balance or account nonce) inSection 42 However such proactive state replication is farmore complicated with EOS unless the full node is configuredto operate as a producing node and logging the state infor-mation thus EOS stale transactions could not be fully un-derstood without the missing EOS network state information

7 Related Work

71 Blockchain Data Analysis Historical transaction data ofBitcoin have often been studied for economic aspects such ascryptocurrency abuse [17] anti-money-laundering [18] andmonetary flow of businesses [19] However historicalblockchain data usually available from block explorer ser-vices are not sufficient for our research purpose

72 Blockchain Measurement Researchers have performedblockchain measurement studies to assess the degree ofdecentralization [20] to investigate demographic informa-tion of network nodes [34 68] to study mining pool be-havior [22] and to evaluate security of PoW blockchains [21]against known attacks such as double-spending attack [60]and selfish mining [37] Our work expands the under-standing of previous security evaluations with the keyfindings acquired from our large-scale transaction and blockmeasurement

73 Blockchain Attacks Partitioning attacks usually exploitvulnerable peer management mechanisms of Bitcoin [51]and Ethereum [52] Such attacks are also examined in thecontext of ISPrsquos BGP hijacking [53] and a stealthier variantrelieving the attacker from the risk of getting exposed [54]Cryptocurrency mining has been a popular subject inassessing the security of Bitcoin selfish mining [37] blockwithholding attack [36] and a mixed strategy [38] have beenstudied Double-spending attacks have been studied in thecontext of Bitcoin fast payments [60]

74 Block Explorer Services We have surveyed the popularblock explorer services of Bitcoin [5 10 12] Ethereum[10 13 16] and EOS [11 14 15] to see the availability ofinformation beyond what is recorded in the main chainblock data we have utilized in our study namely

(i) Stale blockstransactions no Bitcoin and EOS blockexplorers provide stale block information (A relatedstudy [36] has utilized a Bitcoin block explorer service[68] to retrieve stale blocks However the service has

been terminated in March 2019) All Ethereum blockexplorers provide only reported stale blocks (ie uncleblocks [23]) (Ethereum provides incentives for unclestale blocks [44] so that miners include them in theirmined blocks for profit)No block explorers provide stale transaction infor-mation unless one is currently pooled

(ii) Blocktransaction arrival times all block explorersprovide block timestamps that are recorded in theblock headers not the actual times of arrival Ourblockchain fork and gap analysis require measuredblock arrival times at multiple locations All blockexplorers show transaction timestamps identical to theblock timestamp to which the transactions belong(Recent Bitcoin transactions have different timestampsthan the block timestamps in [4] while the timestampsare only at a granularity of one minute) [69 70]

8 Conclusion

We have measured transaction and block arrival events ofthe three permissionless blockchains We have devised anoble analysis model and analyzed completeness of ourblock and transaction logs Finally we have studied thediscrepancy in measured events and arrival characteristics toshare our key findings including a false universal assumptionof previous mining-related studies

Data Availability

e measurement data used to support the findings of thisstudy have not been made available because they containprivate information that can be used to identify individualblockchain nodes

Disclosure

is is an extended and revised version of a conference paperpresented in IEEE ICDCS 2021 [41]

Conflicts of Interest

e authors declare that they have no conflicts of interest

Acknowledgments

e authors would like to thank Seungwon Woo DaegeunYoon and Changhyun Lee for helping them with themeasurement instrumentation is work was supported byElectronics and Telecommunications Research Institute(ETRI) grant funded by the Korean Government (21ZR1300Research on Intelligent Cyber Security and Trust Infra)

References

[1] S Nakamoto ldquoBitcoin a peer-to-peer electronic cash systemrdquo2019

[2] V Buterin ldquoEthereum white paperrdquo 2013 httpsethereumorgenwhitepaper

[3] Monero ldquoMonerordquo 2020 httpswebgetmoneroorg

16 Security and Communication Networks

[4] bitcoincashorg httpswwwbitcoincashorg[5] Blockchaincom httpswwwblockchaincom[6] Ripple ldquoXRP e best digital asset for global paymentsrdquo

2020 httpsripplecomxrp[7] I Foundation ldquoIotardquo 2021 httpswwwiotaorg[8] ldquoEosiordquo 2020 httpseosio[9] S Orsquoneal ldquoEos proves yet again that decentralization is not its

priorityrdquo 2018 httpscointelegraphcomnewseos-proves-yet-again-that-decentralization-is-not-its-priority

[10] Blockchair httpsblockchaircom[11] Bloksio httpsbloksio[12] BTCcom ldquoBitcoin block explorerrdquo 2021 httpsbtccom[13] Ethereum block explorer httpsethbtccom[14] eosflareio Eos block explorer httpseosflareio[15] EOSPark ldquoEos block explorerrdquo 2021 httpseosparkcom[16] Etherscan Ethereum explorer httpsetherscanio[17] S Lee C Yoon and H Kang ldquoCybercriminal minds An

investigative study of cryptocurrency abuses in the dark webrdquoin Proceedings of the Network and Distributed System SecuritySymposium pp 1ndash15 Internet Society San Diego CA USAFebruary 2019

[18] MMoser R Bohme and D Breuker ldquoAn inquiry into moneylaundering tools in the bitcoin ecosystemrdquo in Proceedings ofthe 2013 APWG eCrime Researchers summit pp 1ndash14 IEEESan Francisco CA USA September 2013

[19] M Lischke and B Fabian ldquoAnalyzing the bitcoin network thefirst four yearsrdquo Future Internet vol 8 no 1 2016

[20] A E Gencer S Basu I Eyal R V Renesse and E G SirerldquoDecentralization in bitcoin and ethereum networksrdquo inProceedings of the International Conference On FinancialCryptography and Data Security pp 439ndash457 SpringerNieuwport Curaccedilao February 2018

[21] A Gervais G O Karame KWust V Glykantzis H Ritzdorfand S Capkun ldquoOn the security and performance of proof ofwork blockchainsrdquo in Proceedings Of the 2016 ACM SIGSACConference on Computer and Communications Securitypp 3ndash16 Vienna Austria October 2016

[22] C Wang X Chu and Q Yang ldquoMeasurement and analysis ofthe bitcoin networks a view from mining poolsrdquo 2019httpsarxivorgabs190207549

[23] G Wood ldquoEthereum A secure decentralised generalisedtransaction ledgerrdquo Ethereum Project Yellow Paper vol 1512014

[24] ldquoTransactions protocol eosio developer docsrdquo 2018 httpsdeveloperseosiowelcomev20protocoltransactions_protocol

[25] Y Sompolinsky and A Zohar ldquoSecure high-rate transactionprocessing in bitcoinrdquo in Proceedings of the InternationalConference On Financial Cryptography and Data Securitypp 507ndash527 Springer San Juan PR USA January 2015

[26] Blockone ldquoConsensus protocolrdquo 2018 httpsdeveloperseosiowelcomev20protocolconsensus_protocol

[27] A Gervais H Ritzdorf G O Karame and S CapkunldquoTampering with the delivery of blocks and transactions inbitcoinrdquo in Proceedings Of the 22nd ACM SIGSAC ConferenceOn Computer and Communications Security pp 692ndash705Denver CO USA October 2015

[28] ldquoGithub Bit coinrdquo 2020 httpsgithubcombitcoinbitcoin[29] G Ethereum ldquoGo ethereumrdquo 2020 httpsgithubcom

ethereumgo-ethereum[30] Google ldquoGoogle cloudrdquo 2021 httpscloudgooglecom[31] ldquoHow to replay from a snapshotrdquo 2018 httpsdeveloperseos

iomanualseoslatestnodeosreplayshow-to-replay-from-a-snapshot

[32] C Decker and R Wattenhofer ldquoInformation propagation inthe bitcoin networkrdquo in Proceedings of the IEEE P2P 2013Proceedings pp 1ndash10 IEEE Trento Italy September 2013

[33] ldquoEthereum uncle raterdquo 2020 httpsychartscomindicatorsethereum_uncle_rate

[34] J A Donet C P Sola and J H Joancomartı ldquoe bitcoin p2pnetworkrdquo in Proceedings of the International Conference OnFinancial Cryptography and Data Security pp 87ndash102Springer Christ Church Barbados March 2014

[35] G S Davies ldquoBit-booster - offline commit graph drawingtoolrdquo 2016 httpbit-boostercomgraphhtml

[36] N T Courtois and L Bahack ldquoOn subversive miner strategiesand block withholding attack in bitcoin digital currencyrdquo2014 httpsarxivorgabs14021718

[37] I Eyal and E G Sirer ldquoMajority is not enough bitcoin miningis vulnerablerdquo in Proceedings of the International Conferenceon Financial Cryptography and Data Security pp 436ndash454Springer Christ Church Barbados March 2014

[38] Y Kwon D Kim Y Son E Vasserman and Y Kim ldquoBeselfish and avoid dilemmas fork after withholding (faw) at-tacks on bitcoinrdquo in Proceedings Of the 2017 ACM SIGSACConference On Computer and Communications Securitypp 195ndash209 Abu Dhabi UAE April 2017

[39] B Research ldquoDecentralisation governance and eos - a lostcaserdquo 2020 httpsresearchbinancecomenanalysiseos-governance

[40] B Wiki ldquoIrreversible transactions - finney attackrdquo 2012httpsenbitcoinitwikiIrreversible_Transactions∖Finney_attack

[41] J Poon and T Dryja ldquoe bitcoin lightning network scalableoff-chain instant paymentsrdquo 2016

[42] M Bartoletti and L Pompianu ldquoAn analysis of bitcoin op_return metadatardquo in Proceedings of the International Con-ference On Financial Cryptography and Data Securitypp 218ndash230 Springer Sliema Malta April 2017

[43] ldquoReplace by feerdquo 2018 httpsenbitcoinitwikiReplace_by_fee

[44] E Foundation ldquoNode and clientsrdquo 2020 httpsethereumorgendevelopersdocsnodes-and-clients

[45] H Heo and S Shin ldquoBehind block explorers public block-chain measurement and security implicationrdquo in Proceedingsof the 41th IEEE International Conference On DistributedComputing Systems IEEE Washington DC USA In pressWashington DC USA July 2021

[46] R Bowden H P Keeler A E Krzesinski and P G TaylorldquoBlock arrivals in the bitcoin blockchainrdquo 2018 httpsarxivorgabs180107447

[47] M E Crovella and A Bestavros ldquoExplaining world wide webtraffic self-similarityrdquo Technical Report Citeseer PrincetonNJ USA 1995

[48] H Zhang Y Shu and O Yang ldquoEstimation of hurst pa-rameter by variance-time plotsrdquo in Proceedings of the 1997IEEE Pacific Rim Conference on Communications Computersand Signal Processing PACRIM 10 Years Networkingthe Pacific Rim 1987-1997 IEEE Victoria BC CanadaAugust 1997

[49] A Feldmann ldquoCharacteristics of TCP connection arrivalsrdquo inSelf-Similar Network Traffic and Performance EvaluationK Park andWWillinger Eds pp 367ndash399Wiley HobokenNJ USA 2000

[50] RSK ldquoRSKrdquo 2021 httpswwwrskco[51] E Heilman A Kendler A Zohar and S Goldberg ldquoEclipse

attacks on bitcoinrsquos peer-to-peer networkrdquo in Proceedings of

Security and Communication Networks 17

the 24th USENIX Security Symposium pp 129ndash144 Wash-ington DC USA April 2015

[52] Y Marcus E Heilman and S Goldberg ldquoLow-resourceeclipse attacks on ethereumrsquos peer-to-peer networkrdquo IACRCryptology vol 2018 p 236 2018

[53] M Apostolaki A Zohar and L Vanbever ldquoHijacking bitcoinRouting attacks on cryptocurrenciesrdquo in Proceedings of the2017 IEEE Symposium On Security and Privacy (SP)pp 375ndash392 IEEE San Jose CA USA May 2017

[54] M Tran I Choi G J Moon A V Vu and M S Kang ldquoAstealthier partitioning attack against bitcoin peer-to-peernetworkrdquo in Proceedings of the IEEE Symposium On Securityand Privacy (SampP) San Francisco CA USA May 2020

[55] B I Proposal ldquoBip 0152rdquo 2016 httpsenbitcoinitwikiBIP_0152

[56] B Core ldquoBitcoin Core Version 01901 Release Noterdquo 2016httpsbitcoinorgenreleasev01901

[57] ldquoGeth v190rdquo 2019 httpsblogethereumorg20190710geth-v1-9-0

[58] ldquoProtocol documentationrdquo 2016 httpsenbitcoinitwikiProtocoltext_documentation

[59] C Feng and J Niu ldquoSelfish mining in ethereumrdquo in Pro-ceedings of the 2019 IEEE 39th International Conference OnDistributed Computing Systems (ICDCS) pp 1306ndash1316IEEE Dallas TX USA July 2019

[60] G O Karame E Androulaki and S Capkun ldquoDouble-spending fast payments in bitcoinrdquo in Proceedings of the 2012ACM Conference on Computer and Communications Securitypp 906ndash917 Raleigh NC USA October 2012

[61] P Das L Eckey T Frassetto et al ldquoFastkitten practical smartcontracts on bitcoinrdquo in Proceedimgs of the 28th USENIXSecurity Symposium (USENIX Security 19) pp 801ndash818Santa Clara CA USA August 2019

[62] S G Motlagh J Misic and V B Misic ldquoe impact of selfishmining on bitcoin network performancerdquo IEEE Transactionson Network Science and Engineering vol 8 no 1 pp 724ndash7352021

[63] A Muhle A Gruner T Gayvoronskaya and C Meinel ldquoAsurvey on essential components of a self-sovereign identityrdquoComputer Science Review vol 30 pp 80ndash86 2018

[64] M Toorani and C Gehrmann ldquoA decentralized dynamic pkibased on blockchainrdquo in Proceedings Of the 36th Annual ACMSymposium On Applied Computing pp 1646ndash1655 GwangjuKorea March 2021

[65] E foundation ldquoOptimistic-rollupsrdquo 2021 httpsdocsethhubioethereum-roadmaplayer-2-scalingoptimistictext_rollups

[66] ldquoZk-rollupsrdquo 2021 httpsdocsethhubioethereum-roadmaplayer-2-scalingzk-rollups

[67] E foundation ldquoEthereumwire protocolrdquo 2019 httpsgithubcomethereumdevp2pblobmastercapseth

[68] S K Kim Z Ma S Murali J Mason A Miller andM BaileyldquoMeasuring ethereum network peersrdquo in Proceedings of theInternet Measurement Conference 2018 pp 91ndash104 BostonMA USA October 2018

[69] Symmetricom ldquoDelivering sub-microsecond accurate time tolinux applications around the worldrdquo 2012 httpwwwchronoscoukfilespdfswpsWP_AccurateTimeForLinuxApplicationspdf

[70] Ycharts ldquoBlocktrail blockchain data query service (termi-nated)rdquo 2019 httpsblocktrailcom

18 Security and Communication Networks

which transactions are flattened that is appear as if si-multaneously arriving at the time of block arrival and onlythose included in the main chain blocks are visible Forexample the arrival times of t0 and t1 can be only bound tothe timestamp of b10 in the historical view as there are noseparate timestamps for transaction records Transactionsand blocks can also be stale that is not included in blocks ornot part of the main chain respectively or not even ex-plicitly advertised if observed under the hood For examplethe stable block b11 which is not the part of the main chaincannot be found on the historical record the stale trans-action t2 that fails to be included in a block will not berecorded either e measurement view can provide a richand dynamic transaction and block arrival event logs on theother hand

In this paper we conduct an in-depth analysis of large-scale block and transaction arrival event measurement of thethree popular blockchains Bitcoin Ethereum and EOSeblock and transaction logs which are not visible from themain chain block data are investigated to reveal our findingsthat shed light on the understanding of how permissionlessblockchain systems work Specifically we make the fol-lowing major contributions

(i) Transaction and block arrival events of the threepopular permissionless blockchains are measured ineight geographically dispersed locations Ourmeasurement is underpinned by a noble analysismodel and supporting results of measurementsoundness

(ii) We perform a quantitative analysis on the dis-crepancy between observed events and the publicblock data We further study the block discrepancyin terms of blockchain forks to show that the as-sumption universally adopted by mining-relatedresearch does not hold for Ethereum

(iii) We analyze transaction arrival processes to findthat they indeed exhibit LRD (Long-Range De-pendence) We provide analytical distributionsthat fit best the permissionless blockchains westudy

2 Background

21 Blockchain e blockchain stores transactions in theunit of blocks Transactions are defined differently perblockchain system it commonly represents a single transferof cryptocurrency values Ethereum further defines that atransaction is an action initiated by an externally owned

account to modify the state stored in the blockchain network[23] An EOS transaction is the set of one or more suchactions [24]

A miner (or a block producer) can add a block to thechain by publishing it over the network hoping that herpublished block will become the part of the canonical chain(We also call it the main chain in this paper) upon suc-cessful mining (or block production) she gets rewarded inits native cryptocurrency

We call the blockchain permissionless if anyone canparticipate in the mining process Consequently there canbe temporarily more than one candidate block to be in-cluded in the main chain and we call such cases blockchainforks e main chain refers to the longest [1] heaviest-subtree [25] and irreversible [26] chain for BitcoinEthereum and EOS respectively

Bitcoin and Ethereum adopt PoW (Proof-of-Work)consensus mechanism where mining of a block is performedby solving the computationally demanding cryptopuzzlesOn the other hand EOS adopts DPoS (Delegate Proof-of-Stake) consensus mechanism where the set of block pro-ducers who later produce scheduled blocks in turn iselected by EOS stakeholders Table 1 summarizes the threeblockchains we study in this paper

22 ResearchQuestions Our study aims to shed light on theunderstanding of various aspects of blockchains obscuredfrom a historical view Specifically we have focused on threeresearch questions

RQ1 Are network-advertised transaction logsconsistent with the transactions included in mainchain blocks

(i) (Preview on our findings) No Basically theblockchain transaction arrival processes are moreLRD (Long-Range Dependent) than those of theblocks (Section 51) ere are unadvertised trans-actions that are directly inserted by miners im-plying privatization of transaction fees Advertisedtransactions also may end up being stale that is notincluded in blocks mostly due to conflict transac-tions which instead get placed in blocks (Section42)RQ2 Do miners behave rationally (or selfishly) tomaximize their profit (Do miners endorse earliestpropagated blocks in the event of blockchain forks)

(ii) (Preview on our findings) No Bitcoin fork eventsnow have become too rare (004) implying that

b10 b13

t1t0 t5

Timeb12

t4t3

b14

t7t6Transaction

arrivalsBlock

arrivals

(a)

b10 b13b11

t0 t1 t2 t5t3 t6

Time

TransactionarrivalsBlock

arrivalsb12

t4

b14

t7 t8

(b)

Figure 1 Two viewmodels of blockchain events ti are transaction arrival events and bi are block arrival events grey-colored events are onlyobservable in the measurement view (a) Historical view (b) Measurement view

2 Security and Communication Networks

selfish mining is not the preferred strategy for Bitcoinminers On the other hand the majority of Ethereumminers add blocks to their own mined blocks ratherthan the earliest propagated ones that are mined byother pools this contradicts the unarguably adoptedassumption of previous studies (Section 41)RQ3 Do blockchain nodes effectively get away frompartitioning attacks by virtue of information re-dundancy from multiple peers (Are they stillvulnerable to partitioning attacks)

(iii) (Preview on our findings) Yes e referenceimplementations of PoW blockchains have in-creased the number of (outbound) peer connectionsand consequently the up-to-date nodes benefitfrom redundant block advertisement from 14 to 46peers for Bitcoin and Ethereum respectively (Sec-tion 52) tampering with a small number of peerswill not successfully partition or make a node un-synchronized for minutes [27]

23 AnalysisModel Although the three blockchains operatedifferently (as summarized in Table 1) in many ways theycan be commonly modeled with the following

(i) Blocks are produced by miners (or block producers)and are broadcast to the network by peer connec-tions A block b is uniquely identified with itsblockhash and refers to its parent block bp (ieprev(b) bp) e arrival time of b at a measure-ment point m (ie arrival(b)m) is the arrival time ofb from one of mrsquos peers who delivers b for the firsttime e block b can be included in the main chain(ie Bmain) or it can be stale (ie b notin Bmain)

(ii) Transactions are composed and propagated by usersthrough a P2P network A transaction t is uniquelyidentified with its txid e arrival time of transac-tion t at a node m (ie arrival(t)m) is the arrival timeof t from one of mrsquos peers who delivers t for the firsttime e transaction t can be included in block b

(ie t isin transactions(b)) or be stale (iet notin transactions(b)forallb isin Bmain)

e set of notations is summarized in Table 2 and thefunctions used in the definition are listed in Table 3

Our model comprises the two arrival events that isblock and transaction arrival events where a single block

arrival event is mapped to zero or more transaction events(ie ti isin transactions(b)) by the function transactions(middot)

(Bitcoin coinbase transactions are excluded in our analysis asthey are not advertised to the network)

Figure 2 depicts how we analyze our measurements Instudying the discrepancy in block and transaction events(Section 4) the arrival events near the measurement bound-aries significantly affect our quantitative analysis For exampleincluding or excluding a single Bitcoin block around themeasurement boundary can produce more than two thousandstale or unobserved transactions To this end we crop themeasurement to the observation period by carefully choosingtwo anchor blocks the preamble block bm and the concludingblock bn for each dataset of blockchains so that our mea-surement satisfies the two following conditions (i) ere is noloss of measurement data (due to the reasons described inSection 31) at any of our eight (Due to unreliable peeringservices of candidate BPs (block producers) of EOS we haverelaxed the conditions to six for EOS) locations in the timeperiod of one week before the arrival of bm and one week afterthe arrival of bn (ii) Both bm and bn belong to the main chain

3 Measurement

31 Data Collection We have modified the referenceimplementations of three popular pieces of blockchainsoftware Bitcoin Core [28] Go Ethereum [29] and EOSIO[8] to facilitate logging of all received transactions andblocks from peers Our monitoring pieces of software aredeployed to eight geographically dispersed regions of theGoogle cloud platform [30] Asia-East Asia-South Europe-North Europe-West North America-Northeast US-Cen-tral US-East and US-West Each VM is configured to havetwo vCPUs 185GB of memory and 800GB of standardpersistent disk Measurements were performed between July2019 and December 2019 by having our monitors which areindeed full nodes on the three blockchain mainnets con-nected to the peers As regards EOS the full node softwarethat is nodeos is neither bundled with default seed peers norfacilitated with a peer discovery mechanism We havemanually collected available peers and fed them Also asnodeos only accepts transaction and block advertisements inIn-Sync mode [24] a recent snapshot [31] is inputted toquickly catch up without throttling CPU and networkbandwidth by syncing from scratch that is the genesisblock Unfortunately we experienced several problems thatresulted in suspension of our monitoring processes For

Table 1 Blockchain summary

Blockchain Consensusmechanism

Blocktime

Transactions per second(all-time high)

Balancemodel

Transactionfee

Peer-to-peer management

Discovery Max peers (Outgoing)

Bitcoin PoW sim10minutes 7 UTXO Yes Random from

seeder list 125 (8)

Ethereum PoW sim10seconds 15 Account Yes Kademlia-like 50 (16)

EOS DPoS 05seconds 4000 Account No (staking) mdash mdash

Security and Communication Networks 3

example the Google cloud platform endeavors to detectcryptocurrency-mining-related activities Once detected theVM instance immediately gets suspended and is reinstatedonly if a reasonable explanation is provided

Furthermore we have noticed a few software crashesVM suspensions by other reasons or temporary lack of diskspace causing loss of measurement data Lastly a majority of

EOS candidate BPs who have provided the peering servicehave gradually stopped their services and only several are leftat the end of our measurement period To eradicate inac-curacy due to the above problems our measurement datasetis trimmed as described in Section 23 Table 4 summarizesour choice of the two anchor blocks and consequent ob-servation period statistics

Table 2 Transaction and block set notation of our measurement framework

Notation Description Definition

Bobse set of blocks observed in the observation

periodbi bi+1 bjminus2 bjminus11113966 1113967 where there is no bk satisfying

arrival(bm)le arrival(bk)le arrival(bi) or arrival(bjminus1)le arrival(bk)le arrival(bn)

Bmaine set of blocks that are included in the

main chainbm+1 bm+2 bnminus1 bn1113864 1113865 where bi prev(bi+1) for all mlt ilt n and bm and bn are

the preamble and concluding blocks respectivelyBstale e set of observed blocks that are stale Bobs minus Bmain

Bunseene set of blocks that are part of the main

chain but not observed Bmain minus Bobs

Tobse set of transactions observed in the

observation periodti ti+1 tjminus2 tjminus11113966 1113967 where there is no tk satisfying

arrival(bm)le arrival(tk)le arrival(ti) or arrival(tjminus1)le arrival(tk)le arrival(bn)

Tpree set of transactions observed before the

observation periodt0 t1 timinus2 timinus11113864 1113865 where there is no tk satisfying

arrival(timinus1)le arrival(tk)le arrival(bm)

Tposte set of transactions observed after the

observation period tj tj+1 1113966 1113967 where there is no tk satisfying arrival(bn)le arrival(tk)le arrival(tj)

Tstalee set of observed transactions that are

stale Tobs minus cupbisinBmain

transactions(b)

Tincludede set of transactions that are observed and

included in the main chain blocks Tobs cap cupbisinBmain

transactions(b)

Tunseene set of transactions that are included inthe main chain blocks but not observed cup

bisinBmain

transactions(b) minus Tpre cupTobs cupTpost

Table 3 Block and transaction functions

Function Descriptionblockhash(b) e hash value of block b

prevhash(b) e previous block hash value of block b

prev(b) e previous block bp of block p ie blockhash(bp) prevhash(b)

height(b) e block height of block b

miner(b) e miner of block b

children(b) e set of child blocks of block b ie height(bc) height(b) + 1forallbc isin children(b)

transactions(b) e set of transactions included in block b

arrival(e) e arrival time of event e where e can be either a block or a transactioninputs(t) e set of transaction inputs (ie vin) of Bitcoin transaction t

outputs(t) e set of transaction outputs (ie vout) of Bitcoin transaction t

nonce(t) e nonce value of Ethereum transaction t

bm bnbm+1

ti ti+1 ti+2 tj-1tj-2 tjtindash1

Time

Transactionarrivals

Blockarrivals

TobsTpre Tpost

bn+1

BobsBpre Bpost

Measurement period

Observation period

bmndash1

Figure 2 Transaction and block analysis model grey-colored events are cropped out for measurement point consistency

4 Security and Communication Networks

32 Measurement Soundness As public blockchain net-works are built on the best-effort serviced overlay network ofP2P connections complete and timed information deliveryis not guaranteed We analyze the completeness of blockarrival events transaction arrival events and their arrivaltime accuracy to underpin the soundness of ourmeasurement

321 Block Coverage Blocks can be part of the main chainor they can be staleWe test our observation against themainchain which is available from a number of block explorerservices to make sure there are no missing blocks

Table 5 shows the observed number of blocks across ourmeasurement points e main chain blocks are all observedwhile stale blocks are partially observed stale blocks beingpartially observed is expected as blockchain nodes are notobliged to propagate stale blocks e stale blocks accountfor only sim004 for Bitcoin and EOS while sim702 of theobserved blocks are stale for Ethereum e stale blockprobability of Bitcoin has been decreasing [21 32] andEthereumrsquos stale block probability is 5 sim 10 larger thanknown uncle rates (calculated only with reported uncles) asour measurement captures unreported stale blocks aswell [33]

322 Transaction Coverage Incomplete transaction mea-surement causes a subset of transactions which are includedin blocks never being observed during measurement Ag-gregating transactions observed from different monitors cancompensate for this incompletenesse unseen transactionsare acquired by subtracting the observed transactions fromthe transactions included in the main chain blocks

Figure 3 shows the probability of unseen transactions(ie n(T

1113954Munseen)n(Tobs)) as a function of the number of

combined measurement points As combining all mea-surement point transaction arrivals results in a convergedfrequency of sim005 for Bitcoin and EOS and sim05 forEthereum it implies that unseen transactions will be stillobserved even if more monitors are deployed to the networkWe further study the unseen transactions in Section 42

323 Timing Accuracy Consider an ordered arrival time-stamp of block b observed at all measurement pointsM tsi|0le ilt n(M)1113864 1113865 arrival(b)m|forallm isinM where tsi lttsj for all ilt jlt n(M) We evaluate the tightness of ourmeasured timing information with Δ(ts0 ts1) and how farthe arrival times can be dispersed among the measurementpoints with Δ(ts0 ts7) where Δ computes the timewisedifference Figure 4 depicts the distribution of the two

Table 4 Observation period statistics

BlockchainPreamble block Concluding block Population

Block height Timestamp Block height Timestamp blocks transactionsBitcoin 587500 2019-07-28 210228 597500 2019-10-02 062237 10004 21454436Ethereum 8290000 2019-08-05 100210 8620000 2019-09-25 192827 353155 36665088EOS 69900000 2019-07-21 210001 75300000 2019-08-22 040804 5402099 144198985

Table 5 Block coverage

RegionBTC ETH EOS

Longest Stale Longest Stale Irreversible StaleAS-East 10000 1 330000 23160 mdash mdashAS-South 10000 3 330000 23160 5400000 2087EU-North 10000 4 330000 23159 5400000 2094EU-West 10000 2 330000 23157 5400000 2087NA-Northeast 10000 3 330000 23160 5400000 2151

US-Central 10000 1 330000 23159 5400000 2085US-East 10000 3 330000 23160 mdash mdashUS-West 10000 4 330000 23155 5400000 2099

Bitcoin (left)Ethereum (right)EOS (left)

0

0002

0004

0006

0008

001

0012

0014

Freq

uenc

y (E

ther

eum

)

2 64 5 81 3 7 of combined measurement points

0

00001

00002

00003

00004

00005

00006

00007

Freq

uenc

y (B

itcoi

n or

EO

S)

Figure 3 Unseen transaction probability distribution

∆(ts0 ts1) Bitcoin

∆(ts0 ts1) Ethereum

∆(ts0 ts1) EOS

∆(ts0 ts7) Bitcoin

∆(ts0 ts7) Ethereum

∆(ts0 ts5) EOS

0

02

04

06

08

1

Cum

ula

tive

freq

uen

cy

1000001 1 10001 100001

Time difference (seconds)

Figure 4 Block arrival time accuracy

Security and Communication Networks 5

variables for all block arrival events It shows that thetimestamps are tight as more than 90 of the blocks arrivedwith a time difference less than 100ms Although Bitcoinblock arrivals can be delayed by another block time interval( sim 10 minutes) sim 80 of the blocks are not dispersed bymore than one second EOS blocks show an order-of-magnitude-smaller dispersion in the worst case e longtails implying that block arrival times can be very prolongedin a small number of cases are commonly observed forBitcoin in the literature [32 34]

Consider an ordered arrival timestamp of transaction t

observed at all measurement points M tsi|0le ilt n(M)1113864 1113865

arrival(t)m|forallm isinM where tsi lt tsj for all ilt jlt n(M)Figure 5 shows the distribution of Δ(ts0 ts1) Δ(ts0 ts3) andΔ(ts0 ts7) for Bitcoin transactions Similar to Bitcoin blocksthe long tail shows that the transaction arrival times can bedispersed more than 5 seconds for 5 of the transactions Inthe meantime Δ(ts0 ts1) is tight as more than 99 of thetwo earliest arrivals are not dispersed more than 1 secondEthereum and EOS transactions exhibit much tighterΔ(ts0 ts1) showing that more than 98 of the transactionarrivals are less than 100 milliseconds apart

4 Block and Transaction Discrepancies

In this section we study the discrepancies in blocks andtransactions between the main chain and our observedevents

41 Blockchain Fork As all main chain blocks are observed(ie Bunseen empty) through our measurement the discrep-ancy in blocks only appears as stale blocks (ie Bstale) Anincident of having stale blocks is also called a blockchain forkwhere one or more blocks are appended to a different branchof the main chain

411 Fork Characteristics and Examples A nonoverlappingblockchain fork episode e at block height [m n) is defined byidentifying two blocks

(i) Fork initiating block bf isin Bmain where height(bf)

m and n(children(bf))gt 1(ii) Fork resolving block br isin Bmain where height(br)

n and children(bi) empty for all bi isin Sn

Sn bi|height(bi) n and bi notin Bmain1113864 1113865 Figure 6(a) il-lustrates our fork episode model

We define three characteristic variables (i) its run lengthrun minus length(e) n minus m (ii) the weight (ie the number ofstale blocks in the episode) weight(e) 1113936

nhm(n(Sh)) and

(iii) the fork degree (ie the maximum number of forkbranches) degree(e) maxmlehlen(n(Sh) + 1) Figure 7 showshow characteristic variables are distributed and our findingsare summarized as follows

(i) Due to its long block time (ie sim10minutes) and lowstale block probability (ie lt 005) statisticalcharacterization of Bitcoin fork episodes suffers froma lack of sample events Even three years of live

measurement yield less than a hundred fork episodesas we only expect to observe less than 30 fork eventsper year

(ii) Ethereum fork episodes mostly run one block heightwith a single additional branch e fork degree (iemaximum of branches) is as high as three for sim5 of the episodes and the forks are not immediatelyresolved that is having two or more run lengths inabout 3 of the cases

EOS fork episodes run as long as 12 blocks that is theentire block schedule of a single BP (block producer) [26] asBPs can override the entire block-producing schedule of thepreceding BP

Putting Bitcoin which produces few fork episodes asideEthereum and EOS exhibit very different fork episodepatterns Figure 8 shows two example fork episodes ofEthereum and EOS We have used the commit graphdrawing tool [35] to visualize the fork episodes Figure 8(a)depicts four fork episodes that is [174 176) [177 178)[183 184) and [185 186) of Ethereum and Figure 8(b)shows two EOS fork episodes that is [290 292) and[294 302)e first fork episode [174 176) of Ethereumexhibits the run length of 3 the weight of 4 and the degree of4 with three nonreported (ie thus available only from ourmeasurement) stale blocks e second fork episode[294 302) of EOS exhibits the run length of 9 the weightof 9 and the degree of 2

412 Nonearliest Advertised Block Endorsement of EthereumMiners Our most interesting finding is that Ethereumminers often do not add blocks to the earliest advertisedblock during fork episodes Consider an illustrative forkepisode depicted in Figure 6(b) e episode begins as thethree blocks (ie b1 b2 and b3) are added to the fork ini-tiating block b0 e immediately following blocks (ie bi

and bj) will have their previous blockhash identifying one ofthe three previous blocks of the minerrsquos choice e block bimined by some miner may be added to the earliest block(ie b1) the other block bj is mined by a different miner whochooses a different block (ie b2) to add to To evaluateminersrsquo preference of blocks to which succeeding blocks areadded in the event of blockchain forks we define theconditional probability of miner ma adding a block to aprevious block mined by mb (by not adding to any of adifferent minerrsquos block) in fork episodes for all ma and mb

Pr miner bi( 1113857( mb|miner bj1113872 1113873

ma

prev bj1113872 1113873 bi

existbk height bk( 1113857 height bi( 1113857)

(1)

Figure 9(a) shows a histogram of the above probabilityma (x-axis) adds a block to mbrsquos block (label) over others infork episodes It is apparent that the top ranked minerssignificantly prefer adding blocks to their own mined blocksover other minersrsquo blocks Figure 9(b) depicts the same

6 Security and Communication Networks

bf

br

m

m + 1

n

n + 1

Height

(a)

Time

Arrival (b1)

Arrival (b2)

Arrival (b3)

b0

b1

b2

b3

bi

bj

(b)

Figure 6 Fork analysis model (a) Fork episode (b) Fork resolve example

EthereumEOS

0

02

04

06

08

1

Cum

ulat

ive f

requ

ency

2 4 6 8 10 120 14

Run length

EthereumEOS

0

02

04

06

08

1

Cum

ulat

ive f

requ

ency

2 4 6 8 10 12 140

Weight

EthereumEOS

0

02

04

06

08

1

Cum

ulat

ive f

requ

ency

40 62

Degree

Figure 7 Fork episode characteristics

∆ (ts0 ts1)∆ (ts0 ts3)∆ (ts0 ts7)

0010203040506070809

1Cu

mul

ativ

e fre

quen

cy(

of t

rans

actio

ns)

2 4 6 8 100Time difference (seconds)

(a)

BitcoinEthereumEOS

1 2 3 4 50Time difference (seconds)

0

02

04

06

08

1

Cum

ulat

ive f

requ

ency

( o

f tra

nsac

tions

)

(b)

Figure 5 Transaction arrival time accuracy (a) Transaction arrival time differences of Bitcoin (b) Δ(ts0 ts1) distribution

Security and Communication Networks 7

(a) (b)

Figure 8 Example fork episodes each dot represents a block followed by block hash (last six hexadecimals) arrival time block height (lastthree digits) block timestamp and its miner Each Ethereum stale block is tagged either R (reported uncle) or NR (not reported) Each EOSblock is tagged with the block sequence (out of 12) of the corresponding BPrsquos production schedule (a) Ethereum (b) EOS

SparkPoolEthermine

F2PoolNanopool

MiningPoolHubzhizhutop

Unconditional SparkPool Ethermine F2Pool Nanopool MiningPoolhub

zhizhutop

0

01

02

03

04

05

Freq

uenc

y

(a)

EarliestMixedNonearliest

Spar

kPoo

lEt

herm

ine

F2Po

olN

anop

ool

Min

ingP

oolH

ubzh

izhu

top

UU

Pool

Pand

aMin

erBT

POO

Lxn

pool

Huo

biM

inin

gPoo

lD

war

fPoo

lfir

epoo

lU

nkno

wn

Min

ing

Expr

ess

BTC

com

Pool

Min

eral

lPoo

lBe

ePoo

lH

iveo

nPoo

l2M

iner

sPPL

NS

2Min

ersS

OLO

Coin

otro

nW

POO

LEz

ilPoo

lpo

olin

o

f tot

al fo

rk re

solv

e

(b)

Figure 9 Ethereum fork resolve statistics (a) Probability of ma (x-axis) adding a block to mbrsquos block (b) Probability of adding to the earliestpropagated block

8 Security and Communication Networks

probability by labeling whether or not the chosen block (byma) is the earliest propagated one e ldquoearliestrdquo label in-dicates that the block to which the newly mined block (byma) is added has been observed as the earliest one to arrivecongruently among all eight measurement locations (Asblock arrival times are measured in eight different locationsthe arrival order can be conflicting e ldquomixedrdquo labelrepresents the conflicting cases) For example the topranked pool SparkPool chose the earliest arriving blocksim55 of the time 3409 out of 6234 blocks among the other2825 blocks that were added to nonearliest previous blocksSparkPoolrsquos own blocks were chosen over others 1211 timeswhile other poolsrsquo blocks were preferred to SparkPoolrsquos only24 times In the meantime Nanopool chose the earliest one amajority of the time For the top 25 ranked mining pools onlyfour of them added blocks to the earliest arriving blocks morethan 90 of the timeis contradicts the earliest propagatedblock endorsement assumption that is broadly adopted inmining-related research [36ndash38]

One possible explanation of the phenomenon is that themining pools adopt their own block preferring strategy as asimple precautionary defense against yet unknown selfishmining pools the profitability of selfish mining largelydepends on the probability of honest pools adding to theattacking poolrsquos branch

413 Cut-Tail Fork Pattern of EOS BPs We find that theEOS fork episodes occur in a way that BPs are cutting the tailof the previous BPrsquos produced blocks EOS adopts the DPoSconsensus mechanism [26] 21 block producers (BPs) areelected by voting and scheduled to produce 12 consecutiveblocks in 6 seconds (ie 500ms for each block) in the al-phabetical order of their names Figure 10 shows thenumbers of switching (by schedule) events and cut-tail forkevents of all immediate BP pairs We observe a high fre-quency of such events when bitfinexeos1 is producing blocksby appending to big onersquos blocks while there are accusationsof BPrsquos dishonest behaviors we believe that the reportedbitfinexrsquos performance problem is the compelling reason forthe phenomenon [39]

42 Unseen and Stale Transactions

421 Private Transaction Mining Unseen transactions arecharacterized by the strong evidence that implies that theunseen transactions are indeed never advertised to the net-work Table 6 categorizes 9587 of Ethereum unseentransactions by using the from addresses of the transactions(We use prefixes followed by ⋆ in presenting hash valueseg address (ie pubkey hash) and txid for brevity Weunderstand this does not entirely anonymize identity as thereaders can verify their results against ours by matching theprefixes) Public names are retrieved from Etherscan [16] Aminer is specified in the table only if all blocks that includethe unseen transactions with the from address are con-gruently mined by that single miner It shows that most ofthe unseen transactions are indeed the block minerrsquos owntransactions

Table 7 shows unseen Bitcoin transactions categorized bythe identified reasons sim 67 of the unseen transactions areeither zero-fee transactions or zero-fee-transaction-dependenttransactionsWe define a transaction t isin transactions(b) as adependent transaction if at least one of input transactions oft is included in the same block b

Bitcoin Core [28] implementation does not propagatetransactions with zero transaction fee Also a dependenttransaction cannot be mempooled until the transaction towhich it is dependent is mempooled consequently it cannotbe relayed to peers e Bitcoin Core mempool imple-mentation justifies the inexistence of zero-fee and zero-fee-dependent transactions from our measurement Existence ofa stale transaction which shares the same transaction inputwith the unseen transaction may imply a possible double-spend attempt a variant [40] involving private mining of ablock with ti while advertising a conflict transaction tj suchthat inputs(ti)cap inputs(tj)neempty we have observed 27 suchunseen transactions without a certainty of attack intentionsor if they are not indeed advertised Lastly multisig trans-action inputs often imply off-chain protocols where signedtransactions are exchanged out-of-band [41] and havingOP_RETURN transaction output implies special purposeprotocols of Bitcoin for example sidechains where theirrelationship with miners require further investigation [42]e presence of unseen transactions by either privatetransaction mining or potential out-of-band delivery oftransactions has a subtle security implication One obviousside effect is privatization of transaction fees the transactionfees of privately mined ones are exclusively obtainable by theprivate miner alone unless the network is fully utilized Ifthe network is fully utilized a miner is forced to include herprivate transactions at the expense of not including othertransactions as the block capacity is limited

422 Conflict Stale Transactions Stale transactions arenetwork-transmitted transactions that are not included inany of the blocks

Table 8 shows the stale transaction counts observed ateach location e stale transactions account for 020369 and 047 of Bitcoin Ethereum and EOS transac-tions respectively Ethereum transactions had an order ofmagnitude more chance of being stale than others

As for public blockchains with transaction fees that isBitcoin and Ethereum stale transactions are mostly at-tributable to conflict Table 9 summarizes the identifiedreasons for transactions being stale A stale Bitcoin trans-action is attributable to conflict if there are one or moretransactions sharing at least one transaction input (ie vin)

An Ethereum transaction is attributable to conflict ifthere is another transaction with the same nonce from thesame account A widely known reason for two or moretransactions being in conflict is transaction replacementsuch as replace-by-fee [43] On the other hand slightly morethan 5 of Bitcoin transactions are stale because at least oneof their transaction inputs is also stale

On the other hand roughly one out of ten staleEthereum transactions is attributable to improper ordering

Security and Communication Networks 9

of nonce (e transaction nonce should be equal to thenumber of transactions sent from the address) nonce is toohigh (983) or too low (002) Last but not least 727 ofstale transactions are not included in blocks because theaccount is not sufficiently funded (An Ethereum accountshould have balance ge value+ gastimes gas price to execute thetransaction [44]) An Ethereum account can be

insufficiently funded when executing a transaction for anumber of reasons [45]

423 EOS Transaction Discrepancy EOS exhibits unseenand stale transactions far different from those of Bitcoin orEthereum that is the PoW blockchains with transaction feeEOS software is not bundled with peer discovery rather thenode operator is required to look up for candidate BPrsquospeering services timely delivery of blockchain data andreliability of the node is dependent on the peering nodes ofchoice (Indeed we have experienced service disruption bydisconnecting from peers for unknown reasons)e notionof being conflict in two or more transactions that is themost frequent reason for transactions being stale for Bitcoinand Ethereum is not applicable to EOS (EOS adopts theaccount model without transaction ordering per accountthus there should be no conflict transaction outputs or thesame account nonce) On the other hand EOS requires

eosh

uobi

pool

-eos

infst

ones

eosfl

ytom

ars-

eosh

uobi

pool

zbeo

sbp1

1111

-atti

clab

eosb

attic

labe

osb-

big

one

hoo

com

-new

dex

bpw

hale

exco

m-z

beos

bp11

111

start

eosio

bp-w

hale

exco

meo

sdot

wik

ibp-

eosfl

ytom

ars

eosc

anno

nchn

-eos

dotw

ikib

pbi

gon

e-bi

tfine

xeos

1eo

sinfst

ones

-eos

iom

eeto

nehe

lloeo

scnb

p-ho

oco

meo

slaom

aoco

m-e

ossv

12eo

ssv

slow

mist

iobp

-sta

rteo

siobp

eoss

v12e

ossv

-hel

loeo

scnb

peo

sbei

jingb

p-eo

scan

nonc

hneo

siosg

1111

1-eo

slaom

aoco

meo

siom

eeto

ne-e

osio

sg11

111

bitfi

nexe

os1-

cert

ikeo

sorg

new

dex

bp-s

low

mist

iobp

coch

ainw

orld

-eos

asia

1111

1bi

tfine

xeos

1-co

chai

nwor

ldce

rtik

eoso

rg-c

ocha

inw

orld

eosa

sia11

111-

eosb

eijin

gbp

new

dex

bp-o

kcap

italb

p1eo

siom

eeto

ne-e

osla

omao

com

okca

pita

lbp1

-slo

wm

istio

bpco

chai

nwor

ld-e

osbe

ijing

bpne

wde

xbp

-sta

rteo

siobp

eosa

sia11

111-

eosc

anno

nchn

eosla

omao

com

-hel

loeo

scnb

pco

chai

nwor

ld-e

osca

nnon

chn

cert

ikeo

sorg

-eos

beiji

ngbp

eoss

v12e

ossv

-hoo

com

bitfi

nexe

os1-

eosa

sia11

111

eosin

fston

es-e

osla

omao

com

okca

pita

lbp1

-sta

rteo

siobp

BP switching (left)Cut-tail (right)

0

5000

10000

15000

20000

25000

BP sw

itchi

ng ev

ents

0

100

200

300

400

500

cu

t-tai

l eve

nts

Figure 10 EOS BP switching and cut-tail events

Table 6 Ethereum unseen transactions

From address Public name Transaction count Miner0xea67⋆ Ethermine 128145 (7242) Ethermine0x2a65⋆ DwarfPool 22955 (1297) DwarfPool0x8fd0⋆ Unknown 11346 (641) SparkPool0x829b⋆ F2Pool 4453 (251) F2Pool0x4c54⋆ HiveonPool 1135 (064) SparkPool0x99c8⋆ BeePool 468 (026) BeePool0xdba7⋆ Unknown 348 (020) UUPool0x464b⋆ FKPool 340 (019) FKPool0xf687⋆ Unknown 217 (012) AntPool0xa801⋆ Unknown 151 (009) AntPool0xbe7c⋆ Unknown 126 (007) AntPool0xb96f⋆ Unknown 101 (006) AntPool

Sum 169785 (9587)

Table 7 Bitcoin unseen transactions

Category Transactioncount

Zero-fee transaction 148 (5068)Zero-fee-transaction-dependent transaction 48 (1644)Multisig transaction input 43 (1473)Conflict with stale transaction 27 (925)OP_RETURN transaction output 26 (890)Sum 292 (10000)

10 Security and Communication Networks

contract users to stake tokens for CPU time that can bededucted by transaction executions A requested transactioncan be rejected thus being stale due to the lack of CPU timeor other resources similarly Replaying the entire statechanges of EOS to find out stale transactions due to lack ofresources is not possible unless all transaction and state logsof the entire BPs are available

On the other hand EOS transactions have two additionalattributes which are not available in the Bitcoin or Ethereumtransaction structures

(i) Reference block every EOS transaction refers to ablock by specifying the block number and hash notonly to prevent replay attacks but also to signal thenetwork that the userrsquos stake is on a specific fork

(ii) Expiration time EOS transactions have explicitexpiration times

If a transactionrsquos reference block is not part of the mainchain at the time of execution the transaction cannot beexecuted (and thus cannot be included in a block) We haveidentified that 18 of stale transactions apply to this case Tofurther identify unknown reasons we consider four timedevents that are relevant to transaction execution

(i) Last irreversible block arrival time arrival(blib) thearrival time of transactionrsquos reference block EOStransactions by default refer to the last irreversibleblock (LIB) [26]

(ii) Head block arrival time arrival(bhead) the scheduledtime of the head block when transaction is arrived

(iii) Transaction arrival time arrival(t) the arrival timeof transaction t

(iv) Expiration time exp(t) the expiration time oftransaction t

e three time differences that is Δexp Δincl and Δtrxare investigated to find characteristics of unseen (Tunseen)and stale (Tstale) transactions over the normal transactions(Tincluded) Figure 11 illustrates the relevant events and timedifferences of them Δexp measures the time difference be-tween the two scheduled (ie virtually timed) events Δincland Δtrx are defined by the arrival events to our monitornode Figure 12 shows the distributions of Δexp Δincl andΔtrx We find that unseen transactions have prolonged Δinclimplying that the delay of newly produced blocks can causenewly generated transactions not promptly delivered be-cause the sync manager is in the Head Catch-Up mode astransactions are only transferred in In-Sync mode by itsdesign [24] Stale transactions with relatively small Δtrx canbe attributable to problematic dApp implementations re-ferring to non-LIB blocks the chain instability caused byblockchain fork mostly due to the cut-tail behavior shown inSection 41 can cause transactions being rejected for im-mature block reference

However we do not find any reason attributable to thetransaction expiration Although the unseen transactionstend to have smallΔexp the expiration times are only as smallas 30 seconds (ie the default expiration time) Particularlyone or more EOS applications set the expiration time to180 seconds (other than the default 30 seconds) and morethan half of the stale transactions are invoked by thoseapplications

While transaction is the smallest unit of execution inBitcoin and Ethereum the unit of contract execution in EOSis action [24] A transaction consists of one or more actionsHowever the constituent actions in a single transactioncannot be separately advertised or executed accordingly weapply the identical transaction model to EOS without loss ofgenerality

5 Block and TransactionArrival Characteristics

51 Arrival Processes All three blockchains we study in thispaper are designed to publish capacity constrained blocks intargeted regular time intervals An incarnation of suchdesign is expected to exhibit a Poisson block arrival processWhile it is claimed that Bitcoin block arrivals do not entirelyexhibit a homogeneous Poisson process due to its difficultadjustment mechanism [46] transaction arrival processes ofblockchains are not studied in the literature to the best of ourknowledge A particularly meaningful step toward under-standing the arrival process of events generated by a complexsystem is examining if the arrival events are independent orexhibiting a correlated structure [47]

e variance-time log-log plots [48] of the block andtransaction arrival event time series are depicted in

Table 8 Stale transactions

Region Bitcoin Ethereum EOSAsia-East 41720 1170706 mdashAsia-South 41653 1194018 504277Europe-North 41693 1192435 470480Europe-West 41668 1123680 450140North America-Northeast 41703 1212210 588711US-Central 41683 1212389 505160US-East 41692 1186488 mdashUS-West 41672 1167627 480207Combined 42023 1351847 672999

Table 9 Identified reasons of stale transactions

Category Transaction count(a) Bitcoin

Conflict 39408 (9378)Stale transaction input 2307 (549)Conflict and stale transaction input 308 (073)Sum 42023 (10000)

(b) EthereumConflict 1208588 (8924)Nonce (skipped) 133161 (983)Nonce (used) 251 (002)Insufficient fund 9847 (727)Sum 1351847 (9982)

(c) EOSFork 12106 (180)Others 660893 (9820)Sum 672999 (10000)

Security and Communication Networks 11

Figure 13(a) As regards the block arrival processes Bitcoinblock arrivals exhibit a linear slope β minus23 e estimatedHurst parameter H 1 + β2 43 implies that the processis not a homogeneous Poisson process but LRD (Long-Range Dependent) contrary to what is expected for a regularinterval event generation [46] Ethereum block arrivalsapproximate the Bitcoinrsquos except for the high aggregationlevel due to high stale block rate EOS block arrivals incontrast follow the slope β minus1 in the low aggregation levelas the block generation is indeed regularly scheduled

Figure 14 shows the variance-time plot of Ethereum andEOS block arrival time series by taking all block arrivalevents (Bobs) and main chain block arrivals only (Bmain) Weconfirm that Ethereum block arrivals indeed exhibit astraight line (close to Bitcoin) if excluding stale blocksHowever EOS block arrivals do not exhibit a straight line

even if we exclude stale blocks due to delayed burst blockarrivals possibly due to cut-tail fork patterns (see Section41)

e transaction arrival processes of all three blockchainsappear to exhibit LRD with Hurst parameter Hgt 56 asβltminus13 To further identify analytical distributions that fitbest the empirical ones the coefficient of variation (σμ) andskewness (ie the standardized third moment) of transac-tion interarrival times are computed for every measurementdataset and compared to the relationships expected for theexponential lognormal Weibull and Gamma distributionsin Figure 13(b) We find that Bitcoin Ethereum and EOStransaction interarrival times are fit best Gamma Weibulland lognormal distribution respectively Individual datasetsare also examined for the fitness of the distribution to findthat the empirical distribution fits the analytical distribution

Virtualclock

Time

Transaction initiator

Time

Blockproducer

Time

Monitornode

Time

Scheduled block time of blib

Scheduled block time of bhead

Scheduled block time of bincl

1 Produce and propagate blib

2 Produce and propagate bhead

Expiration time of t

4 Produce and propagate bincl

Δexp

Δtrx

Δincl

3 Create and propagate t

Figure 11 EOS transaction analysis model

Tincluded

Tstale

Tunseen

0010203040506070809

1

Cum

ulat

ive f

requ

ency

100 200 300 400 5000Time difference (seconds)

(a)

Tincluded

Tunseen

01 1 10 100 1000001Time difference (seconds)

0010203040506070809

1

Cum

ulat

ive f

requ

ency

(b)

Tincluded

Tstale

0010203040506070809

1

Cum

ulat

ive f

requ

ency

01 1 10 100 1000001Time difference (seconds)

(c)

Figure 12 EOS transaction timing analysis (a) Δexp (b) Δincl (c) Δtrx

12 Security and Communication Networks

well except for the small interarrival time ranges For ex-ample Figure 15 depicts the CDF of Ethereum transactioninterarrival times observed in US-West Although the em-pirical distribution fits Weibull with parameters computedwith the maximum likelihood estimator [49] sample pointsunder several milliseconds appear to be unreliable (We areyet unaware of the reason However it is known that thetime source of commodity operating systems is not accurateand we need an external time source for accurate sub-millisecond timing measurement [50])

52AdvertisementRedundancy Bitcoin and Ethereum nodepieces of software are implemented to maintain a large

number of peer connections with multiple random remotenodes Bitcoin Core can connect up to 125 peers where 8 ofthem are outbound connections Go Ethereum maintains 50peer connections where 16 of them are outbound by default(see Table 1) On the other hand partitioning attacks aredeveloped to isolate a blockchain node from the others bytampering with all such peer connections Partitioning at-tacks usually exploit vulnerable peer management mecha-nisms of Bitcoin [51] and Ethereum [52] Such attacks arealso examined in the context of ISPrsquos BGP hijacking [53] anda stealthier variant relieving the attacker from the risk ofgetting exposed [54] e attacks often rely on imple-mentation vulnerabilities for efficient eclipsing of peerswhile known vulnerabilities are getting addressed for ex-ample the lack of parallel block download sessions causing

Slope = ndash1

Trx BitcoinTrx EthereumTrx EOS

Blk BitcoinBlk EthereumBlk EOS

ndash12

ndash10

ndash8

ndash6

ndash4

ndash2

0Lo

g no

rmal

ized

var

ianc

e

124 6 10 140 2 8Aggregation level

(a)

Lognormal

Weibull

Gamma

Exponential

BitcoinEthereumEOS

0

5

10

15

20

Stan

dard

ized

third

mom

ent

1 2 3 40Coefficient of variation

(b)

Figure 13 Transaction arrival characteristics (a) Variance-time plot of block and transaction arrivals (b) Cov versus skewness oftransaction interarrival times

Ethereum - Bobs

Ethereum - Bmain

EOS - Bobs

EOS - Bmain

ndash12

ndash10

ndash8

ndash6

ndash4

ndash2

0

Log

norm

aliz

ed v

aria

nce

2 4 6 8 10 12 140Aggregation level

Figure 14 Variance-time plot of block arrivals including staleblocks (Bobs) and excluding stale blocks (Bmain)

EmpiricalExponential μ = 0024

Lognormal μ = 00354 σ2 = 00486Pareto k = 0000212 a = 0231Weibull c = 0589 a = 00147

00001 0001 001 01 1000001Time (seconds)

0

02

04

06

08

1

Cum

ulat

ive f

requ

ency

Figure 15 Empirical and fitted analytical distributions of Ether-eum transaction interarrival times

Security and Communication Networks 13

temporary denial of blocks (reported in [27] and fixed byrecommending three concurrent download sessions in [55])let attackers successfully partition the node without eclipsingall peer connections [53] A simple countermeasure of in-creasing the number of peer connections on the other handis applied to the reference public blockchain implementa-tions [56 57] to inflate attack complexity

We investigate the degree of a peerrsquos advertisementredundancy on newly generated blocks and transactions toevaluate the efficacy of partitioning attacks and the coun-termeasure of increasing the number of peer connectionsFigure 16 shows how redundantly newly generated blockinformation is offered by peers Bitcoin nodes have main-tained sim43 peer connections that is 8 outbound and ad-ditional 35 inbound connections on average and Ethereumnodes record all 50 peer connections established during theentire observation period

For each newly generated block one-third of peersadvertised the block header to our Bitcoin node and morethan 90 of Ethereum peers signaled availability of theblocks In consequence successfully partitioning a noderequires compromise of peers proportional to the totalnumber of peer connections Increasing the number of peerconnections will burden the attacker linearly as expected

Figure 17 shows how redundantly the newly generatedtransaction information is offered by peers While one out ofthree Bitcoin peers also advertises new transactions viaINVENTORYmessage [58] half of the Ethereum peers havesent new transactions to our node in average Bitcoin andEthereum blocks are advertised with the block header(rather than the direct delivery of all block contents) Bitcointransactions are also advertised with INVENTORY messagebefore the whole contents are transferred HoweverEthereum transaction data that is the entire contents aredirectly sent by peers (Ethereum now has a pooled trans-action delivery model in its newer ETH64 protocol [30])We also find that there are cases with much less advertisedtransactions and have identified that they are indeed mostlystale ones stale transactions are mostly due to conflict (seeSection 42) and the nodes that already queued the conflicttransaction will not relay the stale one

6 Discussion

61 Implication on Mining Attacks Cryptocurrency mininghas been a popular subject in assessing the security ofBitcoin selfish mining [37] block withholding attack [36]and a mixed strategy [38] have been studied Although it isshown that selfish behavior in mining is always moreprofitable than being honest without need for a mutualagreement of not attacking each other [38] we find thatselfish mining is not the preferred strategy All selfish miningstrategies will result in blockchain forks but we observe avery low fork probability (ie 004) for Bitcoin On theother hand selfish mining on Ethereum has been studiedonly recently to unanimously claim that selfish mining isalso profitable for Ethereum miners however it is lessprofitable than Bitcoin due to its uncle reward system [59]Our result in Section 4 shows that a majority of Ethereum

miners choose to add to their own produced blocks over theearliest propagated blocks How does this affect the selfishmining strategy

e selfish mining strategy assumes a parameter c whichdefines the fraction of honest minersrsquo mines on the attackerrsquosfork branch (e parameter comes into play in case (f ) of[27]) If the attacking pool has a network-wise superiorposition in block propagation (ie cgt 05) the selfishmining strategy is profitable for pools with proportionalmining power αgt 25 [37] Absolute network inferiority(ie c 0 due to a defensive mining strategy such as the onepresented in Section 41) increases the required miningpower to 33 the 33 mining power appears to be sig-nificantly harder to achieve in the real world [20]

As for the FAW (Fork-After-Withholding) attackstrategy [38] the network capability parameter C defines theprobability that an attackerrsquos FPoW (Full Proof-of-Work)block (during infiltration mining) is selected as a main chainblock C affects both the attack reward and whether theminerrsquos dilemma holds or not in the mutual attacking gameAs an example case (Section 9 of [38]) of a two-pool gamebetween F2Pool and BitFury the absolute network inferi-ority drops C from 0914 to 03 to make it a dilemmatic gameagain Unfortunately minersrsquo own block preferences cannotbe directly transferred to a single parameter of c or C it callsfor a model change from previous mining studies

62 Conflict Transactions and Double-Spending AttacksDouble-spending attacks have been studied in the context ofBitcoin fast payments where zero or only one confirmation isrequired to complete an offline merchandise transaction[60] real-world cases where two conflict transactions dis-parately arrive at different measurement locations mayimply such attacks Table 10 shows the cases where twotransactions are in conflict (and thus only one of themis included in a block ie inputs(ti)cap inputs(ts)neemptyand existb isin Bmain ti isin transactions(b) (∄b isin Bmain ts isintransactions(b) is indisputable given a consistent transactionledger)) and two different subsets of the monitors havemempooled either one of them We also have identified 27unseen transactions implying possible one-confirmationattack variant requiring the private mining (ie not ad-vertising the double-spending transaction to the network) in

5 10 15 20 25 30 35 40 45 500 of peers

0

005

01

015

02

025

Freq

uenc

y

BitcoinEthereum

Figure 16 Peer redundancy of block advertisement

14 Security and Communication Networks

Section 42 As for the countermeasure of such attacks bydeploying monitors [60] deployment of 8 monitors in thenetwork to detect the attacks would fail at most 27 out of 95times (sim30) assuming that those 27 unseen transactionswe have identified are initially advertised to the network

63 Potential Impact on Blockchain ApplicationsEthereum and EOS are the most widely used smart contractplatforms fostering various decentralized applications Bit-coin which lacks the capability of executing complex smartcontract codes is also recently utilized to execute smartcontracts for decentralized applications [50 61] Eventhough our work focuses on the fundamental blockchainmechanisms in terms of transactionblock production andpropagation the impact of our findings on decentralizedapplications can be foresighted

According to our blockchain fork results (Section 41)the lack of selfish mining in the real world was speculated bya very low stale block rate of Bitcoin network and prevalenceof nonearliest block endorsement by Ethereum miners Asprofitability of selfish mining encourages miners to behavein a way of producing more blockchain forks the perfor-mance degradation is proportionate to the number of minerswho adopt the selfish mining strategy the key performancemetrics affecting the blockchain application performance

such as node response time or block delivery time are shownto be noticeably degraded due to the selfish mining [62] Forexample decentralized identities issued or revoked on suchblockchains [63 64] cannot be responsively finalized due toinflated blockchain forks Our results show that the selfishmining is not prevalent in the real world thus the appli-cation performance impact is overrated even though it istheoretically shown that miners have every reason to beselfish [38] As for EOS we reported cases where a sequenceof (up to 12) blocks being stale are often observed in suc-cessive mining of two BPs however the rate is too low (ie004) to impact the performance of applications (Section32)

Transaction arrival processes being LRD (Section 51)pose a technical challenge in provisioning transactionprocessing scalability especially for Layer-2 blockchain ap-plication solutions [65 66] For example Layer-2 rollupsolutions require transaction relays which aggregate indi-vidual user transactions of a given blockchain applicationdeployed in the network often without a priori knowledge ofnetwork load One way of solving the problem is a properprioritization of transactions based on the applicationcontext

Lastly blockchain network partitioning can be thebiggest concern for blockchain service providers We ob-served that the increased numbers of peer connections inblockchain reference implementations effectively provide ahigher degree of information redundancy (Section 52)However increased number of peer connections can beexploitable for an attacker who has a denial-of-service attackvector or an invalid transaction initiated by a simple ap-plication bug can flood the network [45]

64 Limitation Our measurement study has several limi-tations First of all our results may only capture only a fewmonths of blockchain network operations In the meantimethe permissionless blockchain pieces of software are in activedevelopment for example Ethereum now utilizes the pooledtransaction delivery [67] instead of unsolicited transactiondelivery which was the only mode at the time of our

Table 10 Bitcoin disparately mempooled transactions

monitors mempooledti

monitors mempooledts

Transactioncount

7 1 26 (3824)6 2 14 (2059)5 3 10 (1471)4 4 5 (735)3 5 5 (735)2 6 3 (441)1 7 3 (441)5 1 1 (147)6 1 1 (147)

Sum 68 (10000)

Tincluded

Tstale

5 10 15 20 25 30 35 40 45 500 of peers

0

005

01

015

02

025

03Fr

eque

ncy

(a)

Tincluded

Tstale

0002004006008

01012014016

Freq

uenc

y

4030 500 10 20 of peers

(b)

Figure 17 Peer redundancy of transaction advertisement (a) Bitcoin (b) Ethereum

Security and Communication Networks 15

measurement Both cryptocurrency market values andblockchain network utilizations are rapidly increasing andthus miners are getting more motivated to optimize theirperformance for example Bitcoin fork probability has be-come far smaller than what is reported previously (seeSection 41)

Second the blockchain state information is not collected inour measurement Our analysis is performed based on onlyavailable information stored in block and transaction logs Wehave utilized an Ethereum archive node [44] to query historicalstate information (eg account balance or account nonce) inSection 42 However such proactive state replication is farmore complicated with EOS unless the full node is configuredto operate as a producing node and logging the state infor-mation thus EOS stale transactions could not be fully un-derstood without the missing EOS network state information

7 Related Work

71 Blockchain Data Analysis Historical transaction data ofBitcoin have often been studied for economic aspects such ascryptocurrency abuse [17] anti-money-laundering [18] andmonetary flow of businesses [19] However historicalblockchain data usually available from block explorer ser-vices are not sufficient for our research purpose

72 Blockchain Measurement Researchers have performedblockchain measurement studies to assess the degree ofdecentralization [20] to investigate demographic informa-tion of network nodes [34 68] to study mining pool be-havior [22] and to evaluate security of PoW blockchains [21]against known attacks such as double-spending attack [60]and selfish mining [37] Our work expands the under-standing of previous security evaluations with the keyfindings acquired from our large-scale transaction and blockmeasurement

73 Blockchain Attacks Partitioning attacks usually exploitvulnerable peer management mechanisms of Bitcoin [51]and Ethereum [52] Such attacks are also examined in thecontext of ISPrsquos BGP hijacking [53] and a stealthier variantrelieving the attacker from the risk of getting exposed [54]Cryptocurrency mining has been a popular subject inassessing the security of Bitcoin selfish mining [37] blockwithholding attack [36] and a mixed strategy [38] have beenstudied Double-spending attacks have been studied in thecontext of Bitcoin fast payments [60]

74 Block Explorer Services We have surveyed the popularblock explorer services of Bitcoin [5 10 12] Ethereum[10 13 16] and EOS [11 14 15] to see the availability ofinformation beyond what is recorded in the main chainblock data we have utilized in our study namely

(i) Stale blockstransactions no Bitcoin and EOS blockexplorers provide stale block information (A relatedstudy [36] has utilized a Bitcoin block explorer service[68] to retrieve stale blocks However the service has

been terminated in March 2019) All Ethereum blockexplorers provide only reported stale blocks (ie uncleblocks [23]) (Ethereum provides incentives for unclestale blocks [44] so that miners include them in theirmined blocks for profit)No block explorers provide stale transaction infor-mation unless one is currently pooled

(ii) Blocktransaction arrival times all block explorersprovide block timestamps that are recorded in theblock headers not the actual times of arrival Ourblockchain fork and gap analysis require measuredblock arrival times at multiple locations All blockexplorers show transaction timestamps identical to theblock timestamp to which the transactions belong(Recent Bitcoin transactions have different timestampsthan the block timestamps in [4] while the timestampsare only at a granularity of one minute) [69 70]

8 Conclusion

We have measured transaction and block arrival events ofthe three permissionless blockchains We have devised anoble analysis model and analyzed completeness of ourblock and transaction logs Finally we have studied thediscrepancy in measured events and arrival characteristics toshare our key findings including a false universal assumptionof previous mining-related studies

Data Availability

e measurement data used to support the findings of thisstudy have not been made available because they containprivate information that can be used to identify individualblockchain nodes

Disclosure

is is an extended and revised version of a conference paperpresented in IEEE ICDCS 2021 [41]

Conflicts of Interest

e authors declare that they have no conflicts of interest

Acknowledgments

e authors would like to thank Seungwon Woo DaegeunYoon and Changhyun Lee for helping them with themeasurement instrumentation is work was supported byElectronics and Telecommunications Research Institute(ETRI) grant funded by the Korean Government (21ZR1300Research on Intelligent Cyber Security and Trust Infra)

References

[1] S Nakamoto ldquoBitcoin a peer-to-peer electronic cash systemrdquo2019

[2] V Buterin ldquoEthereum white paperrdquo 2013 httpsethereumorgenwhitepaper

[3] Monero ldquoMonerordquo 2020 httpswebgetmoneroorg

16 Security and Communication Networks

[4] bitcoincashorg httpswwwbitcoincashorg[5] Blockchaincom httpswwwblockchaincom[6] Ripple ldquoXRP e best digital asset for global paymentsrdquo

2020 httpsripplecomxrp[7] I Foundation ldquoIotardquo 2021 httpswwwiotaorg[8] ldquoEosiordquo 2020 httpseosio[9] S Orsquoneal ldquoEos proves yet again that decentralization is not its

priorityrdquo 2018 httpscointelegraphcomnewseos-proves-yet-again-that-decentralization-is-not-its-priority

[10] Blockchair httpsblockchaircom[11] Bloksio httpsbloksio[12] BTCcom ldquoBitcoin block explorerrdquo 2021 httpsbtccom[13] Ethereum block explorer httpsethbtccom[14] eosflareio Eos block explorer httpseosflareio[15] EOSPark ldquoEos block explorerrdquo 2021 httpseosparkcom[16] Etherscan Ethereum explorer httpsetherscanio[17] S Lee C Yoon and H Kang ldquoCybercriminal minds An

investigative study of cryptocurrency abuses in the dark webrdquoin Proceedings of the Network and Distributed System SecuritySymposium pp 1ndash15 Internet Society San Diego CA USAFebruary 2019

[18] MMoser R Bohme and D Breuker ldquoAn inquiry into moneylaundering tools in the bitcoin ecosystemrdquo in Proceedings ofthe 2013 APWG eCrime Researchers summit pp 1ndash14 IEEESan Francisco CA USA September 2013

[19] M Lischke and B Fabian ldquoAnalyzing the bitcoin network thefirst four yearsrdquo Future Internet vol 8 no 1 2016

[20] A E Gencer S Basu I Eyal R V Renesse and E G SirerldquoDecentralization in bitcoin and ethereum networksrdquo inProceedings of the International Conference On FinancialCryptography and Data Security pp 439ndash457 SpringerNieuwport Curaccedilao February 2018

[21] A Gervais G O Karame KWust V Glykantzis H Ritzdorfand S Capkun ldquoOn the security and performance of proof ofwork blockchainsrdquo in Proceedings Of the 2016 ACM SIGSACConference on Computer and Communications Securitypp 3ndash16 Vienna Austria October 2016

[22] C Wang X Chu and Q Yang ldquoMeasurement and analysis ofthe bitcoin networks a view from mining poolsrdquo 2019httpsarxivorgabs190207549

[23] G Wood ldquoEthereum A secure decentralised generalisedtransaction ledgerrdquo Ethereum Project Yellow Paper vol 1512014

[24] ldquoTransactions protocol eosio developer docsrdquo 2018 httpsdeveloperseosiowelcomev20protocoltransactions_protocol

[25] Y Sompolinsky and A Zohar ldquoSecure high-rate transactionprocessing in bitcoinrdquo in Proceedings of the InternationalConference On Financial Cryptography and Data Securitypp 507ndash527 Springer San Juan PR USA January 2015

[26] Blockone ldquoConsensus protocolrdquo 2018 httpsdeveloperseosiowelcomev20protocolconsensus_protocol

[27] A Gervais H Ritzdorf G O Karame and S CapkunldquoTampering with the delivery of blocks and transactions inbitcoinrdquo in Proceedings Of the 22nd ACM SIGSAC ConferenceOn Computer and Communications Security pp 692ndash705Denver CO USA October 2015

[28] ldquoGithub Bit coinrdquo 2020 httpsgithubcombitcoinbitcoin[29] G Ethereum ldquoGo ethereumrdquo 2020 httpsgithubcom

ethereumgo-ethereum[30] Google ldquoGoogle cloudrdquo 2021 httpscloudgooglecom[31] ldquoHow to replay from a snapshotrdquo 2018 httpsdeveloperseos

iomanualseoslatestnodeosreplayshow-to-replay-from-a-snapshot

[32] C Decker and R Wattenhofer ldquoInformation propagation inthe bitcoin networkrdquo in Proceedings of the IEEE P2P 2013Proceedings pp 1ndash10 IEEE Trento Italy September 2013

[33] ldquoEthereum uncle raterdquo 2020 httpsychartscomindicatorsethereum_uncle_rate

[34] J A Donet C P Sola and J H Joancomartı ldquoe bitcoin p2pnetworkrdquo in Proceedings of the International Conference OnFinancial Cryptography and Data Security pp 87ndash102Springer Christ Church Barbados March 2014

[35] G S Davies ldquoBit-booster - offline commit graph drawingtoolrdquo 2016 httpbit-boostercomgraphhtml

[36] N T Courtois and L Bahack ldquoOn subversive miner strategiesand block withholding attack in bitcoin digital currencyrdquo2014 httpsarxivorgabs14021718

[37] I Eyal and E G Sirer ldquoMajority is not enough bitcoin miningis vulnerablerdquo in Proceedings of the International Conferenceon Financial Cryptography and Data Security pp 436ndash454Springer Christ Church Barbados March 2014

[38] Y Kwon D Kim Y Son E Vasserman and Y Kim ldquoBeselfish and avoid dilemmas fork after withholding (faw) at-tacks on bitcoinrdquo in Proceedings Of the 2017 ACM SIGSACConference On Computer and Communications Securitypp 195ndash209 Abu Dhabi UAE April 2017

[39] B Research ldquoDecentralisation governance and eos - a lostcaserdquo 2020 httpsresearchbinancecomenanalysiseos-governance

[40] B Wiki ldquoIrreversible transactions - finney attackrdquo 2012httpsenbitcoinitwikiIrreversible_Transactions∖Finney_attack

[41] J Poon and T Dryja ldquoe bitcoin lightning network scalableoff-chain instant paymentsrdquo 2016

[42] M Bartoletti and L Pompianu ldquoAn analysis of bitcoin op_return metadatardquo in Proceedings of the International Con-ference On Financial Cryptography and Data Securitypp 218ndash230 Springer Sliema Malta April 2017

[43] ldquoReplace by feerdquo 2018 httpsenbitcoinitwikiReplace_by_fee

[44] E Foundation ldquoNode and clientsrdquo 2020 httpsethereumorgendevelopersdocsnodes-and-clients

[45] H Heo and S Shin ldquoBehind block explorers public block-chain measurement and security implicationrdquo in Proceedingsof the 41th IEEE International Conference On DistributedComputing Systems IEEE Washington DC USA In pressWashington DC USA July 2021

[46] R Bowden H P Keeler A E Krzesinski and P G TaylorldquoBlock arrivals in the bitcoin blockchainrdquo 2018 httpsarxivorgabs180107447

[47] M E Crovella and A Bestavros ldquoExplaining world wide webtraffic self-similarityrdquo Technical Report Citeseer PrincetonNJ USA 1995

[48] H Zhang Y Shu and O Yang ldquoEstimation of hurst pa-rameter by variance-time plotsrdquo in Proceedings of the 1997IEEE Pacific Rim Conference on Communications Computersand Signal Processing PACRIM 10 Years Networkingthe Pacific Rim 1987-1997 IEEE Victoria BC CanadaAugust 1997

[49] A Feldmann ldquoCharacteristics of TCP connection arrivalsrdquo inSelf-Similar Network Traffic and Performance EvaluationK Park andWWillinger Eds pp 367ndash399Wiley HobokenNJ USA 2000

[50] RSK ldquoRSKrdquo 2021 httpswwwrskco[51] E Heilman A Kendler A Zohar and S Goldberg ldquoEclipse

attacks on bitcoinrsquos peer-to-peer networkrdquo in Proceedings of

Security and Communication Networks 17

the 24th USENIX Security Symposium pp 129ndash144 Wash-ington DC USA April 2015

[52] Y Marcus E Heilman and S Goldberg ldquoLow-resourceeclipse attacks on ethereumrsquos peer-to-peer networkrdquo IACRCryptology vol 2018 p 236 2018

[53] M Apostolaki A Zohar and L Vanbever ldquoHijacking bitcoinRouting attacks on cryptocurrenciesrdquo in Proceedings of the2017 IEEE Symposium On Security and Privacy (SP)pp 375ndash392 IEEE San Jose CA USA May 2017

[54] M Tran I Choi G J Moon A V Vu and M S Kang ldquoAstealthier partitioning attack against bitcoin peer-to-peernetworkrdquo in Proceedings of the IEEE Symposium On Securityand Privacy (SampP) San Francisco CA USA May 2020

[55] B I Proposal ldquoBip 0152rdquo 2016 httpsenbitcoinitwikiBIP_0152

[56] B Core ldquoBitcoin Core Version 01901 Release Noterdquo 2016httpsbitcoinorgenreleasev01901

[57] ldquoGeth v190rdquo 2019 httpsblogethereumorg20190710geth-v1-9-0

[58] ldquoProtocol documentationrdquo 2016 httpsenbitcoinitwikiProtocoltext_documentation

[59] C Feng and J Niu ldquoSelfish mining in ethereumrdquo in Pro-ceedings of the 2019 IEEE 39th International Conference OnDistributed Computing Systems (ICDCS) pp 1306ndash1316IEEE Dallas TX USA July 2019

[60] G O Karame E Androulaki and S Capkun ldquoDouble-spending fast payments in bitcoinrdquo in Proceedings of the 2012ACM Conference on Computer and Communications Securitypp 906ndash917 Raleigh NC USA October 2012

[61] P Das L Eckey T Frassetto et al ldquoFastkitten practical smartcontracts on bitcoinrdquo in Proceedimgs of the 28th USENIXSecurity Symposium (USENIX Security 19) pp 801ndash818Santa Clara CA USA August 2019

[62] S G Motlagh J Misic and V B Misic ldquoe impact of selfishmining on bitcoin network performancerdquo IEEE Transactionson Network Science and Engineering vol 8 no 1 pp 724ndash7352021

[63] A Muhle A Gruner T Gayvoronskaya and C Meinel ldquoAsurvey on essential components of a self-sovereign identityrdquoComputer Science Review vol 30 pp 80ndash86 2018

[64] M Toorani and C Gehrmann ldquoA decentralized dynamic pkibased on blockchainrdquo in Proceedings Of the 36th Annual ACMSymposium On Applied Computing pp 1646ndash1655 GwangjuKorea March 2021

[65] E foundation ldquoOptimistic-rollupsrdquo 2021 httpsdocsethhubioethereum-roadmaplayer-2-scalingoptimistictext_rollups

[66] ldquoZk-rollupsrdquo 2021 httpsdocsethhubioethereum-roadmaplayer-2-scalingzk-rollups

[67] E foundation ldquoEthereumwire protocolrdquo 2019 httpsgithubcomethereumdevp2pblobmastercapseth

[68] S K Kim Z Ma S Murali J Mason A Miller andM BaileyldquoMeasuring ethereum network peersrdquo in Proceedings of theInternet Measurement Conference 2018 pp 91ndash104 BostonMA USA October 2018

[69] Symmetricom ldquoDelivering sub-microsecond accurate time tolinux applications around the worldrdquo 2012 httpwwwchronoscoukfilespdfswpsWP_AccurateTimeForLinuxApplicationspdf

[70] Ycharts ldquoBlocktrail blockchain data query service (termi-nated)rdquo 2019 httpsblocktrailcom

18 Security and Communication Networks

selfish mining is not the preferred strategy for Bitcoinminers On the other hand the majority of Ethereumminers add blocks to their own mined blocks ratherthan the earliest propagated ones that are mined byother pools this contradicts the unarguably adoptedassumption of previous studies (Section 41)RQ3 Do blockchain nodes effectively get away frompartitioning attacks by virtue of information re-dundancy from multiple peers (Are they stillvulnerable to partitioning attacks)

(iii) (Preview on our findings) Yes e referenceimplementations of PoW blockchains have in-creased the number of (outbound) peer connectionsand consequently the up-to-date nodes benefitfrom redundant block advertisement from 14 to 46peers for Bitcoin and Ethereum respectively (Sec-tion 52) tampering with a small number of peerswill not successfully partition or make a node un-synchronized for minutes [27]

23 AnalysisModel Although the three blockchains operatedifferently (as summarized in Table 1) in many ways theycan be commonly modeled with the following

(i) Blocks are produced by miners (or block producers)and are broadcast to the network by peer connec-tions A block b is uniquely identified with itsblockhash and refers to its parent block bp (ieprev(b) bp) e arrival time of b at a measure-ment point m (ie arrival(b)m) is the arrival time ofb from one of mrsquos peers who delivers b for the firsttime e block b can be included in the main chain(ie Bmain) or it can be stale (ie b notin Bmain)

(ii) Transactions are composed and propagated by usersthrough a P2P network A transaction t is uniquelyidentified with its txid e arrival time of transac-tion t at a node m (ie arrival(t)m) is the arrival timeof t from one of mrsquos peers who delivers t for the firsttime e transaction t can be included in block b

(ie t isin transactions(b)) or be stale (iet notin transactions(b)forallb isin Bmain)

e set of notations is summarized in Table 2 and thefunctions used in the definition are listed in Table 3

Our model comprises the two arrival events that isblock and transaction arrival events where a single block

arrival event is mapped to zero or more transaction events(ie ti isin transactions(b)) by the function transactions(middot)

(Bitcoin coinbase transactions are excluded in our analysis asthey are not advertised to the network)

Figure 2 depicts how we analyze our measurements Instudying the discrepancy in block and transaction events(Section 4) the arrival events near the measurement bound-aries significantly affect our quantitative analysis For exampleincluding or excluding a single Bitcoin block around themeasurement boundary can produce more than two thousandstale or unobserved transactions To this end we crop themeasurement to the observation period by carefully choosingtwo anchor blocks the preamble block bm and the concludingblock bn for each dataset of blockchains so that our mea-surement satisfies the two following conditions (i) ere is noloss of measurement data (due to the reasons described inSection 31) at any of our eight (Due to unreliable peeringservices of candidate BPs (block producers) of EOS we haverelaxed the conditions to six for EOS) locations in the timeperiod of one week before the arrival of bm and one week afterthe arrival of bn (ii) Both bm and bn belong to the main chain

3 Measurement

31 Data Collection We have modified the referenceimplementations of three popular pieces of blockchainsoftware Bitcoin Core [28] Go Ethereum [29] and EOSIO[8] to facilitate logging of all received transactions andblocks from peers Our monitoring pieces of software aredeployed to eight geographically dispersed regions of theGoogle cloud platform [30] Asia-East Asia-South Europe-North Europe-West North America-Northeast US-Cen-tral US-East and US-West Each VM is configured to havetwo vCPUs 185GB of memory and 800GB of standardpersistent disk Measurements were performed between July2019 and December 2019 by having our monitors which areindeed full nodes on the three blockchain mainnets con-nected to the peers As regards EOS the full node softwarethat is nodeos is neither bundled with default seed peers norfacilitated with a peer discovery mechanism We havemanually collected available peers and fed them Also asnodeos only accepts transaction and block advertisements inIn-Sync mode [24] a recent snapshot [31] is inputted toquickly catch up without throttling CPU and networkbandwidth by syncing from scratch that is the genesisblock Unfortunately we experienced several problems thatresulted in suspension of our monitoring processes For

Table 1 Blockchain summary

Blockchain Consensusmechanism

Blocktime

Transactions per second(all-time high)

Balancemodel

Transactionfee

Peer-to-peer management

Discovery Max peers (Outgoing)

Bitcoin PoW sim10minutes 7 UTXO Yes Random from

seeder list 125 (8)

Ethereum PoW sim10seconds 15 Account Yes Kademlia-like 50 (16)

EOS DPoS 05seconds 4000 Account No (staking) mdash mdash

Security and Communication Networks 3

example the Google cloud platform endeavors to detectcryptocurrency-mining-related activities Once detected theVM instance immediately gets suspended and is reinstatedonly if a reasonable explanation is provided

Furthermore we have noticed a few software crashesVM suspensions by other reasons or temporary lack of diskspace causing loss of measurement data Lastly a majority of

EOS candidate BPs who have provided the peering servicehave gradually stopped their services and only several are leftat the end of our measurement period To eradicate inac-curacy due to the above problems our measurement datasetis trimmed as described in Section 23 Table 4 summarizesour choice of the two anchor blocks and consequent ob-servation period statistics

Table 2 Transaction and block set notation of our measurement framework

Notation Description Definition

Bobse set of blocks observed in the observation

periodbi bi+1 bjminus2 bjminus11113966 1113967 where there is no bk satisfying

arrival(bm)le arrival(bk)le arrival(bi) or arrival(bjminus1)le arrival(bk)le arrival(bn)

Bmaine set of blocks that are included in the

main chainbm+1 bm+2 bnminus1 bn1113864 1113865 where bi prev(bi+1) for all mlt ilt n and bm and bn are

the preamble and concluding blocks respectivelyBstale e set of observed blocks that are stale Bobs minus Bmain

Bunseene set of blocks that are part of the main

chain but not observed Bmain minus Bobs

Tobse set of transactions observed in the

observation periodti ti+1 tjminus2 tjminus11113966 1113967 where there is no tk satisfying

arrival(bm)le arrival(tk)le arrival(ti) or arrival(tjminus1)le arrival(tk)le arrival(bn)

Tpree set of transactions observed before the

observation periodt0 t1 timinus2 timinus11113864 1113865 where there is no tk satisfying

arrival(timinus1)le arrival(tk)le arrival(bm)

Tposte set of transactions observed after the

observation period tj tj+1 1113966 1113967 where there is no tk satisfying arrival(bn)le arrival(tk)le arrival(tj)

Tstalee set of observed transactions that are

stale Tobs minus cupbisinBmain

transactions(b)

Tincludede set of transactions that are observed and

included in the main chain blocks Tobs cap cupbisinBmain

transactions(b)

Tunseene set of transactions that are included inthe main chain blocks but not observed cup

bisinBmain

transactions(b) minus Tpre cupTobs cupTpost

Table 3 Block and transaction functions

Function Descriptionblockhash(b) e hash value of block b

prevhash(b) e previous block hash value of block b

prev(b) e previous block bp of block p ie blockhash(bp) prevhash(b)

height(b) e block height of block b

miner(b) e miner of block b

children(b) e set of child blocks of block b ie height(bc) height(b) + 1forallbc isin children(b)

transactions(b) e set of transactions included in block b

arrival(e) e arrival time of event e where e can be either a block or a transactioninputs(t) e set of transaction inputs (ie vin) of Bitcoin transaction t

outputs(t) e set of transaction outputs (ie vout) of Bitcoin transaction t

nonce(t) e nonce value of Ethereum transaction t

bm bnbm+1

ti ti+1 ti+2 tj-1tj-2 tjtindash1

Time

Transactionarrivals

Blockarrivals

TobsTpre Tpost

bn+1

BobsBpre Bpost

Measurement period

Observation period

bmndash1

Figure 2 Transaction and block analysis model grey-colored events are cropped out for measurement point consistency

4 Security and Communication Networks

32 Measurement Soundness As public blockchain net-works are built on the best-effort serviced overlay network ofP2P connections complete and timed information deliveryis not guaranteed We analyze the completeness of blockarrival events transaction arrival events and their arrivaltime accuracy to underpin the soundness of ourmeasurement

321 Block Coverage Blocks can be part of the main chainor they can be staleWe test our observation against themainchain which is available from a number of block explorerservices to make sure there are no missing blocks

Table 5 shows the observed number of blocks across ourmeasurement points e main chain blocks are all observedwhile stale blocks are partially observed stale blocks beingpartially observed is expected as blockchain nodes are notobliged to propagate stale blocks e stale blocks accountfor only sim004 for Bitcoin and EOS while sim702 of theobserved blocks are stale for Ethereum e stale blockprobability of Bitcoin has been decreasing [21 32] andEthereumrsquos stale block probability is 5 sim 10 larger thanknown uncle rates (calculated only with reported uncles) asour measurement captures unreported stale blocks aswell [33]

322 Transaction Coverage Incomplete transaction mea-surement causes a subset of transactions which are includedin blocks never being observed during measurement Ag-gregating transactions observed from different monitors cancompensate for this incompletenesse unseen transactionsare acquired by subtracting the observed transactions fromthe transactions included in the main chain blocks

Figure 3 shows the probability of unseen transactions(ie n(T

1113954Munseen)n(Tobs)) as a function of the number of

combined measurement points As combining all mea-surement point transaction arrivals results in a convergedfrequency of sim005 for Bitcoin and EOS and sim05 forEthereum it implies that unseen transactions will be stillobserved even if more monitors are deployed to the networkWe further study the unseen transactions in Section 42

323 Timing Accuracy Consider an ordered arrival time-stamp of block b observed at all measurement pointsM tsi|0le ilt n(M)1113864 1113865 arrival(b)m|forallm isinM where tsi lttsj for all ilt jlt n(M) We evaluate the tightness of ourmeasured timing information with Δ(ts0 ts1) and how farthe arrival times can be dispersed among the measurementpoints with Δ(ts0 ts7) where Δ computes the timewisedifference Figure 4 depicts the distribution of the two

Table 4 Observation period statistics

BlockchainPreamble block Concluding block Population

Block height Timestamp Block height Timestamp blocks transactionsBitcoin 587500 2019-07-28 210228 597500 2019-10-02 062237 10004 21454436Ethereum 8290000 2019-08-05 100210 8620000 2019-09-25 192827 353155 36665088EOS 69900000 2019-07-21 210001 75300000 2019-08-22 040804 5402099 144198985

Table 5 Block coverage

RegionBTC ETH EOS

Longest Stale Longest Stale Irreversible StaleAS-East 10000 1 330000 23160 mdash mdashAS-South 10000 3 330000 23160 5400000 2087EU-North 10000 4 330000 23159 5400000 2094EU-West 10000 2 330000 23157 5400000 2087NA-Northeast 10000 3 330000 23160 5400000 2151

US-Central 10000 1 330000 23159 5400000 2085US-East 10000 3 330000 23160 mdash mdashUS-West 10000 4 330000 23155 5400000 2099

Bitcoin (left)Ethereum (right)EOS (left)

0

0002

0004

0006

0008

001

0012

0014

Freq

uenc

y (E

ther

eum

)

2 64 5 81 3 7 of combined measurement points

0

00001

00002

00003

00004

00005

00006

00007

Freq

uenc

y (B

itcoi

n or

EO

S)

Figure 3 Unseen transaction probability distribution

∆(ts0 ts1) Bitcoin

∆(ts0 ts1) Ethereum

∆(ts0 ts1) EOS

∆(ts0 ts7) Bitcoin

∆(ts0 ts7) Ethereum

∆(ts0 ts5) EOS

0

02

04

06

08

1

Cum

ula

tive

freq

uen

cy

1000001 1 10001 100001

Time difference (seconds)

Figure 4 Block arrival time accuracy

Security and Communication Networks 5

variables for all block arrival events It shows that thetimestamps are tight as more than 90 of the blocks arrivedwith a time difference less than 100ms Although Bitcoinblock arrivals can be delayed by another block time interval( sim 10 minutes) sim 80 of the blocks are not dispersed bymore than one second EOS blocks show an order-of-magnitude-smaller dispersion in the worst case e longtails implying that block arrival times can be very prolongedin a small number of cases are commonly observed forBitcoin in the literature [32 34]

Consider an ordered arrival timestamp of transaction t

observed at all measurement points M tsi|0le ilt n(M)1113864 1113865

arrival(t)m|forallm isinM where tsi lt tsj for all ilt jlt n(M)Figure 5 shows the distribution of Δ(ts0 ts1) Δ(ts0 ts3) andΔ(ts0 ts7) for Bitcoin transactions Similar to Bitcoin blocksthe long tail shows that the transaction arrival times can bedispersed more than 5 seconds for 5 of the transactions Inthe meantime Δ(ts0 ts1) is tight as more than 99 of thetwo earliest arrivals are not dispersed more than 1 secondEthereum and EOS transactions exhibit much tighterΔ(ts0 ts1) showing that more than 98 of the transactionarrivals are less than 100 milliseconds apart

4 Block and Transaction Discrepancies

In this section we study the discrepancies in blocks andtransactions between the main chain and our observedevents

41 Blockchain Fork As all main chain blocks are observed(ie Bunseen empty) through our measurement the discrep-ancy in blocks only appears as stale blocks (ie Bstale) Anincident of having stale blocks is also called a blockchain forkwhere one or more blocks are appended to a different branchof the main chain

411 Fork Characteristics and Examples A nonoverlappingblockchain fork episode e at block height [m n) is defined byidentifying two blocks

(i) Fork initiating block bf isin Bmain where height(bf)

m and n(children(bf))gt 1(ii) Fork resolving block br isin Bmain where height(br)

n and children(bi) empty for all bi isin Sn

Sn bi|height(bi) n and bi notin Bmain1113864 1113865 Figure 6(a) il-lustrates our fork episode model

We define three characteristic variables (i) its run lengthrun minus length(e) n minus m (ii) the weight (ie the number ofstale blocks in the episode) weight(e) 1113936

nhm(n(Sh)) and

(iii) the fork degree (ie the maximum number of forkbranches) degree(e) maxmlehlen(n(Sh) + 1) Figure 7 showshow characteristic variables are distributed and our findingsare summarized as follows

(i) Due to its long block time (ie sim10minutes) and lowstale block probability (ie lt 005) statisticalcharacterization of Bitcoin fork episodes suffers froma lack of sample events Even three years of live

measurement yield less than a hundred fork episodesas we only expect to observe less than 30 fork eventsper year

(ii) Ethereum fork episodes mostly run one block heightwith a single additional branch e fork degree (iemaximum of branches) is as high as three for sim5 of the episodes and the forks are not immediatelyresolved that is having two or more run lengths inabout 3 of the cases

EOS fork episodes run as long as 12 blocks that is theentire block schedule of a single BP (block producer) [26] asBPs can override the entire block-producing schedule of thepreceding BP

Putting Bitcoin which produces few fork episodes asideEthereum and EOS exhibit very different fork episodepatterns Figure 8 shows two example fork episodes ofEthereum and EOS We have used the commit graphdrawing tool [35] to visualize the fork episodes Figure 8(a)depicts four fork episodes that is [174 176) [177 178)[183 184) and [185 186) of Ethereum and Figure 8(b)shows two EOS fork episodes that is [290 292) and[294 302)e first fork episode [174 176) of Ethereumexhibits the run length of 3 the weight of 4 and the degree of4 with three nonreported (ie thus available only from ourmeasurement) stale blocks e second fork episode[294 302) of EOS exhibits the run length of 9 the weightof 9 and the degree of 2

412 Nonearliest Advertised Block Endorsement of EthereumMiners Our most interesting finding is that Ethereumminers often do not add blocks to the earliest advertisedblock during fork episodes Consider an illustrative forkepisode depicted in Figure 6(b) e episode begins as thethree blocks (ie b1 b2 and b3) are added to the fork ini-tiating block b0 e immediately following blocks (ie bi

and bj) will have their previous blockhash identifying one ofthe three previous blocks of the minerrsquos choice e block bimined by some miner may be added to the earliest block(ie b1) the other block bj is mined by a different miner whochooses a different block (ie b2) to add to To evaluateminersrsquo preference of blocks to which succeeding blocks areadded in the event of blockchain forks we define theconditional probability of miner ma adding a block to aprevious block mined by mb (by not adding to any of adifferent minerrsquos block) in fork episodes for all ma and mb

Pr miner bi( 1113857( mb|miner bj1113872 1113873

ma

prev bj1113872 1113873 bi

existbk height bk( 1113857 height bi( 1113857)

(1)

Figure 9(a) shows a histogram of the above probabilityma (x-axis) adds a block to mbrsquos block (label) over others infork episodes It is apparent that the top ranked minerssignificantly prefer adding blocks to their own mined blocksover other minersrsquo blocks Figure 9(b) depicts the same

6 Security and Communication Networks

bf

br

m

m + 1

n

n + 1

Height

(a)

Time

Arrival (b1)

Arrival (b2)

Arrival (b3)

b0

b1

b2

b3

bi

bj

(b)

Figure 6 Fork analysis model (a) Fork episode (b) Fork resolve example

EthereumEOS

0

02

04

06

08

1

Cum

ulat

ive f

requ

ency

2 4 6 8 10 120 14

Run length

EthereumEOS

0

02

04

06

08

1

Cum

ulat

ive f

requ

ency

2 4 6 8 10 12 140

Weight

EthereumEOS

0

02

04

06

08

1

Cum

ulat

ive f

requ

ency

40 62

Degree

Figure 7 Fork episode characteristics

∆ (ts0 ts1)∆ (ts0 ts3)∆ (ts0 ts7)

0010203040506070809

1Cu

mul

ativ

e fre

quen

cy(

of t

rans

actio

ns)

2 4 6 8 100Time difference (seconds)

(a)

BitcoinEthereumEOS

1 2 3 4 50Time difference (seconds)

0

02

04

06

08

1

Cum

ulat

ive f

requ

ency

( o

f tra

nsac

tions

)

(b)

Figure 5 Transaction arrival time accuracy (a) Transaction arrival time differences of Bitcoin (b) Δ(ts0 ts1) distribution

Security and Communication Networks 7

(a) (b)

Figure 8 Example fork episodes each dot represents a block followed by block hash (last six hexadecimals) arrival time block height (lastthree digits) block timestamp and its miner Each Ethereum stale block is tagged either R (reported uncle) or NR (not reported) Each EOSblock is tagged with the block sequence (out of 12) of the corresponding BPrsquos production schedule (a) Ethereum (b) EOS

SparkPoolEthermine

F2PoolNanopool

MiningPoolHubzhizhutop

Unconditional SparkPool Ethermine F2Pool Nanopool MiningPoolhub

zhizhutop

0

01

02

03

04

05

Freq

uenc

y

(a)

EarliestMixedNonearliest

Spar

kPoo

lEt

herm

ine

F2Po

olN

anop

ool

Min

ingP

oolH

ubzh

izhu

top

UU

Pool

Pand

aMin

erBT

POO

Lxn

pool

Huo

biM

inin

gPoo

lD

war

fPoo

lfir

epoo

lU

nkno

wn

Min

ing

Expr

ess

BTC

com

Pool

Min

eral

lPoo

lBe

ePoo

lH

iveo

nPoo

l2M

iner

sPPL

NS

2Min

ersS

OLO

Coin

otro

nW

POO

LEz

ilPoo

lpo

olin

o

f tot

al fo

rk re

solv

e

(b)

Figure 9 Ethereum fork resolve statistics (a) Probability of ma (x-axis) adding a block to mbrsquos block (b) Probability of adding to the earliestpropagated block

8 Security and Communication Networks

probability by labeling whether or not the chosen block (byma) is the earliest propagated one e ldquoearliestrdquo label in-dicates that the block to which the newly mined block (byma) is added has been observed as the earliest one to arrivecongruently among all eight measurement locations (Asblock arrival times are measured in eight different locationsthe arrival order can be conflicting e ldquomixedrdquo labelrepresents the conflicting cases) For example the topranked pool SparkPool chose the earliest arriving blocksim55 of the time 3409 out of 6234 blocks among the other2825 blocks that were added to nonearliest previous blocksSparkPoolrsquos own blocks were chosen over others 1211 timeswhile other poolsrsquo blocks were preferred to SparkPoolrsquos only24 times In the meantime Nanopool chose the earliest one amajority of the time For the top 25 ranked mining pools onlyfour of them added blocks to the earliest arriving blocks morethan 90 of the timeis contradicts the earliest propagatedblock endorsement assumption that is broadly adopted inmining-related research [36ndash38]

One possible explanation of the phenomenon is that themining pools adopt their own block preferring strategy as asimple precautionary defense against yet unknown selfishmining pools the profitability of selfish mining largelydepends on the probability of honest pools adding to theattacking poolrsquos branch

413 Cut-Tail Fork Pattern of EOS BPs We find that theEOS fork episodes occur in a way that BPs are cutting the tailof the previous BPrsquos produced blocks EOS adopts the DPoSconsensus mechanism [26] 21 block producers (BPs) areelected by voting and scheduled to produce 12 consecutiveblocks in 6 seconds (ie 500ms for each block) in the al-phabetical order of their names Figure 10 shows thenumbers of switching (by schedule) events and cut-tail forkevents of all immediate BP pairs We observe a high fre-quency of such events when bitfinexeos1 is producing blocksby appending to big onersquos blocks while there are accusationsof BPrsquos dishonest behaviors we believe that the reportedbitfinexrsquos performance problem is the compelling reason forthe phenomenon [39]

42 Unseen and Stale Transactions

421 Private Transaction Mining Unseen transactions arecharacterized by the strong evidence that implies that theunseen transactions are indeed never advertised to the net-work Table 6 categorizes 9587 of Ethereum unseentransactions by using the from addresses of the transactions(We use prefixes followed by ⋆ in presenting hash valueseg address (ie pubkey hash) and txid for brevity Weunderstand this does not entirely anonymize identity as thereaders can verify their results against ours by matching theprefixes) Public names are retrieved from Etherscan [16] Aminer is specified in the table only if all blocks that includethe unseen transactions with the from address are con-gruently mined by that single miner It shows that most ofthe unseen transactions are indeed the block minerrsquos owntransactions

Table 7 shows unseen Bitcoin transactions categorized bythe identified reasons sim 67 of the unseen transactions areeither zero-fee transactions or zero-fee-transaction-dependenttransactionsWe define a transaction t isin transactions(b) as adependent transaction if at least one of input transactions oft is included in the same block b

Bitcoin Core [28] implementation does not propagatetransactions with zero transaction fee Also a dependenttransaction cannot be mempooled until the transaction towhich it is dependent is mempooled consequently it cannotbe relayed to peers e Bitcoin Core mempool imple-mentation justifies the inexistence of zero-fee and zero-fee-dependent transactions from our measurement Existence ofa stale transaction which shares the same transaction inputwith the unseen transaction may imply a possible double-spend attempt a variant [40] involving private mining of ablock with ti while advertising a conflict transaction tj suchthat inputs(ti)cap inputs(tj)neempty we have observed 27 suchunseen transactions without a certainty of attack intentionsor if they are not indeed advertised Lastly multisig trans-action inputs often imply off-chain protocols where signedtransactions are exchanged out-of-band [41] and havingOP_RETURN transaction output implies special purposeprotocols of Bitcoin for example sidechains where theirrelationship with miners require further investigation [42]e presence of unseen transactions by either privatetransaction mining or potential out-of-band delivery oftransactions has a subtle security implication One obviousside effect is privatization of transaction fees the transactionfees of privately mined ones are exclusively obtainable by theprivate miner alone unless the network is fully utilized Ifthe network is fully utilized a miner is forced to include herprivate transactions at the expense of not including othertransactions as the block capacity is limited

422 Conflict Stale Transactions Stale transactions arenetwork-transmitted transactions that are not included inany of the blocks

Table 8 shows the stale transaction counts observed ateach location e stale transactions account for 020369 and 047 of Bitcoin Ethereum and EOS transac-tions respectively Ethereum transactions had an order ofmagnitude more chance of being stale than others

As for public blockchains with transaction fees that isBitcoin and Ethereum stale transactions are mostly at-tributable to conflict Table 9 summarizes the identifiedreasons for transactions being stale A stale Bitcoin trans-action is attributable to conflict if there are one or moretransactions sharing at least one transaction input (ie vin)

An Ethereum transaction is attributable to conflict ifthere is another transaction with the same nonce from thesame account A widely known reason for two or moretransactions being in conflict is transaction replacementsuch as replace-by-fee [43] On the other hand slightly morethan 5 of Bitcoin transactions are stale because at least oneof their transaction inputs is also stale

On the other hand roughly one out of ten staleEthereum transactions is attributable to improper ordering

Security and Communication Networks 9

of nonce (e transaction nonce should be equal to thenumber of transactions sent from the address) nonce is toohigh (983) or too low (002) Last but not least 727 ofstale transactions are not included in blocks because theaccount is not sufficiently funded (An Ethereum accountshould have balance ge value+ gastimes gas price to execute thetransaction [44]) An Ethereum account can be

insufficiently funded when executing a transaction for anumber of reasons [45]

423 EOS Transaction Discrepancy EOS exhibits unseenand stale transactions far different from those of Bitcoin orEthereum that is the PoW blockchains with transaction feeEOS software is not bundled with peer discovery rather thenode operator is required to look up for candidate BPrsquospeering services timely delivery of blockchain data andreliability of the node is dependent on the peering nodes ofchoice (Indeed we have experienced service disruption bydisconnecting from peers for unknown reasons)e notionof being conflict in two or more transactions that is themost frequent reason for transactions being stale for Bitcoinand Ethereum is not applicable to EOS (EOS adopts theaccount model without transaction ordering per accountthus there should be no conflict transaction outputs or thesame account nonce) On the other hand EOS requires

eosh

uobi

pool

-eos

infst

ones

eosfl

ytom

ars-

eosh

uobi

pool

zbeo

sbp1

1111

-atti

clab

eosb

attic

labe

osb-

big

one

hoo

com

-new

dex

bpw

hale

exco

m-z

beos

bp11

111

start

eosio

bp-w

hale

exco

meo

sdot

wik

ibp-

eosfl

ytom

ars

eosc

anno

nchn

-eos

dotw

ikib

pbi

gon

e-bi

tfine

xeos

1eo

sinfst

ones

-eos

iom

eeto

nehe

lloeo

scnb

p-ho

oco

meo

slaom

aoco

m-e

ossv

12eo

ssv

slow

mist

iobp

-sta

rteo

siobp

eoss

v12e

ossv

-hel

loeo

scnb

peo

sbei

jingb

p-eo

scan

nonc

hneo

siosg

1111

1-eo

slaom

aoco

meo

siom

eeto

ne-e

osio

sg11

111

bitfi

nexe

os1-

cert

ikeo

sorg

new

dex

bp-s

low

mist

iobp

coch

ainw

orld

-eos

asia

1111

1bi

tfine

xeos

1-co

chai

nwor

ldce

rtik

eoso

rg-c

ocha

inw

orld

eosa

sia11

111-

eosb

eijin

gbp

new

dex

bp-o

kcap

italb

p1eo

siom

eeto

ne-e

osla

omao

com

okca

pita

lbp1

-slo

wm

istio

bpco

chai

nwor

ld-e

osbe

ijing

bpne

wde

xbp

-sta

rteo

siobp

eosa

sia11

111-

eosc

anno

nchn

eosla

omao

com

-hel

loeo

scnb

pco

chai

nwor

ld-e

osca

nnon

chn

cert

ikeo

sorg

-eos

beiji

ngbp

eoss

v12e

ossv

-hoo

com

bitfi

nexe

os1-

eosa

sia11

111

eosin

fston

es-e

osla

omao

com

okca

pita

lbp1

-sta

rteo

siobp

BP switching (left)Cut-tail (right)

0

5000

10000

15000

20000

25000

BP sw

itchi

ng ev

ents

0

100

200

300

400

500

cu

t-tai

l eve

nts

Figure 10 EOS BP switching and cut-tail events

Table 6 Ethereum unseen transactions

From address Public name Transaction count Miner0xea67⋆ Ethermine 128145 (7242) Ethermine0x2a65⋆ DwarfPool 22955 (1297) DwarfPool0x8fd0⋆ Unknown 11346 (641) SparkPool0x829b⋆ F2Pool 4453 (251) F2Pool0x4c54⋆ HiveonPool 1135 (064) SparkPool0x99c8⋆ BeePool 468 (026) BeePool0xdba7⋆ Unknown 348 (020) UUPool0x464b⋆ FKPool 340 (019) FKPool0xf687⋆ Unknown 217 (012) AntPool0xa801⋆ Unknown 151 (009) AntPool0xbe7c⋆ Unknown 126 (007) AntPool0xb96f⋆ Unknown 101 (006) AntPool

Sum 169785 (9587)

Table 7 Bitcoin unseen transactions

Category Transactioncount

Zero-fee transaction 148 (5068)Zero-fee-transaction-dependent transaction 48 (1644)Multisig transaction input 43 (1473)Conflict with stale transaction 27 (925)OP_RETURN transaction output 26 (890)Sum 292 (10000)

10 Security and Communication Networks

contract users to stake tokens for CPU time that can bededucted by transaction executions A requested transactioncan be rejected thus being stale due to the lack of CPU timeor other resources similarly Replaying the entire statechanges of EOS to find out stale transactions due to lack ofresources is not possible unless all transaction and state logsof the entire BPs are available

On the other hand EOS transactions have two additionalattributes which are not available in the Bitcoin or Ethereumtransaction structures

(i) Reference block every EOS transaction refers to ablock by specifying the block number and hash notonly to prevent replay attacks but also to signal thenetwork that the userrsquos stake is on a specific fork

(ii) Expiration time EOS transactions have explicitexpiration times

If a transactionrsquos reference block is not part of the mainchain at the time of execution the transaction cannot beexecuted (and thus cannot be included in a block) We haveidentified that 18 of stale transactions apply to this case Tofurther identify unknown reasons we consider four timedevents that are relevant to transaction execution

(i) Last irreversible block arrival time arrival(blib) thearrival time of transactionrsquos reference block EOStransactions by default refer to the last irreversibleblock (LIB) [26]

(ii) Head block arrival time arrival(bhead) the scheduledtime of the head block when transaction is arrived

(iii) Transaction arrival time arrival(t) the arrival timeof transaction t

(iv) Expiration time exp(t) the expiration time oftransaction t

e three time differences that is Δexp Δincl and Δtrxare investigated to find characteristics of unseen (Tunseen)and stale (Tstale) transactions over the normal transactions(Tincluded) Figure 11 illustrates the relevant events and timedifferences of them Δexp measures the time difference be-tween the two scheduled (ie virtually timed) events Δincland Δtrx are defined by the arrival events to our monitornode Figure 12 shows the distributions of Δexp Δincl andΔtrx We find that unseen transactions have prolonged Δinclimplying that the delay of newly produced blocks can causenewly generated transactions not promptly delivered be-cause the sync manager is in the Head Catch-Up mode astransactions are only transferred in In-Sync mode by itsdesign [24] Stale transactions with relatively small Δtrx canbe attributable to problematic dApp implementations re-ferring to non-LIB blocks the chain instability caused byblockchain fork mostly due to the cut-tail behavior shown inSection 41 can cause transactions being rejected for im-mature block reference

However we do not find any reason attributable to thetransaction expiration Although the unseen transactionstend to have smallΔexp the expiration times are only as smallas 30 seconds (ie the default expiration time) Particularlyone or more EOS applications set the expiration time to180 seconds (other than the default 30 seconds) and morethan half of the stale transactions are invoked by thoseapplications

While transaction is the smallest unit of execution inBitcoin and Ethereum the unit of contract execution in EOSis action [24] A transaction consists of one or more actionsHowever the constituent actions in a single transactioncannot be separately advertised or executed accordingly weapply the identical transaction model to EOS without loss ofgenerality

5 Block and TransactionArrival Characteristics

51 Arrival Processes All three blockchains we study in thispaper are designed to publish capacity constrained blocks intargeted regular time intervals An incarnation of suchdesign is expected to exhibit a Poisson block arrival processWhile it is claimed that Bitcoin block arrivals do not entirelyexhibit a homogeneous Poisson process due to its difficultadjustment mechanism [46] transaction arrival processes ofblockchains are not studied in the literature to the best of ourknowledge A particularly meaningful step toward under-standing the arrival process of events generated by a complexsystem is examining if the arrival events are independent orexhibiting a correlated structure [47]

e variance-time log-log plots [48] of the block andtransaction arrival event time series are depicted in

Table 8 Stale transactions

Region Bitcoin Ethereum EOSAsia-East 41720 1170706 mdashAsia-South 41653 1194018 504277Europe-North 41693 1192435 470480Europe-West 41668 1123680 450140North America-Northeast 41703 1212210 588711US-Central 41683 1212389 505160US-East 41692 1186488 mdashUS-West 41672 1167627 480207Combined 42023 1351847 672999

Table 9 Identified reasons of stale transactions

Category Transaction count(a) Bitcoin

Conflict 39408 (9378)Stale transaction input 2307 (549)Conflict and stale transaction input 308 (073)Sum 42023 (10000)

(b) EthereumConflict 1208588 (8924)Nonce (skipped) 133161 (983)Nonce (used) 251 (002)Insufficient fund 9847 (727)Sum 1351847 (9982)

(c) EOSFork 12106 (180)Others 660893 (9820)Sum 672999 (10000)

Security and Communication Networks 11

Figure 13(a) As regards the block arrival processes Bitcoinblock arrivals exhibit a linear slope β minus23 e estimatedHurst parameter H 1 + β2 43 implies that the processis not a homogeneous Poisson process but LRD (Long-Range Dependent) contrary to what is expected for a regularinterval event generation [46] Ethereum block arrivalsapproximate the Bitcoinrsquos except for the high aggregationlevel due to high stale block rate EOS block arrivals incontrast follow the slope β minus1 in the low aggregation levelas the block generation is indeed regularly scheduled

Figure 14 shows the variance-time plot of Ethereum andEOS block arrival time series by taking all block arrivalevents (Bobs) and main chain block arrivals only (Bmain) Weconfirm that Ethereum block arrivals indeed exhibit astraight line (close to Bitcoin) if excluding stale blocksHowever EOS block arrivals do not exhibit a straight line

even if we exclude stale blocks due to delayed burst blockarrivals possibly due to cut-tail fork patterns (see Section41)

e transaction arrival processes of all three blockchainsappear to exhibit LRD with Hurst parameter Hgt 56 asβltminus13 To further identify analytical distributions that fitbest the empirical ones the coefficient of variation (σμ) andskewness (ie the standardized third moment) of transac-tion interarrival times are computed for every measurementdataset and compared to the relationships expected for theexponential lognormal Weibull and Gamma distributionsin Figure 13(b) We find that Bitcoin Ethereum and EOStransaction interarrival times are fit best Gamma Weibulland lognormal distribution respectively Individual datasetsare also examined for the fitness of the distribution to findthat the empirical distribution fits the analytical distribution

Virtualclock

Time

Transaction initiator

Time

Blockproducer

Time

Monitornode

Time

Scheduled block time of blib

Scheduled block time of bhead

Scheduled block time of bincl

1 Produce and propagate blib

2 Produce and propagate bhead

Expiration time of t

4 Produce and propagate bincl

Δexp

Δtrx

Δincl

3 Create and propagate t

Figure 11 EOS transaction analysis model

Tincluded

Tstale

Tunseen

0010203040506070809

1

Cum

ulat

ive f

requ

ency

100 200 300 400 5000Time difference (seconds)

(a)

Tincluded

Tunseen

01 1 10 100 1000001Time difference (seconds)

0010203040506070809

1

Cum

ulat

ive f

requ

ency

(b)

Tincluded

Tstale

0010203040506070809

1

Cum

ulat

ive f

requ

ency

01 1 10 100 1000001Time difference (seconds)

(c)

Figure 12 EOS transaction timing analysis (a) Δexp (b) Δincl (c) Δtrx

12 Security and Communication Networks

well except for the small interarrival time ranges For ex-ample Figure 15 depicts the CDF of Ethereum transactioninterarrival times observed in US-West Although the em-pirical distribution fits Weibull with parameters computedwith the maximum likelihood estimator [49] sample pointsunder several milliseconds appear to be unreliable (We areyet unaware of the reason However it is known that thetime source of commodity operating systems is not accurateand we need an external time source for accurate sub-millisecond timing measurement [50])

52AdvertisementRedundancy Bitcoin and Ethereum nodepieces of software are implemented to maintain a large

number of peer connections with multiple random remotenodes Bitcoin Core can connect up to 125 peers where 8 ofthem are outbound connections Go Ethereum maintains 50peer connections where 16 of them are outbound by default(see Table 1) On the other hand partitioning attacks aredeveloped to isolate a blockchain node from the others bytampering with all such peer connections Partitioning at-tacks usually exploit vulnerable peer management mecha-nisms of Bitcoin [51] and Ethereum [52] Such attacks arealso examined in the context of ISPrsquos BGP hijacking [53] anda stealthier variant relieving the attacker from the risk ofgetting exposed [54] e attacks often rely on imple-mentation vulnerabilities for efficient eclipsing of peerswhile known vulnerabilities are getting addressed for ex-ample the lack of parallel block download sessions causing

Slope = ndash1

Trx BitcoinTrx EthereumTrx EOS

Blk BitcoinBlk EthereumBlk EOS

ndash12

ndash10

ndash8

ndash6

ndash4

ndash2

0Lo

g no

rmal

ized

var

ianc

e

124 6 10 140 2 8Aggregation level

(a)

Lognormal

Weibull

Gamma

Exponential

BitcoinEthereumEOS

0

5

10

15

20

Stan

dard

ized

third

mom

ent

1 2 3 40Coefficient of variation

(b)

Figure 13 Transaction arrival characteristics (a) Variance-time plot of block and transaction arrivals (b) Cov versus skewness oftransaction interarrival times

Ethereum - Bobs

Ethereum - Bmain

EOS - Bobs

EOS - Bmain

ndash12

ndash10

ndash8

ndash6

ndash4

ndash2

0

Log

norm

aliz

ed v

aria

nce

2 4 6 8 10 12 140Aggregation level

Figure 14 Variance-time plot of block arrivals including staleblocks (Bobs) and excluding stale blocks (Bmain)

EmpiricalExponential μ = 0024

Lognormal μ = 00354 σ2 = 00486Pareto k = 0000212 a = 0231Weibull c = 0589 a = 00147

00001 0001 001 01 1000001Time (seconds)

0

02

04

06

08

1

Cum

ulat

ive f

requ

ency

Figure 15 Empirical and fitted analytical distributions of Ether-eum transaction interarrival times

Security and Communication Networks 13

temporary denial of blocks (reported in [27] and fixed byrecommending three concurrent download sessions in [55])let attackers successfully partition the node without eclipsingall peer connections [53] A simple countermeasure of in-creasing the number of peer connections on the other handis applied to the reference public blockchain implementa-tions [56 57] to inflate attack complexity

We investigate the degree of a peerrsquos advertisementredundancy on newly generated blocks and transactions toevaluate the efficacy of partitioning attacks and the coun-termeasure of increasing the number of peer connectionsFigure 16 shows how redundantly newly generated blockinformation is offered by peers Bitcoin nodes have main-tained sim43 peer connections that is 8 outbound and ad-ditional 35 inbound connections on average and Ethereumnodes record all 50 peer connections established during theentire observation period

For each newly generated block one-third of peersadvertised the block header to our Bitcoin node and morethan 90 of Ethereum peers signaled availability of theblocks In consequence successfully partitioning a noderequires compromise of peers proportional to the totalnumber of peer connections Increasing the number of peerconnections will burden the attacker linearly as expected

Figure 17 shows how redundantly the newly generatedtransaction information is offered by peers While one out ofthree Bitcoin peers also advertises new transactions viaINVENTORYmessage [58] half of the Ethereum peers havesent new transactions to our node in average Bitcoin andEthereum blocks are advertised with the block header(rather than the direct delivery of all block contents) Bitcointransactions are also advertised with INVENTORY messagebefore the whole contents are transferred HoweverEthereum transaction data that is the entire contents aredirectly sent by peers (Ethereum now has a pooled trans-action delivery model in its newer ETH64 protocol [30])We also find that there are cases with much less advertisedtransactions and have identified that they are indeed mostlystale ones stale transactions are mostly due to conflict (seeSection 42) and the nodes that already queued the conflicttransaction will not relay the stale one

6 Discussion

61 Implication on Mining Attacks Cryptocurrency mininghas been a popular subject in assessing the security ofBitcoin selfish mining [37] block withholding attack [36]and a mixed strategy [38] have been studied Although it isshown that selfish behavior in mining is always moreprofitable than being honest without need for a mutualagreement of not attacking each other [38] we find thatselfish mining is not the preferred strategy All selfish miningstrategies will result in blockchain forks but we observe avery low fork probability (ie 004) for Bitcoin On theother hand selfish mining on Ethereum has been studiedonly recently to unanimously claim that selfish mining isalso profitable for Ethereum miners however it is lessprofitable than Bitcoin due to its uncle reward system [59]Our result in Section 4 shows that a majority of Ethereum

miners choose to add to their own produced blocks over theearliest propagated blocks How does this affect the selfishmining strategy

e selfish mining strategy assumes a parameter c whichdefines the fraction of honest minersrsquo mines on the attackerrsquosfork branch (e parameter comes into play in case (f ) of[27]) If the attacking pool has a network-wise superiorposition in block propagation (ie cgt 05) the selfishmining strategy is profitable for pools with proportionalmining power αgt 25 [37] Absolute network inferiority(ie c 0 due to a defensive mining strategy such as the onepresented in Section 41) increases the required miningpower to 33 the 33 mining power appears to be sig-nificantly harder to achieve in the real world [20]

As for the FAW (Fork-After-Withholding) attackstrategy [38] the network capability parameter C defines theprobability that an attackerrsquos FPoW (Full Proof-of-Work)block (during infiltration mining) is selected as a main chainblock C affects both the attack reward and whether theminerrsquos dilemma holds or not in the mutual attacking gameAs an example case (Section 9 of [38]) of a two-pool gamebetween F2Pool and BitFury the absolute network inferi-ority drops C from 0914 to 03 to make it a dilemmatic gameagain Unfortunately minersrsquo own block preferences cannotbe directly transferred to a single parameter of c or C it callsfor a model change from previous mining studies

62 Conflict Transactions and Double-Spending AttacksDouble-spending attacks have been studied in the context ofBitcoin fast payments where zero or only one confirmation isrequired to complete an offline merchandise transaction[60] real-world cases where two conflict transactions dis-parately arrive at different measurement locations mayimply such attacks Table 10 shows the cases where twotransactions are in conflict (and thus only one of themis included in a block ie inputs(ti)cap inputs(ts)neemptyand existb isin Bmain ti isin transactions(b) (∄b isin Bmain ts isintransactions(b) is indisputable given a consistent transactionledger)) and two different subsets of the monitors havemempooled either one of them We also have identified 27unseen transactions implying possible one-confirmationattack variant requiring the private mining (ie not ad-vertising the double-spending transaction to the network) in

5 10 15 20 25 30 35 40 45 500 of peers

0

005

01

015

02

025

Freq

uenc

y

BitcoinEthereum

Figure 16 Peer redundancy of block advertisement

14 Security and Communication Networks

Section 42 As for the countermeasure of such attacks bydeploying monitors [60] deployment of 8 monitors in thenetwork to detect the attacks would fail at most 27 out of 95times (sim30) assuming that those 27 unseen transactionswe have identified are initially advertised to the network

63 Potential Impact on Blockchain ApplicationsEthereum and EOS are the most widely used smart contractplatforms fostering various decentralized applications Bit-coin which lacks the capability of executing complex smartcontract codes is also recently utilized to execute smartcontracts for decentralized applications [50 61] Eventhough our work focuses on the fundamental blockchainmechanisms in terms of transactionblock production andpropagation the impact of our findings on decentralizedapplications can be foresighted

According to our blockchain fork results (Section 41)the lack of selfish mining in the real world was speculated bya very low stale block rate of Bitcoin network and prevalenceof nonearliest block endorsement by Ethereum miners Asprofitability of selfish mining encourages miners to behavein a way of producing more blockchain forks the perfor-mance degradation is proportionate to the number of minerswho adopt the selfish mining strategy the key performancemetrics affecting the blockchain application performance

such as node response time or block delivery time are shownto be noticeably degraded due to the selfish mining [62] Forexample decentralized identities issued or revoked on suchblockchains [63 64] cannot be responsively finalized due toinflated blockchain forks Our results show that the selfishmining is not prevalent in the real world thus the appli-cation performance impact is overrated even though it istheoretically shown that miners have every reason to beselfish [38] As for EOS we reported cases where a sequenceof (up to 12) blocks being stale are often observed in suc-cessive mining of two BPs however the rate is too low (ie004) to impact the performance of applications (Section32)

Transaction arrival processes being LRD (Section 51)pose a technical challenge in provisioning transactionprocessing scalability especially for Layer-2 blockchain ap-plication solutions [65 66] For example Layer-2 rollupsolutions require transaction relays which aggregate indi-vidual user transactions of a given blockchain applicationdeployed in the network often without a priori knowledge ofnetwork load One way of solving the problem is a properprioritization of transactions based on the applicationcontext

Lastly blockchain network partitioning can be thebiggest concern for blockchain service providers We ob-served that the increased numbers of peer connections inblockchain reference implementations effectively provide ahigher degree of information redundancy (Section 52)However increased number of peer connections can beexploitable for an attacker who has a denial-of-service attackvector or an invalid transaction initiated by a simple ap-plication bug can flood the network [45]

64 Limitation Our measurement study has several limi-tations First of all our results may only capture only a fewmonths of blockchain network operations In the meantimethe permissionless blockchain pieces of software are in activedevelopment for example Ethereum now utilizes the pooledtransaction delivery [67] instead of unsolicited transactiondelivery which was the only mode at the time of our

Table 10 Bitcoin disparately mempooled transactions

monitors mempooledti

monitors mempooledts

Transactioncount

7 1 26 (3824)6 2 14 (2059)5 3 10 (1471)4 4 5 (735)3 5 5 (735)2 6 3 (441)1 7 3 (441)5 1 1 (147)6 1 1 (147)

Sum 68 (10000)

Tincluded

Tstale

5 10 15 20 25 30 35 40 45 500 of peers

0

005

01

015

02

025

03Fr

eque

ncy

(a)

Tincluded

Tstale

0002004006008

01012014016

Freq

uenc

y

4030 500 10 20 of peers

(b)

Figure 17 Peer redundancy of transaction advertisement (a) Bitcoin (b) Ethereum

Security and Communication Networks 15

measurement Both cryptocurrency market values andblockchain network utilizations are rapidly increasing andthus miners are getting more motivated to optimize theirperformance for example Bitcoin fork probability has be-come far smaller than what is reported previously (seeSection 41)

Second the blockchain state information is not collected inour measurement Our analysis is performed based on onlyavailable information stored in block and transaction logs Wehave utilized an Ethereum archive node [44] to query historicalstate information (eg account balance or account nonce) inSection 42 However such proactive state replication is farmore complicated with EOS unless the full node is configuredto operate as a producing node and logging the state infor-mation thus EOS stale transactions could not be fully un-derstood without the missing EOS network state information

7 Related Work

71 Blockchain Data Analysis Historical transaction data ofBitcoin have often been studied for economic aspects such ascryptocurrency abuse [17] anti-money-laundering [18] andmonetary flow of businesses [19] However historicalblockchain data usually available from block explorer ser-vices are not sufficient for our research purpose

72 Blockchain Measurement Researchers have performedblockchain measurement studies to assess the degree ofdecentralization [20] to investigate demographic informa-tion of network nodes [34 68] to study mining pool be-havior [22] and to evaluate security of PoW blockchains [21]against known attacks such as double-spending attack [60]and selfish mining [37] Our work expands the under-standing of previous security evaluations with the keyfindings acquired from our large-scale transaction and blockmeasurement

73 Blockchain Attacks Partitioning attacks usually exploitvulnerable peer management mechanisms of Bitcoin [51]and Ethereum [52] Such attacks are also examined in thecontext of ISPrsquos BGP hijacking [53] and a stealthier variantrelieving the attacker from the risk of getting exposed [54]Cryptocurrency mining has been a popular subject inassessing the security of Bitcoin selfish mining [37] blockwithholding attack [36] and a mixed strategy [38] have beenstudied Double-spending attacks have been studied in thecontext of Bitcoin fast payments [60]

74 Block Explorer Services We have surveyed the popularblock explorer services of Bitcoin [5 10 12] Ethereum[10 13 16] and EOS [11 14 15] to see the availability ofinformation beyond what is recorded in the main chainblock data we have utilized in our study namely

(i) Stale blockstransactions no Bitcoin and EOS blockexplorers provide stale block information (A relatedstudy [36] has utilized a Bitcoin block explorer service[68] to retrieve stale blocks However the service has

been terminated in March 2019) All Ethereum blockexplorers provide only reported stale blocks (ie uncleblocks [23]) (Ethereum provides incentives for unclestale blocks [44] so that miners include them in theirmined blocks for profit)No block explorers provide stale transaction infor-mation unless one is currently pooled

(ii) Blocktransaction arrival times all block explorersprovide block timestamps that are recorded in theblock headers not the actual times of arrival Ourblockchain fork and gap analysis require measuredblock arrival times at multiple locations All blockexplorers show transaction timestamps identical to theblock timestamp to which the transactions belong(Recent Bitcoin transactions have different timestampsthan the block timestamps in [4] while the timestampsare only at a granularity of one minute) [69 70]

8 Conclusion

We have measured transaction and block arrival events ofthe three permissionless blockchains We have devised anoble analysis model and analyzed completeness of ourblock and transaction logs Finally we have studied thediscrepancy in measured events and arrival characteristics toshare our key findings including a false universal assumptionof previous mining-related studies

Data Availability

e measurement data used to support the findings of thisstudy have not been made available because they containprivate information that can be used to identify individualblockchain nodes

Disclosure

is is an extended and revised version of a conference paperpresented in IEEE ICDCS 2021 [41]

Conflicts of Interest

e authors declare that they have no conflicts of interest

Acknowledgments

e authors would like to thank Seungwon Woo DaegeunYoon and Changhyun Lee for helping them with themeasurement instrumentation is work was supported byElectronics and Telecommunications Research Institute(ETRI) grant funded by the Korean Government (21ZR1300Research on Intelligent Cyber Security and Trust Infra)

References

[1] S Nakamoto ldquoBitcoin a peer-to-peer electronic cash systemrdquo2019

[2] V Buterin ldquoEthereum white paperrdquo 2013 httpsethereumorgenwhitepaper

[3] Monero ldquoMonerordquo 2020 httpswebgetmoneroorg

16 Security and Communication Networks

[4] bitcoincashorg httpswwwbitcoincashorg[5] Blockchaincom httpswwwblockchaincom[6] Ripple ldquoXRP e best digital asset for global paymentsrdquo

2020 httpsripplecomxrp[7] I Foundation ldquoIotardquo 2021 httpswwwiotaorg[8] ldquoEosiordquo 2020 httpseosio[9] S Orsquoneal ldquoEos proves yet again that decentralization is not its

priorityrdquo 2018 httpscointelegraphcomnewseos-proves-yet-again-that-decentralization-is-not-its-priority

[10] Blockchair httpsblockchaircom[11] Bloksio httpsbloksio[12] BTCcom ldquoBitcoin block explorerrdquo 2021 httpsbtccom[13] Ethereum block explorer httpsethbtccom[14] eosflareio Eos block explorer httpseosflareio[15] EOSPark ldquoEos block explorerrdquo 2021 httpseosparkcom[16] Etherscan Ethereum explorer httpsetherscanio[17] S Lee C Yoon and H Kang ldquoCybercriminal minds An

investigative study of cryptocurrency abuses in the dark webrdquoin Proceedings of the Network and Distributed System SecuritySymposium pp 1ndash15 Internet Society San Diego CA USAFebruary 2019

[18] MMoser R Bohme and D Breuker ldquoAn inquiry into moneylaundering tools in the bitcoin ecosystemrdquo in Proceedings ofthe 2013 APWG eCrime Researchers summit pp 1ndash14 IEEESan Francisco CA USA September 2013

[19] M Lischke and B Fabian ldquoAnalyzing the bitcoin network thefirst four yearsrdquo Future Internet vol 8 no 1 2016

[20] A E Gencer S Basu I Eyal R V Renesse and E G SirerldquoDecentralization in bitcoin and ethereum networksrdquo inProceedings of the International Conference On FinancialCryptography and Data Security pp 439ndash457 SpringerNieuwport Curaccedilao February 2018

[21] A Gervais G O Karame KWust V Glykantzis H Ritzdorfand S Capkun ldquoOn the security and performance of proof ofwork blockchainsrdquo in Proceedings Of the 2016 ACM SIGSACConference on Computer and Communications Securitypp 3ndash16 Vienna Austria October 2016

[22] C Wang X Chu and Q Yang ldquoMeasurement and analysis ofthe bitcoin networks a view from mining poolsrdquo 2019httpsarxivorgabs190207549

[23] G Wood ldquoEthereum A secure decentralised generalisedtransaction ledgerrdquo Ethereum Project Yellow Paper vol 1512014

[24] ldquoTransactions protocol eosio developer docsrdquo 2018 httpsdeveloperseosiowelcomev20protocoltransactions_protocol

[25] Y Sompolinsky and A Zohar ldquoSecure high-rate transactionprocessing in bitcoinrdquo in Proceedings of the InternationalConference On Financial Cryptography and Data Securitypp 507ndash527 Springer San Juan PR USA January 2015

[26] Blockone ldquoConsensus protocolrdquo 2018 httpsdeveloperseosiowelcomev20protocolconsensus_protocol

[27] A Gervais H Ritzdorf G O Karame and S CapkunldquoTampering with the delivery of blocks and transactions inbitcoinrdquo in Proceedings Of the 22nd ACM SIGSAC ConferenceOn Computer and Communications Security pp 692ndash705Denver CO USA October 2015

[28] ldquoGithub Bit coinrdquo 2020 httpsgithubcombitcoinbitcoin[29] G Ethereum ldquoGo ethereumrdquo 2020 httpsgithubcom

ethereumgo-ethereum[30] Google ldquoGoogle cloudrdquo 2021 httpscloudgooglecom[31] ldquoHow to replay from a snapshotrdquo 2018 httpsdeveloperseos

iomanualseoslatestnodeosreplayshow-to-replay-from-a-snapshot

[32] C Decker and R Wattenhofer ldquoInformation propagation inthe bitcoin networkrdquo in Proceedings of the IEEE P2P 2013Proceedings pp 1ndash10 IEEE Trento Italy September 2013

[33] ldquoEthereum uncle raterdquo 2020 httpsychartscomindicatorsethereum_uncle_rate

[34] J A Donet C P Sola and J H Joancomartı ldquoe bitcoin p2pnetworkrdquo in Proceedings of the International Conference OnFinancial Cryptography and Data Security pp 87ndash102Springer Christ Church Barbados March 2014

[35] G S Davies ldquoBit-booster - offline commit graph drawingtoolrdquo 2016 httpbit-boostercomgraphhtml

[36] N T Courtois and L Bahack ldquoOn subversive miner strategiesand block withholding attack in bitcoin digital currencyrdquo2014 httpsarxivorgabs14021718

[37] I Eyal and E G Sirer ldquoMajority is not enough bitcoin miningis vulnerablerdquo in Proceedings of the International Conferenceon Financial Cryptography and Data Security pp 436ndash454Springer Christ Church Barbados March 2014

[38] Y Kwon D Kim Y Son E Vasserman and Y Kim ldquoBeselfish and avoid dilemmas fork after withholding (faw) at-tacks on bitcoinrdquo in Proceedings Of the 2017 ACM SIGSACConference On Computer and Communications Securitypp 195ndash209 Abu Dhabi UAE April 2017

[39] B Research ldquoDecentralisation governance and eos - a lostcaserdquo 2020 httpsresearchbinancecomenanalysiseos-governance

[40] B Wiki ldquoIrreversible transactions - finney attackrdquo 2012httpsenbitcoinitwikiIrreversible_Transactions∖Finney_attack

[41] J Poon and T Dryja ldquoe bitcoin lightning network scalableoff-chain instant paymentsrdquo 2016

[42] M Bartoletti and L Pompianu ldquoAn analysis of bitcoin op_return metadatardquo in Proceedings of the International Con-ference On Financial Cryptography and Data Securitypp 218ndash230 Springer Sliema Malta April 2017

[43] ldquoReplace by feerdquo 2018 httpsenbitcoinitwikiReplace_by_fee

[44] E Foundation ldquoNode and clientsrdquo 2020 httpsethereumorgendevelopersdocsnodes-and-clients

[45] H Heo and S Shin ldquoBehind block explorers public block-chain measurement and security implicationrdquo in Proceedingsof the 41th IEEE International Conference On DistributedComputing Systems IEEE Washington DC USA In pressWashington DC USA July 2021

[46] R Bowden H P Keeler A E Krzesinski and P G TaylorldquoBlock arrivals in the bitcoin blockchainrdquo 2018 httpsarxivorgabs180107447

[47] M E Crovella and A Bestavros ldquoExplaining world wide webtraffic self-similarityrdquo Technical Report Citeseer PrincetonNJ USA 1995

[48] H Zhang Y Shu and O Yang ldquoEstimation of hurst pa-rameter by variance-time plotsrdquo in Proceedings of the 1997IEEE Pacific Rim Conference on Communications Computersand Signal Processing PACRIM 10 Years Networkingthe Pacific Rim 1987-1997 IEEE Victoria BC CanadaAugust 1997

[49] A Feldmann ldquoCharacteristics of TCP connection arrivalsrdquo inSelf-Similar Network Traffic and Performance EvaluationK Park andWWillinger Eds pp 367ndash399Wiley HobokenNJ USA 2000

[50] RSK ldquoRSKrdquo 2021 httpswwwrskco[51] E Heilman A Kendler A Zohar and S Goldberg ldquoEclipse

attacks on bitcoinrsquos peer-to-peer networkrdquo in Proceedings of

Security and Communication Networks 17

the 24th USENIX Security Symposium pp 129ndash144 Wash-ington DC USA April 2015

[52] Y Marcus E Heilman and S Goldberg ldquoLow-resourceeclipse attacks on ethereumrsquos peer-to-peer networkrdquo IACRCryptology vol 2018 p 236 2018

[53] M Apostolaki A Zohar and L Vanbever ldquoHijacking bitcoinRouting attacks on cryptocurrenciesrdquo in Proceedings of the2017 IEEE Symposium On Security and Privacy (SP)pp 375ndash392 IEEE San Jose CA USA May 2017

[54] M Tran I Choi G J Moon A V Vu and M S Kang ldquoAstealthier partitioning attack against bitcoin peer-to-peernetworkrdquo in Proceedings of the IEEE Symposium On Securityand Privacy (SampP) San Francisco CA USA May 2020

[55] B I Proposal ldquoBip 0152rdquo 2016 httpsenbitcoinitwikiBIP_0152

[56] B Core ldquoBitcoin Core Version 01901 Release Noterdquo 2016httpsbitcoinorgenreleasev01901

[57] ldquoGeth v190rdquo 2019 httpsblogethereumorg20190710geth-v1-9-0

[58] ldquoProtocol documentationrdquo 2016 httpsenbitcoinitwikiProtocoltext_documentation

[59] C Feng and J Niu ldquoSelfish mining in ethereumrdquo in Pro-ceedings of the 2019 IEEE 39th International Conference OnDistributed Computing Systems (ICDCS) pp 1306ndash1316IEEE Dallas TX USA July 2019

[60] G O Karame E Androulaki and S Capkun ldquoDouble-spending fast payments in bitcoinrdquo in Proceedings of the 2012ACM Conference on Computer and Communications Securitypp 906ndash917 Raleigh NC USA October 2012

[61] P Das L Eckey T Frassetto et al ldquoFastkitten practical smartcontracts on bitcoinrdquo in Proceedimgs of the 28th USENIXSecurity Symposium (USENIX Security 19) pp 801ndash818Santa Clara CA USA August 2019

[62] S G Motlagh J Misic and V B Misic ldquoe impact of selfishmining on bitcoin network performancerdquo IEEE Transactionson Network Science and Engineering vol 8 no 1 pp 724ndash7352021

[63] A Muhle A Gruner T Gayvoronskaya and C Meinel ldquoAsurvey on essential components of a self-sovereign identityrdquoComputer Science Review vol 30 pp 80ndash86 2018

[64] M Toorani and C Gehrmann ldquoA decentralized dynamic pkibased on blockchainrdquo in Proceedings Of the 36th Annual ACMSymposium On Applied Computing pp 1646ndash1655 GwangjuKorea March 2021

[65] E foundation ldquoOptimistic-rollupsrdquo 2021 httpsdocsethhubioethereum-roadmaplayer-2-scalingoptimistictext_rollups

[66] ldquoZk-rollupsrdquo 2021 httpsdocsethhubioethereum-roadmaplayer-2-scalingzk-rollups

[67] E foundation ldquoEthereumwire protocolrdquo 2019 httpsgithubcomethereumdevp2pblobmastercapseth

[68] S K Kim Z Ma S Murali J Mason A Miller andM BaileyldquoMeasuring ethereum network peersrdquo in Proceedings of theInternet Measurement Conference 2018 pp 91ndash104 BostonMA USA October 2018

[69] Symmetricom ldquoDelivering sub-microsecond accurate time tolinux applications around the worldrdquo 2012 httpwwwchronoscoukfilespdfswpsWP_AccurateTimeForLinuxApplicationspdf

[70] Ycharts ldquoBlocktrail blockchain data query service (termi-nated)rdquo 2019 httpsblocktrailcom

18 Security and Communication Networks

example the Google cloud platform endeavors to detectcryptocurrency-mining-related activities Once detected theVM instance immediately gets suspended and is reinstatedonly if a reasonable explanation is provided

Furthermore we have noticed a few software crashesVM suspensions by other reasons or temporary lack of diskspace causing loss of measurement data Lastly a majority of

EOS candidate BPs who have provided the peering servicehave gradually stopped their services and only several are leftat the end of our measurement period To eradicate inac-curacy due to the above problems our measurement datasetis trimmed as described in Section 23 Table 4 summarizesour choice of the two anchor blocks and consequent ob-servation period statistics

Table 2 Transaction and block set notation of our measurement framework

Notation Description Definition

Bobse set of blocks observed in the observation

periodbi bi+1 bjminus2 bjminus11113966 1113967 where there is no bk satisfying

arrival(bm)le arrival(bk)le arrival(bi) or arrival(bjminus1)le arrival(bk)le arrival(bn)

Bmaine set of blocks that are included in the

main chainbm+1 bm+2 bnminus1 bn1113864 1113865 where bi prev(bi+1) for all mlt ilt n and bm and bn are

the preamble and concluding blocks respectivelyBstale e set of observed blocks that are stale Bobs minus Bmain

Bunseene set of blocks that are part of the main

chain but not observed Bmain minus Bobs

Tobse set of transactions observed in the

observation periodti ti+1 tjminus2 tjminus11113966 1113967 where there is no tk satisfying

arrival(bm)le arrival(tk)le arrival(ti) or arrival(tjminus1)le arrival(tk)le arrival(bn)

Tpree set of transactions observed before the

observation periodt0 t1 timinus2 timinus11113864 1113865 where there is no tk satisfying

arrival(timinus1)le arrival(tk)le arrival(bm)

Tposte set of transactions observed after the

observation period tj tj+1 1113966 1113967 where there is no tk satisfying arrival(bn)le arrival(tk)le arrival(tj)

Tstalee set of observed transactions that are

stale Tobs minus cupbisinBmain

transactions(b)

Tincludede set of transactions that are observed and

included in the main chain blocks Tobs cap cupbisinBmain

transactions(b)

Tunseene set of transactions that are included inthe main chain blocks but not observed cup

bisinBmain

transactions(b) minus Tpre cupTobs cupTpost

Table 3 Block and transaction functions

Function Descriptionblockhash(b) e hash value of block b

prevhash(b) e previous block hash value of block b

prev(b) e previous block bp of block p ie blockhash(bp) prevhash(b)

height(b) e block height of block b

miner(b) e miner of block b

children(b) e set of child blocks of block b ie height(bc) height(b) + 1forallbc isin children(b)

transactions(b) e set of transactions included in block b

arrival(e) e arrival time of event e where e can be either a block or a transactioninputs(t) e set of transaction inputs (ie vin) of Bitcoin transaction t

outputs(t) e set of transaction outputs (ie vout) of Bitcoin transaction t

nonce(t) e nonce value of Ethereum transaction t

bm bnbm+1

ti ti+1 ti+2 tj-1tj-2 tjtindash1

Time

Transactionarrivals

Blockarrivals

TobsTpre Tpost

bn+1

BobsBpre Bpost

Measurement period

Observation period

bmndash1

Figure 2 Transaction and block analysis model grey-colored events are cropped out for measurement point consistency

4 Security and Communication Networks

32 Measurement Soundness As public blockchain net-works are built on the best-effort serviced overlay network ofP2P connections complete and timed information deliveryis not guaranteed We analyze the completeness of blockarrival events transaction arrival events and their arrivaltime accuracy to underpin the soundness of ourmeasurement

321 Block Coverage Blocks can be part of the main chainor they can be staleWe test our observation against themainchain which is available from a number of block explorerservices to make sure there are no missing blocks

Table 5 shows the observed number of blocks across ourmeasurement points e main chain blocks are all observedwhile stale blocks are partially observed stale blocks beingpartially observed is expected as blockchain nodes are notobliged to propagate stale blocks e stale blocks accountfor only sim004 for Bitcoin and EOS while sim702 of theobserved blocks are stale for Ethereum e stale blockprobability of Bitcoin has been decreasing [21 32] andEthereumrsquos stale block probability is 5 sim 10 larger thanknown uncle rates (calculated only with reported uncles) asour measurement captures unreported stale blocks aswell [33]

322 Transaction Coverage Incomplete transaction mea-surement causes a subset of transactions which are includedin blocks never being observed during measurement Ag-gregating transactions observed from different monitors cancompensate for this incompletenesse unseen transactionsare acquired by subtracting the observed transactions fromthe transactions included in the main chain blocks

Figure 3 shows the probability of unseen transactions(ie n(T

1113954Munseen)n(Tobs)) as a function of the number of

combined measurement points As combining all mea-surement point transaction arrivals results in a convergedfrequency of sim005 for Bitcoin and EOS and sim05 forEthereum it implies that unseen transactions will be stillobserved even if more monitors are deployed to the networkWe further study the unseen transactions in Section 42

323 Timing Accuracy Consider an ordered arrival time-stamp of block b observed at all measurement pointsM tsi|0le ilt n(M)1113864 1113865 arrival(b)m|forallm isinM where tsi lttsj for all ilt jlt n(M) We evaluate the tightness of ourmeasured timing information with Δ(ts0 ts1) and how farthe arrival times can be dispersed among the measurementpoints with Δ(ts0 ts7) where Δ computes the timewisedifference Figure 4 depicts the distribution of the two

Table 4 Observation period statistics

BlockchainPreamble block Concluding block Population

Block height Timestamp Block height Timestamp blocks transactionsBitcoin 587500 2019-07-28 210228 597500 2019-10-02 062237 10004 21454436Ethereum 8290000 2019-08-05 100210 8620000 2019-09-25 192827 353155 36665088EOS 69900000 2019-07-21 210001 75300000 2019-08-22 040804 5402099 144198985

Table 5 Block coverage

RegionBTC ETH EOS

Longest Stale Longest Stale Irreversible StaleAS-East 10000 1 330000 23160 mdash mdashAS-South 10000 3 330000 23160 5400000 2087EU-North 10000 4 330000 23159 5400000 2094EU-West 10000 2 330000 23157 5400000 2087NA-Northeast 10000 3 330000 23160 5400000 2151

US-Central 10000 1 330000 23159 5400000 2085US-East 10000 3 330000 23160 mdash mdashUS-West 10000 4 330000 23155 5400000 2099

Bitcoin (left)Ethereum (right)EOS (left)

0

0002

0004

0006

0008

001

0012

0014

Freq

uenc

y (E

ther

eum

)

2 64 5 81 3 7 of combined measurement points

0

00001

00002

00003

00004

00005

00006

00007

Freq

uenc

y (B

itcoi

n or

EO

S)

Figure 3 Unseen transaction probability distribution

∆(ts0 ts1) Bitcoin

∆(ts0 ts1) Ethereum

∆(ts0 ts1) EOS

∆(ts0 ts7) Bitcoin

∆(ts0 ts7) Ethereum

∆(ts0 ts5) EOS

0

02

04

06

08

1

Cum

ula

tive

freq

uen

cy

1000001 1 10001 100001

Time difference (seconds)

Figure 4 Block arrival time accuracy

Security and Communication Networks 5

variables for all block arrival events It shows that thetimestamps are tight as more than 90 of the blocks arrivedwith a time difference less than 100ms Although Bitcoinblock arrivals can be delayed by another block time interval( sim 10 minutes) sim 80 of the blocks are not dispersed bymore than one second EOS blocks show an order-of-magnitude-smaller dispersion in the worst case e longtails implying that block arrival times can be very prolongedin a small number of cases are commonly observed forBitcoin in the literature [32 34]

Consider an ordered arrival timestamp of transaction t

observed at all measurement points M tsi|0le ilt n(M)1113864 1113865

arrival(t)m|forallm isinM where tsi lt tsj for all ilt jlt n(M)Figure 5 shows the distribution of Δ(ts0 ts1) Δ(ts0 ts3) andΔ(ts0 ts7) for Bitcoin transactions Similar to Bitcoin blocksthe long tail shows that the transaction arrival times can bedispersed more than 5 seconds for 5 of the transactions Inthe meantime Δ(ts0 ts1) is tight as more than 99 of thetwo earliest arrivals are not dispersed more than 1 secondEthereum and EOS transactions exhibit much tighterΔ(ts0 ts1) showing that more than 98 of the transactionarrivals are less than 100 milliseconds apart

4 Block and Transaction Discrepancies

In this section we study the discrepancies in blocks andtransactions between the main chain and our observedevents

41 Blockchain Fork As all main chain blocks are observed(ie Bunseen empty) through our measurement the discrep-ancy in blocks only appears as stale blocks (ie Bstale) Anincident of having stale blocks is also called a blockchain forkwhere one or more blocks are appended to a different branchof the main chain

411 Fork Characteristics and Examples A nonoverlappingblockchain fork episode e at block height [m n) is defined byidentifying two blocks

(i) Fork initiating block bf isin Bmain where height(bf)

m and n(children(bf))gt 1(ii) Fork resolving block br isin Bmain where height(br)

n and children(bi) empty for all bi isin Sn

Sn bi|height(bi) n and bi notin Bmain1113864 1113865 Figure 6(a) il-lustrates our fork episode model

We define three characteristic variables (i) its run lengthrun minus length(e) n minus m (ii) the weight (ie the number ofstale blocks in the episode) weight(e) 1113936

nhm(n(Sh)) and

(iii) the fork degree (ie the maximum number of forkbranches) degree(e) maxmlehlen(n(Sh) + 1) Figure 7 showshow characteristic variables are distributed and our findingsare summarized as follows

(i) Due to its long block time (ie sim10minutes) and lowstale block probability (ie lt 005) statisticalcharacterization of Bitcoin fork episodes suffers froma lack of sample events Even three years of live

measurement yield less than a hundred fork episodesas we only expect to observe less than 30 fork eventsper year

(ii) Ethereum fork episodes mostly run one block heightwith a single additional branch e fork degree (iemaximum of branches) is as high as three for sim5 of the episodes and the forks are not immediatelyresolved that is having two or more run lengths inabout 3 of the cases

EOS fork episodes run as long as 12 blocks that is theentire block schedule of a single BP (block producer) [26] asBPs can override the entire block-producing schedule of thepreceding BP

Putting Bitcoin which produces few fork episodes asideEthereum and EOS exhibit very different fork episodepatterns Figure 8 shows two example fork episodes ofEthereum and EOS We have used the commit graphdrawing tool [35] to visualize the fork episodes Figure 8(a)depicts four fork episodes that is [174 176) [177 178)[183 184) and [185 186) of Ethereum and Figure 8(b)shows two EOS fork episodes that is [290 292) and[294 302)e first fork episode [174 176) of Ethereumexhibits the run length of 3 the weight of 4 and the degree of4 with three nonreported (ie thus available only from ourmeasurement) stale blocks e second fork episode[294 302) of EOS exhibits the run length of 9 the weightof 9 and the degree of 2

412 Nonearliest Advertised Block Endorsement of EthereumMiners Our most interesting finding is that Ethereumminers often do not add blocks to the earliest advertisedblock during fork episodes Consider an illustrative forkepisode depicted in Figure 6(b) e episode begins as thethree blocks (ie b1 b2 and b3) are added to the fork ini-tiating block b0 e immediately following blocks (ie bi

and bj) will have their previous blockhash identifying one ofthe three previous blocks of the minerrsquos choice e block bimined by some miner may be added to the earliest block(ie b1) the other block bj is mined by a different miner whochooses a different block (ie b2) to add to To evaluateminersrsquo preference of blocks to which succeeding blocks areadded in the event of blockchain forks we define theconditional probability of miner ma adding a block to aprevious block mined by mb (by not adding to any of adifferent minerrsquos block) in fork episodes for all ma and mb

Pr miner bi( 1113857( mb|miner bj1113872 1113873

ma

prev bj1113872 1113873 bi

existbk height bk( 1113857 height bi( 1113857)

(1)

Figure 9(a) shows a histogram of the above probabilityma (x-axis) adds a block to mbrsquos block (label) over others infork episodes It is apparent that the top ranked minerssignificantly prefer adding blocks to their own mined blocksover other minersrsquo blocks Figure 9(b) depicts the same

6 Security and Communication Networks

bf

br

m

m + 1

n

n + 1

Height

(a)

Time

Arrival (b1)

Arrival (b2)

Arrival (b3)

b0

b1

b2

b3

bi

bj

(b)

Figure 6 Fork analysis model (a) Fork episode (b) Fork resolve example

EthereumEOS

0

02

04

06

08

1

Cum

ulat

ive f

requ

ency

2 4 6 8 10 120 14

Run length

EthereumEOS

0

02

04

06

08

1

Cum

ulat

ive f

requ

ency

2 4 6 8 10 12 140

Weight

EthereumEOS

0

02

04

06

08

1

Cum

ulat

ive f

requ

ency

40 62

Degree

Figure 7 Fork episode characteristics

∆ (ts0 ts1)∆ (ts0 ts3)∆ (ts0 ts7)

0010203040506070809

1Cu

mul

ativ

e fre

quen

cy(

of t

rans

actio

ns)

2 4 6 8 100Time difference (seconds)

(a)

BitcoinEthereumEOS

1 2 3 4 50Time difference (seconds)

0

02

04

06

08

1

Cum

ulat

ive f

requ

ency

( o

f tra

nsac

tions

)

(b)

Figure 5 Transaction arrival time accuracy (a) Transaction arrival time differences of Bitcoin (b) Δ(ts0 ts1) distribution

Security and Communication Networks 7

(a) (b)

Figure 8 Example fork episodes each dot represents a block followed by block hash (last six hexadecimals) arrival time block height (lastthree digits) block timestamp and its miner Each Ethereum stale block is tagged either R (reported uncle) or NR (not reported) Each EOSblock is tagged with the block sequence (out of 12) of the corresponding BPrsquos production schedule (a) Ethereum (b) EOS

SparkPoolEthermine

F2PoolNanopool

MiningPoolHubzhizhutop

Unconditional SparkPool Ethermine F2Pool Nanopool MiningPoolhub

zhizhutop

0

01

02

03

04

05

Freq

uenc

y

(a)

EarliestMixedNonearliest

Spar

kPoo

lEt

herm

ine

F2Po

olN

anop

ool

Min

ingP

oolH

ubzh

izhu

top

UU

Pool

Pand

aMin

erBT

POO

Lxn

pool

Huo

biM

inin

gPoo

lD

war

fPoo

lfir

epoo

lU

nkno

wn

Min

ing

Expr

ess

BTC

com

Pool

Min

eral

lPoo

lBe

ePoo

lH

iveo

nPoo

l2M

iner

sPPL

NS

2Min

ersS

OLO

Coin

otro

nW

POO

LEz

ilPoo

lpo

olin

o

f tot

al fo

rk re

solv

e

(b)

Figure 9 Ethereum fork resolve statistics (a) Probability of ma (x-axis) adding a block to mbrsquos block (b) Probability of adding to the earliestpropagated block

8 Security and Communication Networks

probability by labeling whether or not the chosen block (byma) is the earliest propagated one e ldquoearliestrdquo label in-dicates that the block to which the newly mined block (byma) is added has been observed as the earliest one to arrivecongruently among all eight measurement locations (Asblock arrival times are measured in eight different locationsthe arrival order can be conflicting e ldquomixedrdquo labelrepresents the conflicting cases) For example the topranked pool SparkPool chose the earliest arriving blocksim55 of the time 3409 out of 6234 blocks among the other2825 blocks that were added to nonearliest previous blocksSparkPoolrsquos own blocks were chosen over others 1211 timeswhile other poolsrsquo blocks were preferred to SparkPoolrsquos only24 times In the meantime Nanopool chose the earliest one amajority of the time For the top 25 ranked mining pools onlyfour of them added blocks to the earliest arriving blocks morethan 90 of the timeis contradicts the earliest propagatedblock endorsement assumption that is broadly adopted inmining-related research [36ndash38]

One possible explanation of the phenomenon is that themining pools adopt their own block preferring strategy as asimple precautionary defense against yet unknown selfishmining pools the profitability of selfish mining largelydepends on the probability of honest pools adding to theattacking poolrsquos branch

413 Cut-Tail Fork Pattern of EOS BPs We find that theEOS fork episodes occur in a way that BPs are cutting the tailof the previous BPrsquos produced blocks EOS adopts the DPoSconsensus mechanism [26] 21 block producers (BPs) areelected by voting and scheduled to produce 12 consecutiveblocks in 6 seconds (ie 500ms for each block) in the al-phabetical order of their names Figure 10 shows thenumbers of switching (by schedule) events and cut-tail forkevents of all immediate BP pairs We observe a high fre-quency of such events when bitfinexeos1 is producing blocksby appending to big onersquos blocks while there are accusationsof BPrsquos dishonest behaviors we believe that the reportedbitfinexrsquos performance problem is the compelling reason forthe phenomenon [39]

42 Unseen and Stale Transactions

421 Private Transaction Mining Unseen transactions arecharacterized by the strong evidence that implies that theunseen transactions are indeed never advertised to the net-work Table 6 categorizes 9587 of Ethereum unseentransactions by using the from addresses of the transactions(We use prefixes followed by ⋆ in presenting hash valueseg address (ie pubkey hash) and txid for brevity Weunderstand this does not entirely anonymize identity as thereaders can verify their results against ours by matching theprefixes) Public names are retrieved from Etherscan [16] Aminer is specified in the table only if all blocks that includethe unseen transactions with the from address are con-gruently mined by that single miner It shows that most ofthe unseen transactions are indeed the block minerrsquos owntransactions

Table 7 shows unseen Bitcoin transactions categorized bythe identified reasons sim 67 of the unseen transactions areeither zero-fee transactions or zero-fee-transaction-dependenttransactionsWe define a transaction t isin transactions(b) as adependent transaction if at least one of input transactions oft is included in the same block b

Bitcoin Core [28] implementation does not propagatetransactions with zero transaction fee Also a dependenttransaction cannot be mempooled until the transaction towhich it is dependent is mempooled consequently it cannotbe relayed to peers e Bitcoin Core mempool imple-mentation justifies the inexistence of zero-fee and zero-fee-dependent transactions from our measurement Existence ofa stale transaction which shares the same transaction inputwith the unseen transaction may imply a possible double-spend attempt a variant [40] involving private mining of ablock with ti while advertising a conflict transaction tj suchthat inputs(ti)cap inputs(tj)neempty we have observed 27 suchunseen transactions without a certainty of attack intentionsor if they are not indeed advertised Lastly multisig trans-action inputs often imply off-chain protocols where signedtransactions are exchanged out-of-band [41] and havingOP_RETURN transaction output implies special purposeprotocols of Bitcoin for example sidechains where theirrelationship with miners require further investigation [42]e presence of unseen transactions by either privatetransaction mining or potential out-of-band delivery oftransactions has a subtle security implication One obviousside effect is privatization of transaction fees the transactionfees of privately mined ones are exclusively obtainable by theprivate miner alone unless the network is fully utilized Ifthe network is fully utilized a miner is forced to include herprivate transactions at the expense of not including othertransactions as the block capacity is limited

422 Conflict Stale Transactions Stale transactions arenetwork-transmitted transactions that are not included inany of the blocks

Table 8 shows the stale transaction counts observed ateach location e stale transactions account for 020369 and 047 of Bitcoin Ethereum and EOS transac-tions respectively Ethereum transactions had an order ofmagnitude more chance of being stale than others

As for public blockchains with transaction fees that isBitcoin and Ethereum stale transactions are mostly at-tributable to conflict Table 9 summarizes the identifiedreasons for transactions being stale A stale Bitcoin trans-action is attributable to conflict if there are one or moretransactions sharing at least one transaction input (ie vin)

An Ethereum transaction is attributable to conflict ifthere is another transaction with the same nonce from thesame account A widely known reason for two or moretransactions being in conflict is transaction replacementsuch as replace-by-fee [43] On the other hand slightly morethan 5 of Bitcoin transactions are stale because at least oneof their transaction inputs is also stale

On the other hand roughly one out of ten staleEthereum transactions is attributable to improper ordering

Security and Communication Networks 9

of nonce (e transaction nonce should be equal to thenumber of transactions sent from the address) nonce is toohigh (983) or too low (002) Last but not least 727 ofstale transactions are not included in blocks because theaccount is not sufficiently funded (An Ethereum accountshould have balance ge value+ gastimes gas price to execute thetransaction [44]) An Ethereum account can be

insufficiently funded when executing a transaction for anumber of reasons [45]

423 EOS Transaction Discrepancy EOS exhibits unseenand stale transactions far different from those of Bitcoin orEthereum that is the PoW blockchains with transaction feeEOS software is not bundled with peer discovery rather thenode operator is required to look up for candidate BPrsquospeering services timely delivery of blockchain data andreliability of the node is dependent on the peering nodes ofchoice (Indeed we have experienced service disruption bydisconnecting from peers for unknown reasons)e notionof being conflict in two or more transactions that is themost frequent reason for transactions being stale for Bitcoinand Ethereum is not applicable to EOS (EOS adopts theaccount model without transaction ordering per accountthus there should be no conflict transaction outputs or thesame account nonce) On the other hand EOS requires

eosh

uobi

pool

-eos

infst

ones

eosfl

ytom

ars-

eosh

uobi

pool

zbeo

sbp1

1111

-atti

clab

eosb

attic

labe

osb-

big

one

hoo

com

-new

dex

bpw

hale

exco

m-z

beos

bp11

111

start

eosio

bp-w

hale

exco

meo

sdot

wik

ibp-

eosfl

ytom

ars

eosc

anno

nchn

-eos

dotw

ikib

pbi

gon

e-bi

tfine

xeos

1eo

sinfst

ones

-eos

iom

eeto

nehe

lloeo

scnb

p-ho

oco

meo

slaom

aoco

m-e

ossv

12eo

ssv

slow

mist

iobp

-sta

rteo

siobp

eoss

v12e

ossv

-hel

loeo

scnb

peo

sbei

jingb

p-eo

scan

nonc

hneo

siosg

1111

1-eo

slaom

aoco

meo

siom

eeto

ne-e

osio

sg11

111

bitfi

nexe

os1-

cert

ikeo

sorg

new

dex

bp-s

low

mist

iobp

coch

ainw

orld

-eos

asia

1111

1bi

tfine

xeos

1-co

chai

nwor

ldce

rtik

eoso

rg-c

ocha

inw

orld

eosa

sia11

111-

eosb

eijin

gbp

new

dex

bp-o

kcap

italb

p1eo

siom

eeto

ne-e

osla

omao

com

okca

pita

lbp1

-slo

wm

istio

bpco

chai

nwor

ld-e

osbe

ijing

bpne

wde

xbp

-sta

rteo

siobp

eosa

sia11

111-

eosc

anno

nchn

eosla

omao

com

-hel

loeo

scnb

pco

chai

nwor

ld-e

osca

nnon

chn

cert

ikeo

sorg

-eos

beiji

ngbp

eoss

v12e

ossv

-hoo

com

bitfi

nexe

os1-

eosa

sia11

111

eosin

fston

es-e

osla

omao

com

okca

pita

lbp1

-sta

rteo

siobp

BP switching (left)Cut-tail (right)

0

5000

10000

15000

20000

25000

BP sw

itchi

ng ev

ents

0

100

200

300

400

500

cu

t-tai

l eve

nts

Figure 10 EOS BP switching and cut-tail events

Table 6 Ethereum unseen transactions

From address Public name Transaction count Miner0xea67⋆ Ethermine 128145 (7242) Ethermine0x2a65⋆ DwarfPool 22955 (1297) DwarfPool0x8fd0⋆ Unknown 11346 (641) SparkPool0x829b⋆ F2Pool 4453 (251) F2Pool0x4c54⋆ HiveonPool 1135 (064) SparkPool0x99c8⋆ BeePool 468 (026) BeePool0xdba7⋆ Unknown 348 (020) UUPool0x464b⋆ FKPool 340 (019) FKPool0xf687⋆ Unknown 217 (012) AntPool0xa801⋆ Unknown 151 (009) AntPool0xbe7c⋆ Unknown 126 (007) AntPool0xb96f⋆ Unknown 101 (006) AntPool

Sum 169785 (9587)

Table 7 Bitcoin unseen transactions

Category Transactioncount

Zero-fee transaction 148 (5068)Zero-fee-transaction-dependent transaction 48 (1644)Multisig transaction input 43 (1473)Conflict with stale transaction 27 (925)OP_RETURN transaction output 26 (890)Sum 292 (10000)

10 Security and Communication Networks

contract users to stake tokens for CPU time that can bededucted by transaction executions A requested transactioncan be rejected thus being stale due to the lack of CPU timeor other resources similarly Replaying the entire statechanges of EOS to find out stale transactions due to lack ofresources is not possible unless all transaction and state logsof the entire BPs are available

On the other hand EOS transactions have two additionalattributes which are not available in the Bitcoin or Ethereumtransaction structures

(i) Reference block every EOS transaction refers to ablock by specifying the block number and hash notonly to prevent replay attacks but also to signal thenetwork that the userrsquos stake is on a specific fork

(ii) Expiration time EOS transactions have explicitexpiration times

If a transactionrsquos reference block is not part of the mainchain at the time of execution the transaction cannot beexecuted (and thus cannot be included in a block) We haveidentified that 18 of stale transactions apply to this case Tofurther identify unknown reasons we consider four timedevents that are relevant to transaction execution

(i) Last irreversible block arrival time arrival(blib) thearrival time of transactionrsquos reference block EOStransactions by default refer to the last irreversibleblock (LIB) [26]

(ii) Head block arrival time arrival(bhead) the scheduledtime of the head block when transaction is arrived

(iii) Transaction arrival time arrival(t) the arrival timeof transaction t

(iv) Expiration time exp(t) the expiration time oftransaction t

e three time differences that is Δexp Δincl and Δtrxare investigated to find characteristics of unseen (Tunseen)and stale (Tstale) transactions over the normal transactions(Tincluded) Figure 11 illustrates the relevant events and timedifferences of them Δexp measures the time difference be-tween the two scheduled (ie virtually timed) events Δincland Δtrx are defined by the arrival events to our monitornode Figure 12 shows the distributions of Δexp Δincl andΔtrx We find that unseen transactions have prolonged Δinclimplying that the delay of newly produced blocks can causenewly generated transactions not promptly delivered be-cause the sync manager is in the Head Catch-Up mode astransactions are only transferred in In-Sync mode by itsdesign [24] Stale transactions with relatively small Δtrx canbe attributable to problematic dApp implementations re-ferring to non-LIB blocks the chain instability caused byblockchain fork mostly due to the cut-tail behavior shown inSection 41 can cause transactions being rejected for im-mature block reference

However we do not find any reason attributable to thetransaction expiration Although the unseen transactionstend to have smallΔexp the expiration times are only as smallas 30 seconds (ie the default expiration time) Particularlyone or more EOS applications set the expiration time to180 seconds (other than the default 30 seconds) and morethan half of the stale transactions are invoked by thoseapplications

While transaction is the smallest unit of execution inBitcoin and Ethereum the unit of contract execution in EOSis action [24] A transaction consists of one or more actionsHowever the constituent actions in a single transactioncannot be separately advertised or executed accordingly weapply the identical transaction model to EOS without loss ofgenerality

5 Block and TransactionArrival Characteristics

51 Arrival Processes All three blockchains we study in thispaper are designed to publish capacity constrained blocks intargeted regular time intervals An incarnation of suchdesign is expected to exhibit a Poisson block arrival processWhile it is claimed that Bitcoin block arrivals do not entirelyexhibit a homogeneous Poisson process due to its difficultadjustment mechanism [46] transaction arrival processes ofblockchains are not studied in the literature to the best of ourknowledge A particularly meaningful step toward under-standing the arrival process of events generated by a complexsystem is examining if the arrival events are independent orexhibiting a correlated structure [47]

e variance-time log-log plots [48] of the block andtransaction arrival event time series are depicted in

Table 8 Stale transactions

Region Bitcoin Ethereum EOSAsia-East 41720 1170706 mdashAsia-South 41653 1194018 504277Europe-North 41693 1192435 470480Europe-West 41668 1123680 450140North America-Northeast 41703 1212210 588711US-Central 41683 1212389 505160US-East 41692 1186488 mdashUS-West 41672 1167627 480207Combined 42023 1351847 672999

Table 9 Identified reasons of stale transactions

Category Transaction count(a) Bitcoin

Conflict 39408 (9378)Stale transaction input 2307 (549)Conflict and stale transaction input 308 (073)Sum 42023 (10000)

(b) EthereumConflict 1208588 (8924)Nonce (skipped) 133161 (983)Nonce (used) 251 (002)Insufficient fund 9847 (727)Sum 1351847 (9982)

(c) EOSFork 12106 (180)Others 660893 (9820)Sum 672999 (10000)

Security and Communication Networks 11

Figure 13(a) As regards the block arrival processes Bitcoinblock arrivals exhibit a linear slope β minus23 e estimatedHurst parameter H 1 + β2 43 implies that the processis not a homogeneous Poisson process but LRD (Long-Range Dependent) contrary to what is expected for a regularinterval event generation [46] Ethereum block arrivalsapproximate the Bitcoinrsquos except for the high aggregationlevel due to high stale block rate EOS block arrivals incontrast follow the slope β minus1 in the low aggregation levelas the block generation is indeed regularly scheduled

Figure 14 shows the variance-time plot of Ethereum andEOS block arrival time series by taking all block arrivalevents (Bobs) and main chain block arrivals only (Bmain) Weconfirm that Ethereum block arrivals indeed exhibit astraight line (close to Bitcoin) if excluding stale blocksHowever EOS block arrivals do not exhibit a straight line

even if we exclude stale blocks due to delayed burst blockarrivals possibly due to cut-tail fork patterns (see Section41)

e transaction arrival processes of all three blockchainsappear to exhibit LRD with Hurst parameter Hgt 56 asβltminus13 To further identify analytical distributions that fitbest the empirical ones the coefficient of variation (σμ) andskewness (ie the standardized third moment) of transac-tion interarrival times are computed for every measurementdataset and compared to the relationships expected for theexponential lognormal Weibull and Gamma distributionsin Figure 13(b) We find that Bitcoin Ethereum and EOStransaction interarrival times are fit best Gamma Weibulland lognormal distribution respectively Individual datasetsare also examined for the fitness of the distribution to findthat the empirical distribution fits the analytical distribution

Virtualclock

Time

Transaction initiator

Time

Blockproducer

Time

Monitornode

Time

Scheduled block time of blib

Scheduled block time of bhead

Scheduled block time of bincl

1 Produce and propagate blib

2 Produce and propagate bhead

Expiration time of t

4 Produce and propagate bincl

Δexp

Δtrx

Δincl

3 Create and propagate t

Figure 11 EOS transaction analysis model

Tincluded

Tstale

Tunseen

0010203040506070809

1

Cum

ulat

ive f

requ

ency

100 200 300 400 5000Time difference (seconds)

(a)

Tincluded

Tunseen

01 1 10 100 1000001Time difference (seconds)

0010203040506070809

1

Cum

ulat

ive f

requ

ency

(b)

Tincluded

Tstale

0010203040506070809

1

Cum

ulat

ive f

requ

ency

01 1 10 100 1000001Time difference (seconds)

(c)

Figure 12 EOS transaction timing analysis (a) Δexp (b) Δincl (c) Δtrx

12 Security and Communication Networks

well except for the small interarrival time ranges For ex-ample Figure 15 depicts the CDF of Ethereum transactioninterarrival times observed in US-West Although the em-pirical distribution fits Weibull with parameters computedwith the maximum likelihood estimator [49] sample pointsunder several milliseconds appear to be unreliable (We areyet unaware of the reason However it is known that thetime source of commodity operating systems is not accurateand we need an external time source for accurate sub-millisecond timing measurement [50])

52AdvertisementRedundancy Bitcoin and Ethereum nodepieces of software are implemented to maintain a large

number of peer connections with multiple random remotenodes Bitcoin Core can connect up to 125 peers where 8 ofthem are outbound connections Go Ethereum maintains 50peer connections where 16 of them are outbound by default(see Table 1) On the other hand partitioning attacks aredeveloped to isolate a blockchain node from the others bytampering with all such peer connections Partitioning at-tacks usually exploit vulnerable peer management mecha-nisms of Bitcoin [51] and Ethereum [52] Such attacks arealso examined in the context of ISPrsquos BGP hijacking [53] anda stealthier variant relieving the attacker from the risk ofgetting exposed [54] e attacks often rely on imple-mentation vulnerabilities for efficient eclipsing of peerswhile known vulnerabilities are getting addressed for ex-ample the lack of parallel block download sessions causing

Slope = ndash1

Trx BitcoinTrx EthereumTrx EOS

Blk BitcoinBlk EthereumBlk EOS

ndash12

ndash10

ndash8

ndash6

ndash4

ndash2

0Lo

g no

rmal

ized

var

ianc

e

124 6 10 140 2 8Aggregation level

(a)

Lognormal

Weibull

Gamma

Exponential

BitcoinEthereumEOS

0

5

10

15

20

Stan

dard

ized

third

mom

ent

1 2 3 40Coefficient of variation

(b)

Figure 13 Transaction arrival characteristics (a) Variance-time plot of block and transaction arrivals (b) Cov versus skewness oftransaction interarrival times

Ethereum - Bobs

Ethereum - Bmain

EOS - Bobs

EOS - Bmain

ndash12

ndash10

ndash8

ndash6

ndash4

ndash2

0

Log

norm

aliz

ed v

aria

nce

2 4 6 8 10 12 140Aggregation level

Figure 14 Variance-time plot of block arrivals including staleblocks (Bobs) and excluding stale blocks (Bmain)

EmpiricalExponential μ = 0024

Lognormal μ = 00354 σ2 = 00486Pareto k = 0000212 a = 0231Weibull c = 0589 a = 00147

00001 0001 001 01 1000001Time (seconds)

0

02

04

06

08

1

Cum

ulat

ive f

requ

ency

Figure 15 Empirical and fitted analytical distributions of Ether-eum transaction interarrival times

Security and Communication Networks 13

temporary denial of blocks (reported in [27] and fixed byrecommending three concurrent download sessions in [55])let attackers successfully partition the node without eclipsingall peer connections [53] A simple countermeasure of in-creasing the number of peer connections on the other handis applied to the reference public blockchain implementa-tions [56 57] to inflate attack complexity

We investigate the degree of a peerrsquos advertisementredundancy on newly generated blocks and transactions toevaluate the efficacy of partitioning attacks and the coun-termeasure of increasing the number of peer connectionsFigure 16 shows how redundantly newly generated blockinformation is offered by peers Bitcoin nodes have main-tained sim43 peer connections that is 8 outbound and ad-ditional 35 inbound connections on average and Ethereumnodes record all 50 peer connections established during theentire observation period

For each newly generated block one-third of peersadvertised the block header to our Bitcoin node and morethan 90 of Ethereum peers signaled availability of theblocks In consequence successfully partitioning a noderequires compromise of peers proportional to the totalnumber of peer connections Increasing the number of peerconnections will burden the attacker linearly as expected

Figure 17 shows how redundantly the newly generatedtransaction information is offered by peers While one out ofthree Bitcoin peers also advertises new transactions viaINVENTORYmessage [58] half of the Ethereum peers havesent new transactions to our node in average Bitcoin andEthereum blocks are advertised with the block header(rather than the direct delivery of all block contents) Bitcointransactions are also advertised with INVENTORY messagebefore the whole contents are transferred HoweverEthereum transaction data that is the entire contents aredirectly sent by peers (Ethereum now has a pooled trans-action delivery model in its newer ETH64 protocol [30])We also find that there are cases with much less advertisedtransactions and have identified that they are indeed mostlystale ones stale transactions are mostly due to conflict (seeSection 42) and the nodes that already queued the conflicttransaction will not relay the stale one

6 Discussion

61 Implication on Mining Attacks Cryptocurrency mininghas been a popular subject in assessing the security ofBitcoin selfish mining [37] block withholding attack [36]and a mixed strategy [38] have been studied Although it isshown that selfish behavior in mining is always moreprofitable than being honest without need for a mutualagreement of not attacking each other [38] we find thatselfish mining is not the preferred strategy All selfish miningstrategies will result in blockchain forks but we observe avery low fork probability (ie 004) for Bitcoin On theother hand selfish mining on Ethereum has been studiedonly recently to unanimously claim that selfish mining isalso profitable for Ethereum miners however it is lessprofitable than Bitcoin due to its uncle reward system [59]Our result in Section 4 shows that a majority of Ethereum

miners choose to add to their own produced blocks over theearliest propagated blocks How does this affect the selfishmining strategy

e selfish mining strategy assumes a parameter c whichdefines the fraction of honest minersrsquo mines on the attackerrsquosfork branch (e parameter comes into play in case (f ) of[27]) If the attacking pool has a network-wise superiorposition in block propagation (ie cgt 05) the selfishmining strategy is profitable for pools with proportionalmining power αgt 25 [37] Absolute network inferiority(ie c 0 due to a defensive mining strategy such as the onepresented in Section 41) increases the required miningpower to 33 the 33 mining power appears to be sig-nificantly harder to achieve in the real world [20]

As for the FAW (Fork-After-Withholding) attackstrategy [38] the network capability parameter C defines theprobability that an attackerrsquos FPoW (Full Proof-of-Work)block (during infiltration mining) is selected as a main chainblock C affects both the attack reward and whether theminerrsquos dilemma holds or not in the mutual attacking gameAs an example case (Section 9 of [38]) of a two-pool gamebetween F2Pool and BitFury the absolute network inferi-ority drops C from 0914 to 03 to make it a dilemmatic gameagain Unfortunately minersrsquo own block preferences cannotbe directly transferred to a single parameter of c or C it callsfor a model change from previous mining studies

62 Conflict Transactions and Double-Spending AttacksDouble-spending attacks have been studied in the context ofBitcoin fast payments where zero or only one confirmation isrequired to complete an offline merchandise transaction[60] real-world cases where two conflict transactions dis-parately arrive at different measurement locations mayimply such attacks Table 10 shows the cases where twotransactions are in conflict (and thus only one of themis included in a block ie inputs(ti)cap inputs(ts)neemptyand existb isin Bmain ti isin transactions(b) (∄b isin Bmain ts isintransactions(b) is indisputable given a consistent transactionledger)) and two different subsets of the monitors havemempooled either one of them We also have identified 27unseen transactions implying possible one-confirmationattack variant requiring the private mining (ie not ad-vertising the double-spending transaction to the network) in

5 10 15 20 25 30 35 40 45 500 of peers

0

005

01

015

02

025

Freq

uenc

y

BitcoinEthereum

Figure 16 Peer redundancy of block advertisement

14 Security and Communication Networks

Section 42 As for the countermeasure of such attacks bydeploying monitors [60] deployment of 8 monitors in thenetwork to detect the attacks would fail at most 27 out of 95times (sim30) assuming that those 27 unseen transactionswe have identified are initially advertised to the network

63 Potential Impact on Blockchain ApplicationsEthereum and EOS are the most widely used smart contractplatforms fostering various decentralized applications Bit-coin which lacks the capability of executing complex smartcontract codes is also recently utilized to execute smartcontracts for decentralized applications [50 61] Eventhough our work focuses on the fundamental blockchainmechanisms in terms of transactionblock production andpropagation the impact of our findings on decentralizedapplications can be foresighted

According to our blockchain fork results (Section 41)the lack of selfish mining in the real world was speculated bya very low stale block rate of Bitcoin network and prevalenceof nonearliest block endorsement by Ethereum miners Asprofitability of selfish mining encourages miners to behavein a way of producing more blockchain forks the perfor-mance degradation is proportionate to the number of minerswho adopt the selfish mining strategy the key performancemetrics affecting the blockchain application performance

such as node response time or block delivery time are shownto be noticeably degraded due to the selfish mining [62] Forexample decentralized identities issued or revoked on suchblockchains [63 64] cannot be responsively finalized due toinflated blockchain forks Our results show that the selfishmining is not prevalent in the real world thus the appli-cation performance impact is overrated even though it istheoretically shown that miners have every reason to beselfish [38] As for EOS we reported cases where a sequenceof (up to 12) blocks being stale are often observed in suc-cessive mining of two BPs however the rate is too low (ie004) to impact the performance of applications (Section32)

Transaction arrival processes being LRD (Section 51)pose a technical challenge in provisioning transactionprocessing scalability especially for Layer-2 blockchain ap-plication solutions [65 66] For example Layer-2 rollupsolutions require transaction relays which aggregate indi-vidual user transactions of a given blockchain applicationdeployed in the network often without a priori knowledge ofnetwork load One way of solving the problem is a properprioritization of transactions based on the applicationcontext

Lastly blockchain network partitioning can be thebiggest concern for blockchain service providers We ob-served that the increased numbers of peer connections inblockchain reference implementations effectively provide ahigher degree of information redundancy (Section 52)However increased number of peer connections can beexploitable for an attacker who has a denial-of-service attackvector or an invalid transaction initiated by a simple ap-plication bug can flood the network [45]

64 Limitation Our measurement study has several limi-tations First of all our results may only capture only a fewmonths of blockchain network operations In the meantimethe permissionless blockchain pieces of software are in activedevelopment for example Ethereum now utilizes the pooledtransaction delivery [67] instead of unsolicited transactiondelivery which was the only mode at the time of our

Table 10 Bitcoin disparately mempooled transactions

monitors mempooledti

monitors mempooledts

Transactioncount

7 1 26 (3824)6 2 14 (2059)5 3 10 (1471)4 4 5 (735)3 5 5 (735)2 6 3 (441)1 7 3 (441)5 1 1 (147)6 1 1 (147)

Sum 68 (10000)

Tincluded

Tstale

5 10 15 20 25 30 35 40 45 500 of peers

0

005

01

015

02

025

03Fr

eque

ncy

(a)

Tincluded

Tstale

0002004006008

01012014016

Freq

uenc

y

4030 500 10 20 of peers

(b)

Figure 17 Peer redundancy of transaction advertisement (a) Bitcoin (b) Ethereum

Security and Communication Networks 15

measurement Both cryptocurrency market values andblockchain network utilizations are rapidly increasing andthus miners are getting more motivated to optimize theirperformance for example Bitcoin fork probability has be-come far smaller than what is reported previously (seeSection 41)

Second the blockchain state information is not collected inour measurement Our analysis is performed based on onlyavailable information stored in block and transaction logs Wehave utilized an Ethereum archive node [44] to query historicalstate information (eg account balance or account nonce) inSection 42 However such proactive state replication is farmore complicated with EOS unless the full node is configuredto operate as a producing node and logging the state infor-mation thus EOS stale transactions could not be fully un-derstood without the missing EOS network state information

7 Related Work

71 Blockchain Data Analysis Historical transaction data ofBitcoin have often been studied for economic aspects such ascryptocurrency abuse [17] anti-money-laundering [18] andmonetary flow of businesses [19] However historicalblockchain data usually available from block explorer ser-vices are not sufficient for our research purpose

72 Blockchain Measurement Researchers have performedblockchain measurement studies to assess the degree ofdecentralization [20] to investigate demographic informa-tion of network nodes [34 68] to study mining pool be-havior [22] and to evaluate security of PoW blockchains [21]against known attacks such as double-spending attack [60]and selfish mining [37] Our work expands the under-standing of previous security evaluations with the keyfindings acquired from our large-scale transaction and blockmeasurement

73 Blockchain Attacks Partitioning attacks usually exploitvulnerable peer management mechanisms of Bitcoin [51]and Ethereum [52] Such attacks are also examined in thecontext of ISPrsquos BGP hijacking [53] and a stealthier variantrelieving the attacker from the risk of getting exposed [54]Cryptocurrency mining has been a popular subject inassessing the security of Bitcoin selfish mining [37] blockwithholding attack [36] and a mixed strategy [38] have beenstudied Double-spending attacks have been studied in thecontext of Bitcoin fast payments [60]

74 Block Explorer Services We have surveyed the popularblock explorer services of Bitcoin [5 10 12] Ethereum[10 13 16] and EOS [11 14 15] to see the availability ofinformation beyond what is recorded in the main chainblock data we have utilized in our study namely

(i) Stale blockstransactions no Bitcoin and EOS blockexplorers provide stale block information (A relatedstudy [36] has utilized a Bitcoin block explorer service[68] to retrieve stale blocks However the service has

been terminated in March 2019) All Ethereum blockexplorers provide only reported stale blocks (ie uncleblocks [23]) (Ethereum provides incentives for unclestale blocks [44] so that miners include them in theirmined blocks for profit)No block explorers provide stale transaction infor-mation unless one is currently pooled

(ii) Blocktransaction arrival times all block explorersprovide block timestamps that are recorded in theblock headers not the actual times of arrival Ourblockchain fork and gap analysis require measuredblock arrival times at multiple locations All blockexplorers show transaction timestamps identical to theblock timestamp to which the transactions belong(Recent Bitcoin transactions have different timestampsthan the block timestamps in [4] while the timestampsare only at a granularity of one minute) [69 70]

8 Conclusion

We have measured transaction and block arrival events ofthe three permissionless blockchains We have devised anoble analysis model and analyzed completeness of ourblock and transaction logs Finally we have studied thediscrepancy in measured events and arrival characteristics toshare our key findings including a false universal assumptionof previous mining-related studies

Data Availability

e measurement data used to support the findings of thisstudy have not been made available because they containprivate information that can be used to identify individualblockchain nodes

Disclosure

is is an extended and revised version of a conference paperpresented in IEEE ICDCS 2021 [41]

Conflicts of Interest

e authors declare that they have no conflicts of interest

Acknowledgments

e authors would like to thank Seungwon Woo DaegeunYoon and Changhyun Lee for helping them with themeasurement instrumentation is work was supported byElectronics and Telecommunications Research Institute(ETRI) grant funded by the Korean Government (21ZR1300Research on Intelligent Cyber Security and Trust Infra)

References

[1] S Nakamoto ldquoBitcoin a peer-to-peer electronic cash systemrdquo2019

[2] V Buterin ldquoEthereum white paperrdquo 2013 httpsethereumorgenwhitepaper

[3] Monero ldquoMonerordquo 2020 httpswebgetmoneroorg

16 Security and Communication Networks

[4] bitcoincashorg httpswwwbitcoincashorg[5] Blockchaincom httpswwwblockchaincom[6] Ripple ldquoXRP e best digital asset for global paymentsrdquo

2020 httpsripplecomxrp[7] I Foundation ldquoIotardquo 2021 httpswwwiotaorg[8] ldquoEosiordquo 2020 httpseosio[9] S Orsquoneal ldquoEos proves yet again that decentralization is not its

priorityrdquo 2018 httpscointelegraphcomnewseos-proves-yet-again-that-decentralization-is-not-its-priority

[10] Blockchair httpsblockchaircom[11] Bloksio httpsbloksio[12] BTCcom ldquoBitcoin block explorerrdquo 2021 httpsbtccom[13] Ethereum block explorer httpsethbtccom[14] eosflareio Eos block explorer httpseosflareio[15] EOSPark ldquoEos block explorerrdquo 2021 httpseosparkcom[16] Etherscan Ethereum explorer httpsetherscanio[17] S Lee C Yoon and H Kang ldquoCybercriminal minds An

investigative study of cryptocurrency abuses in the dark webrdquoin Proceedings of the Network and Distributed System SecuritySymposium pp 1ndash15 Internet Society San Diego CA USAFebruary 2019

[18] MMoser R Bohme and D Breuker ldquoAn inquiry into moneylaundering tools in the bitcoin ecosystemrdquo in Proceedings ofthe 2013 APWG eCrime Researchers summit pp 1ndash14 IEEESan Francisco CA USA September 2013

[19] M Lischke and B Fabian ldquoAnalyzing the bitcoin network thefirst four yearsrdquo Future Internet vol 8 no 1 2016

[20] A E Gencer S Basu I Eyal R V Renesse and E G SirerldquoDecentralization in bitcoin and ethereum networksrdquo inProceedings of the International Conference On FinancialCryptography and Data Security pp 439ndash457 SpringerNieuwport Curaccedilao February 2018

[21] A Gervais G O Karame KWust V Glykantzis H Ritzdorfand S Capkun ldquoOn the security and performance of proof ofwork blockchainsrdquo in Proceedings Of the 2016 ACM SIGSACConference on Computer and Communications Securitypp 3ndash16 Vienna Austria October 2016

[22] C Wang X Chu and Q Yang ldquoMeasurement and analysis ofthe bitcoin networks a view from mining poolsrdquo 2019httpsarxivorgabs190207549

[23] G Wood ldquoEthereum A secure decentralised generalisedtransaction ledgerrdquo Ethereum Project Yellow Paper vol 1512014

[24] ldquoTransactions protocol eosio developer docsrdquo 2018 httpsdeveloperseosiowelcomev20protocoltransactions_protocol

[25] Y Sompolinsky and A Zohar ldquoSecure high-rate transactionprocessing in bitcoinrdquo in Proceedings of the InternationalConference On Financial Cryptography and Data Securitypp 507ndash527 Springer San Juan PR USA January 2015

[26] Blockone ldquoConsensus protocolrdquo 2018 httpsdeveloperseosiowelcomev20protocolconsensus_protocol

[27] A Gervais H Ritzdorf G O Karame and S CapkunldquoTampering with the delivery of blocks and transactions inbitcoinrdquo in Proceedings Of the 22nd ACM SIGSAC ConferenceOn Computer and Communications Security pp 692ndash705Denver CO USA October 2015

[28] ldquoGithub Bit coinrdquo 2020 httpsgithubcombitcoinbitcoin[29] G Ethereum ldquoGo ethereumrdquo 2020 httpsgithubcom

ethereumgo-ethereum[30] Google ldquoGoogle cloudrdquo 2021 httpscloudgooglecom[31] ldquoHow to replay from a snapshotrdquo 2018 httpsdeveloperseos

iomanualseoslatestnodeosreplayshow-to-replay-from-a-snapshot

[32] C Decker and R Wattenhofer ldquoInformation propagation inthe bitcoin networkrdquo in Proceedings of the IEEE P2P 2013Proceedings pp 1ndash10 IEEE Trento Italy September 2013

[33] ldquoEthereum uncle raterdquo 2020 httpsychartscomindicatorsethereum_uncle_rate

[34] J A Donet C P Sola and J H Joancomartı ldquoe bitcoin p2pnetworkrdquo in Proceedings of the International Conference OnFinancial Cryptography and Data Security pp 87ndash102Springer Christ Church Barbados March 2014

[35] G S Davies ldquoBit-booster - offline commit graph drawingtoolrdquo 2016 httpbit-boostercomgraphhtml

[36] N T Courtois and L Bahack ldquoOn subversive miner strategiesand block withholding attack in bitcoin digital currencyrdquo2014 httpsarxivorgabs14021718

[37] I Eyal and E G Sirer ldquoMajority is not enough bitcoin miningis vulnerablerdquo in Proceedings of the International Conferenceon Financial Cryptography and Data Security pp 436ndash454Springer Christ Church Barbados March 2014

[38] Y Kwon D Kim Y Son E Vasserman and Y Kim ldquoBeselfish and avoid dilemmas fork after withholding (faw) at-tacks on bitcoinrdquo in Proceedings Of the 2017 ACM SIGSACConference On Computer and Communications Securitypp 195ndash209 Abu Dhabi UAE April 2017

[39] B Research ldquoDecentralisation governance and eos - a lostcaserdquo 2020 httpsresearchbinancecomenanalysiseos-governance

[40] B Wiki ldquoIrreversible transactions - finney attackrdquo 2012httpsenbitcoinitwikiIrreversible_Transactions∖Finney_attack

[41] J Poon and T Dryja ldquoe bitcoin lightning network scalableoff-chain instant paymentsrdquo 2016

[42] M Bartoletti and L Pompianu ldquoAn analysis of bitcoin op_return metadatardquo in Proceedings of the International Con-ference On Financial Cryptography and Data Securitypp 218ndash230 Springer Sliema Malta April 2017

[43] ldquoReplace by feerdquo 2018 httpsenbitcoinitwikiReplace_by_fee

[44] E Foundation ldquoNode and clientsrdquo 2020 httpsethereumorgendevelopersdocsnodes-and-clients

[45] H Heo and S Shin ldquoBehind block explorers public block-chain measurement and security implicationrdquo in Proceedingsof the 41th IEEE International Conference On DistributedComputing Systems IEEE Washington DC USA In pressWashington DC USA July 2021

[46] R Bowden H P Keeler A E Krzesinski and P G TaylorldquoBlock arrivals in the bitcoin blockchainrdquo 2018 httpsarxivorgabs180107447

[47] M E Crovella and A Bestavros ldquoExplaining world wide webtraffic self-similarityrdquo Technical Report Citeseer PrincetonNJ USA 1995

[48] H Zhang Y Shu and O Yang ldquoEstimation of hurst pa-rameter by variance-time plotsrdquo in Proceedings of the 1997IEEE Pacific Rim Conference on Communications Computersand Signal Processing PACRIM 10 Years Networkingthe Pacific Rim 1987-1997 IEEE Victoria BC CanadaAugust 1997

[49] A Feldmann ldquoCharacteristics of TCP connection arrivalsrdquo inSelf-Similar Network Traffic and Performance EvaluationK Park andWWillinger Eds pp 367ndash399Wiley HobokenNJ USA 2000

[50] RSK ldquoRSKrdquo 2021 httpswwwrskco[51] E Heilman A Kendler A Zohar and S Goldberg ldquoEclipse

attacks on bitcoinrsquos peer-to-peer networkrdquo in Proceedings of

Security and Communication Networks 17

the 24th USENIX Security Symposium pp 129ndash144 Wash-ington DC USA April 2015

[52] Y Marcus E Heilman and S Goldberg ldquoLow-resourceeclipse attacks on ethereumrsquos peer-to-peer networkrdquo IACRCryptology vol 2018 p 236 2018

[53] M Apostolaki A Zohar and L Vanbever ldquoHijacking bitcoinRouting attacks on cryptocurrenciesrdquo in Proceedings of the2017 IEEE Symposium On Security and Privacy (SP)pp 375ndash392 IEEE San Jose CA USA May 2017

[54] M Tran I Choi G J Moon A V Vu and M S Kang ldquoAstealthier partitioning attack against bitcoin peer-to-peernetworkrdquo in Proceedings of the IEEE Symposium On Securityand Privacy (SampP) San Francisco CA USA May 2020

[55] B I Proposal ldquoBip 0152rdquo 2016 httpsenbitcoinitwikiBIP_0152

[56] B Core ldquoBitcoin Core Version 01901 Release Noterdquo 2016httpsbitcoinorgenreleasev01901

[57] ldquoGeth v190rdquo 2019 httpsblogethereumorg20190710geth-v1-9-0

[58] ldquoProtocol documentationrdquo 2016 httpsenbitcoinitwikiProtocoltext_documentation

[59] C Feng and J Niu ldquoSelfish mining in ethereumrdquo in Pro-ceedings of the 2019 IEEE 39th International Conference OnDistributed Computing Systems (ICDCS) pp 1306ndash1316IEEE Dallas TX USA July 2019

[60] G O Karame E Androulaki and S Capkun ldquoDouble-spending fast payments in bitcoinrdquo in Proceedings of the 2012ACM Conference on Computer and Communications Securitypp 906ndash917 Raleigh NC USA October 2012

[61] P Das L Eckey T Frassetto et al ldquoFastkitten practical smartcontracts on bitcoinrdquo in Proceedimgs of the 28th USENIXSecurity Symposium (USENIX Security 19) pp 801ndash818Santa Clara CA USA August 2019

[62] S G Motlagh J Misic and V B Misic ldquoe impact of selfishmining on bitcoin network performancerdquo IEEE Transactionson Network Science and Engineering vol 8 no 1 pp 724ndash7352021

[63] A Muhle A Gruner T Gayvoronskaya and C Meinel ldquoAsurvey on essential components of a self-sovereign identityrdquoComputer Science Review vol 30 pp 80ndash86 2018

[64] M Toorani and C Gehrmann ldquoA decentralized dynamic pkibased on blockchainrdquo in Proceedings Of the 36th Annual ACMSymposium On Applied Computing pp 1646ndash1655 GwangjuKorea March 2021

[65] E foundation ldquoOptimistic-rollupsrdquo 2021 httpsdocsethhubioethereum-roadmaplayer-2-scalingoptimistictext_rollups

[66] ldquoZk-rollupsrdquo 2021 httpsdocsethhubioethereum-roadmaplayer-2-scalingzk-rollups

[67] E foundation ldquoEthereumwire protocolrdquo 2019 httpsgithubcomethereumdevp2pblobmastercapseth

[68] S K Kim Z Ma S Murali J Mason A Miller andM BaileyldquoMeasuring ethereum network peersrdquo in Proceedings of theInternet Measurement Conference 2018 pp 91ndash104 BostonMA USA October 2018

[69] Symmetricom ldquoDelivering sub-microsecond accurate time tolinux applications around the worldrdquo 2012 httpwwwchronoscoukfilespdfswpsWP_AccurateTimeForLinuxApplicationspdf

[70] Ycharts ldquoBlocktrail blockchain data query service (termi-nated)rdquo 2019 httpsblocktrailcom

18 Security and Communication Networks

32 Measurement Soundness As public blockchain net-works are built on the best-effort serviced overlay network ofP2P connections complete and timed information deliveryis not guaranteed We analyze the completeness of blockarrival events transaction arrival events and their arrivaltime accuracy to underpin the soundness of ourmeasurement

321 Block Coverage Blocks can be part of the main chainor they can be staleWe test our observation against themainchain which is available from a number of block explorerservices to make sure there are no missing blocks

Table 5 shows the observed number of blocks across ourmeasurement points e main chain blocks are all observedwhile stale blocks are partially observed stale blocks beingpartially observed is expected as blockchain nodes are notobliged to propagate stale blocks e stale blocks accountfor only sim004 for Bitcoin and EOS while sim702 of theobserved blocks are stale for Ethereum e stale blockprobability of Bitcoin has been decreasing [21 32] andEthereumrsquos stale block probability is 5 sim 10 larger thanknown uncle rates (calculated only with reported uncles) asour measurement captures unreported stale blocks aswell [33]

322 Transaction Coverage Incomplete transaction mea-surement causes a subset of transactions which are includedin blocks never being observed during measurement Ag-gregating transactions observed from different monitors cancompensate for this incompletenesse unseen transactionsare acquired by subtracting the observed transactions fromthe transactions included in the main chain blocks

Figure 3 shows the probability of unseen transactions(ie n(T

1113954Munseen)n(Tobs)) as a function of the number of

combined measurement points As combining all mea-surement point transaction arrivals results in a convergedfrequency of sim005 for Bitcoin and EOS and sim05 forEthereum it implies that unseen transactions will be stillobserved even if more monitors are deployed to the networkWe further study the unseen transactions in Section 42

323 Timing Accuracy Consider an ordered arrival time-stamp of block b observed at all measurement pointsM tsi|0le ilt n(M)1113864 1113865 arrival(b)m|forallm isinM where tsi lttsj for all ilt jlt n(M) We evaluate the tightness of ourmeasured timing information with Δ(ts0 ts1) and how farthe arrival times can be dispersed among the measurementpoints with Δ(ts0 ts7) where Δ computes the timewisedifference Figure 4 depicts the distribution of the two

Table 4 Observation period statistics

BlockchainPreamble block Concluding block Population

Block height Timestamp Block height Timestamp blocks transactionsBitcoin 587500 2019-07-28 210228 597500 2019-10-02 062237 10004 21454436Ethereum 8290000 2019-08-05 100210 8620000 2019-09-25 192827 353155 36665088EOS 69900000 2019-07-21 210001 75300000 2019-08-22 040804 5402099 144198985

Table 5 Block coverage

RegionBTC ETH EOS

Longest Stale Longest Stale Irreversible StaleAS-East 10000 1 330000 23160 mdash mdashAS-South 10000 3 330000 23160 5400000 2087EU-North 10000 4 330000 23159 5400000 2094EU-West 10000 2 330000 23157 5400000 2087NA-Northeast 10000 3 330000 23160 5400000 2151

US-Central 10000 1 330000 23159 5400000 2085US-East 10000 3 330000 23160 mdash mdashUS-West 10000 4 330000 23155 5400000 2099

Bitcoin (left)Ethereum (right)EOS (left)

0

0002

0004

0006

0008

001

0012

0014

Freq

uenc

y (E

ther

eum

)

2 64 5 81 3 7 of combined measurement points

0

00001

00002

00003

00004

00005

00006

00007

Freq

uenc

y (B

itcoi

n or

EO

S)

Figure 3 Unseen transaction probability distribution

∆(ts0 ts1) Bitcoin

∆(ts0 ts1) Ethereum

∆(ts0 ts1) EOS

∆(ts0 ts7) Bitcoin

∆(ts0 ts7) Ethereum

∆(ts0 ts5) EOS

0

02

04

06

08

1

Cum

ula

tive

freq

uen

cy

1000001 1 10001 100001

Time difference (seconds)

Figure 4 Block arrival time accuracy

Security and Communication Networks 5

variables for all block arrival events It shows that thetimestamps are tight as more than 90 of the blocks arrivedwith a time difference less than 100ms Although Bitcoinblock arrivals can be delayed by another block time interval( sim 10 minutes) sim 80 of the blocks are not dispersed bymore than one second EOS blocks show an order-of-magnitude-smaller dispersion in the worst case e longtails implying that block arrival times can be very prolongedin a small number of cases are commonly observed forBitcoin in the literature [32 34]

Consider an ordered arrival timestamp of transaction t

observed at all measurement points M tsi|0le ilt n(M)1113864 1113865

arrival(t)m|forallm isinM where tsi lt tsj for all ilt jlt n(M)Figure 5 shows the distribution of Δ(ts0 ts1) Δ(ts0 ts3) andΔ(ts0 ts7) for Bitcoin transactions Similar to Bitcoin blocksthe long tail shows that the transaction arrival times can bedispersed more than 5 seconds for 5 of the transactions Inthe meantime Δ(ts0 ts1) is tight as more than 99 of thetwo earliest arrivals are not dispersed more than 1 secondEthereum and EOS transactions exhibit much tighterΔ(ts0 ts1) showing that more than 98 of the transactionarrivals are less than 100 milliseconds apart

4 Block and Transaction Discrepancies

In this section we study the discrepancies in blocks andtransactions between the main chain and our observedevents

41 Blockchain Fork As all main chain blocks are observed(ie Bunseen empty) through our measurement the discrep-ancy in blocks only appears as stale blocks (ie Bstale) Anincident of having stale blocks is also called a blockchain forkwhere one or more blocks are appended to a different branchof the main chain

411 Fork Characteristics and Examples A nonoverlappingblockchain fork episode e at block height [m n) is defined byidentifying two blocks

(i) Fork initiating block bf isin Bmain where height(bf)

m and n(children(bf))gt 1(ii) Fork resolving block br isin Bmain where height(br)

n and children(bi) empty for all bi isin Sn

Sn bi|height(bi) n and bi notin Bmain1113864 1113865 Figure 6(a) il-lustrates our fork episode model

We define three characteristic variables (i) its run lengthrun minus length(e) n minus m (ii) the weight (ie the number ofstale blocks in the episode) weight(e) 1113936

nhm(n(Sh)) and

(iii) the fork degree (ie the maximum number of forkbranches) degree(e) maxmlehlen(n(Sh) + 1) Figure 7 showshow characteristic variables are distributed and our findingsare summarized as follows

(i) Due to its long block time (ie sim10minutes) and lowstale block probability (ie lt 005) statisticalcharacterization of Bitcoin fork episodes suffers froma lack of sample events Even three years of live

measurement yield less than a hundred fork episodesas we only expect to observe less than 30 fork eventsper year

(ii) Ethereum fork episodes mostly run one block heightwith a single additional branch e fork degree (iemaximum of branches) is as high as three for sim5 of the episodes and the forks are not immediatelyresolved that is having two or more run lengths inabout 3 of the cases

EOS fork episodes run as long as 12 blocks that is theentire block schedule of a single BP (block producer) [26] asBPs can override the entire block-producing schedule of thepreceding BP

Putting Bitcoin which produces few fork episodes asideEthereum and EOS exhibit very different fork episodepatterns Figure 8 shows two example fork episodes ofEthereum and EOS We have used the commit graphdrawing tool [35] to visualize the fork episodes Figure 8(a)depicts four fork episodes that is [174 176) [177 178)[183 184) and [185 186) of Ethereum and Figure 8(b)shows two EOS fork episodes that is [290 292) and[294 302)e first fork episode [174 176) of Ethereumexhibits the run length of 3 the weight of 4 and the degree of4 with three nonreported (ie thus available only from ourmeasurement) stale blocks e second fork episode[294 302) of EOS exhibits the run length of 9 the weightof 9 and the degree of 2

412 Nonearliest Advertised Block Endorsement of EthereumMiners Our most interesting finding is that Ethereumminers often do not add blocks to the earliest advertisedblock during fork episodes Consider an illustrative forkepisode depicted in Figure 6(b) e episode begins as thethree blocks (ie b1 b2 and b3) are added to the fork ini-tiating block b0 e immediately following blocks (ie bi

and bj) will have their previous blockhash identifying one ofthe three previous blocks of the minerrsquos choice e block bimined by some miner may be added to the earliest block(ie b1) the other block bj is mined by a different miner whochooses a different block (ie b2) to add to To evaluateminersrsquo preference of blocks to which succeeding blocks areadded in the event of blockchain forks we define theconditional probability of miner ma adding a block to aprevious block mined by mb (by not adding to any of adifferent minerrsquos block) in fork episodes for all ma and mb

Pr miner bi( 1113857( mb|miner bj1113872 1113873

ma

prev bj1113872 1113873 bi

existbk height bk( 1113857 height bi( 1113857)

(1)

Figure 9(a) shows a histogram of the above probabilityma (x-axis) adds a block to mbrsquos block (label) over others infork episodes It is apparent that the top ranked minerssignificantly prefer adding blocks to their own mined blocksover other minersrsquo blocks Figure 9(b) depicts the same

6 Security and Communication Networks

bf

br

m

m + 1

n

n + 1

Height

(a)

Time

Arrival (b1)

Arrival (b2)

Arrival (b3)

b0

b1

b2

b3

bi

bj

(b)

Figure 6 Fork analysis model (a) Fork episode (b) Fork resolve example

EthereumEOS

0

02

04

06

08

1

Cum

ulat

ive f

requ

ency

2 4 6 8 10 120 14

Run length

EthereumEOS

0

02

04

06

08

1

Cum

ulat

ive f

requ

ency

2 4 6 8 10 12 140

Weight

EthereumEOS

0

02

04

06

08

1

Cum

ulat

ive f

requ

ency

40 62

Degree

Figure 7 Fork episode characteristics

∆ (ts0 ts1)∆ (ts0 ts3)∆ (ts0 ts7)

0010203040506070809

1Cu

mul

ativ

e fre

quen

cy(

of t

rans

actio

ns)

2 4 6 8 100Time difference (seconds)

(a)

BitcoinEthereumEOS

1 2 3 4 50Time difference (seconds)

0

02

04

06

08

1

Cum

ulat

ive f

requ

ency

( o

f tra

nsac

tions

)

(b)

Figure 5 Transaction arrival time accuracy (a) Transaction arrival time differences of Bitcoin (b) Δ(ts0 ts1) distribution

Security and Communication Networks 7

(a) (b)

Figure 8 Example fork episodes each dot represents a block followed by block hash (last six hexadecimals) arrival time block height (lastthree digits) block timestamp and its miner Each Ethereum stale block is tagged either R (reported uncle) or NR (not reported) Each EOSblock is tagged with the block sequence (out of 12) of the corresponding BPrsquos production schedule (a) Ethereum (b) EOS

SparkPoolEthermine

F2PoolNanopool

MiningPoolHubzhizhutop

Unconditional SparkPool Ethermine F2Pool Nanopool MiningPoolhub

zhizhutop

0

01

02

03

04

05

Freq

uenc

y

(a)

EarliestMixedNonearliest

Spar

kPoo

lEt

herm

ine

F2Po

olN

anop

ool

Min

ingP

oolH

ubzh

izhu

top

UU

Pool

Pand

aMin

erBT

POO

Lxn

pool

Huo

biM

inin

gPoo

lD

war

fPoo

lfir

epoo

lU

nkno

wn

Min

ing

Expr

ess

BTC

com

Pool

Min

eral

lPoo

lBe

ePoo

lH

iveo

nPoo

l2M

iner

sPPL

NS

2Min

ersS

OLO

Coin

otro

nW

POO

LEz

ilPoo

lpo

olin

o

f tot

al fo

rk re

solv

e

(b)

Figure 9 Ethereum fork resolve statistics (a) Probability of ma (x-axis) adding a block to mbrsquos block (b) Probability of adding to the earliestpropagated block

8 Security and Communication Networks

probability by labeling whether or not the chosen block (byma) is the earliest propagated one e ldquoearliestrdquo label in-dicates that the block to which the newly mined block (byma) is added has been observed as the earliest one to arrivecongruently among all eight measurement locations (Asblock arrival times are measured in eight different locationsthe arrival order can be conflicting e ldquomixedrdquo labelrepresents the conflicting cases) For example the topranked pool SparkPool chose the earliest arriving blocksim55 of the time 3409 out of 6234 blocks among the other2825 blocks that were added to nonearliest previous blocksSparkPoolrsquos own blocks were chosen over others 1211 timeswhile other poolsrsquo blocks were preferred to SparkPoolrsquos only24 times In the meantime Nanopool chose the earliest one amajority of the time For the top 25 ranked mining pools onlyfour of them added blocks to the earliest arriving blocks morethan 90 of the timeis contradicts the earliest propagatedblock endorsement assumption that is broadly adopted inmining-related research [36ndash38]

One possible explanation of the phenomenon is that themining pools adopt their own block preferring strategy as asimple precautionary defense against yet unknown selfishmining pools the profitability of selfish mining largelydepends on the probability of honest pools adding to theattacking poolrsquos branch

413 Cut-Tail Fork Pattern of EOS BPs We find that theEOS fork episodes occur in a way that BPs are cutting the tailof the previous BPrsquos produced blocks EOS adopts the DPoSconsensus mechanism [26] 21 block producers (BPs) areelected by voting and scheduled to produce 12 consecutiveblocks in 6 seconds (ie 500ms for each block) in the al-phabetical order of their names Figure 10 shows thenumbers of switching (by schedule) events and cut-tail forkevents of all immediate BP pairs We observe a high fre-quency of such events when bitfinexeos1 is producing blocksby appending to big onersquos blocks while there are accusationsof BPrsquos dishonest behaviors we believe that the reportedbitfinexrsquos performance problem is the compelling reason forthe phenomenon [39]

42 Unseen and Stale Transactions

421 Private Transaction Mining Unseen transactions arecharacterized by the strong evidence that implies that theunseen transactions are indeed never advertised to the net-work Table 6 categorizes 9587 of Ethereum unseentransactions by using the from addresses of the transactions(We use prefixes followed by ⋆ in presenting hash valueseg address (ie pubkey hash) and txid for brevity Weunderstand this does not entirely anonymize identity as thereaders can verify their results against ours by matching theprefixes) Public names are retrieved from Etherscan [16] Aminer is specified in the table only if all blocks that includethe unseen transactions with the from address are con-gruently mined by that single miner It shows that most ofthe unseen transactions are indeed the block minerrsquos owntransactions

Table 7 shows unseen Bitcoin transactions categorized bythe identified reasons sim 67 of the unseen transactions areeither zero-fee transactions or zero-fee-transaction-dependenttransactionsWe define a transaction t isin transactions(b) as adependent transaction if at least one of input transactions oft is included in the same block b

Bitcoin Core [28] implementation does not propagatetransactions with zero transaction fee Also a dependenttransaction cannot be mempooled until the transaction towhich it is dependent is mempooled consequently it cannotbe relayed to peers e Bitcoin Core mempool imple-mentation justifies the inexistence of zero-fee and zero-fee-dependent transactions from our measurement Existence ofa stale transaction which shares the same transaction inputwith the unseen transaction may imply a possible double-spend attempt a variant [40] involving private mining of ablock with ti while advertising a conflict transaction tj suchthat inputs(ti)cap inputs(tj)neempty we have observed 27 suchunseen transactions without a certainty of attack intentionsor if they are not indeed advertised Lastly multisig trans-action inputs often imply off-chain protocols where signedtransactions are exchanged out-of-band [41] and havingOP_RETURN transaction output implies special purposeprotocols of Bitcoin for example sidechains where theirrelationship with miners require further investigation [42]e presence of unseen transactions by either privatetransaction mining or potential out-of-band delivery oftransactions has a subtle security implication One obviousside effect is privatization of transaction fees the transactionfees of privately mined ones are exclusively obtainable by theprivate miner alone unless the network is fully utilized Ifthe network is fully utilized a miner is forced to include herprivate transactions at the expense of not including othertransactions as the block capacity is limited

422 Conflict Stale Transactions Stale transactions arenetwork-transmitted transactions that are not included inany of the blocks

Table 8 shows the stale transaction counts observed ateach location e stale transactions account for 020369 and 047 of Bitcoin Ethereum and EOS transac-tions respectively Ethereum transactions had an order ofmagnitude more chance of being stale than others

As for public blockchains with transaction fees that isBitcoin and Ethereum stale transactions are mostly at-tributable to conflict Table 9 summarizes the identifiedreasons for transactions being stale A stale Bitcoin trans-action is attributable to conflict if there are one or moretransactions sharing at least one transaction input (ie vin)

An Ethereum transaction is attributable to conflict ifthere is another transaction with the same nonce from thesame account A widely known reason for two or moretransactions being in conflict is transaction replacementsuch as replace-by-fee [43] On the other hand slightly morethan 5 of Bitcoin transactions are stale because at least oneof their transaction inputs is also stale

On the other hand roughly one out of ten staleEthereum transactions is attributable to improper ordering

Security and Communication Networks 9

of nonce (e transaction nonce should be equal to thenumber of transactions sent from the address) nonce is toohigh (983) or too low (002) Last but not least 727 ofstale transactions are not included in blocks because theaccount is not sufficiently funded (An Ethereum accountshould have balance ge value+ gastimes gas price to execute thetransaction [44]) An Ethereum account can be

insufficiently funded when executing a transaction for anumber of reasons [45]

423 EOS Transaction Discrepancy EOS exhibits unseenand stale transactions far different from those of Bitcoin orEthereum that is the PoW blockchains with transaction feeEOS software is not bundled with peer discovery rather thenode operator is required to look up for candidate BPrsquospeering services timely delivery of blockchain data andreliability of the node is dependent on the peering nodes ofchoice (Indeed we have experienced service disruption bydisconnecting from peers for unknown reasons)e notionof being conflict in two or more transactions that is themost frequent reason for transactions being stale for Bitcoinand Ethereum is not applicable to EOS (EOS adopts theaccount model without transaction ordering per accountthus there should be no conflict transaction outputs or thesame account nonce) On the other hand EOS requires

eosh

uobi

pool

-eos

infst

ones

eosfl

ytom

ars-

eosh

uobi

pool

zbeo

sbp1

1111

-atti

clab

eosb

attic

labe

osb-

big

one

hoo

com

-new

dex

bpw

hale

exco

m-z

beos

bp11

111

start

eosio

bp-w

hale

exco

meo

sdot

wik

ibp-

eosfl

ytom

ars

eosc

anno

nchn

-eos

dotw

ikib

pbi

gon

e-bi

tfine

xeos

1eo

sinfst

ones

-eos

iom

eeto

nehe

lloeo

scnb

p-ho

oco

meo

slaom

aoco

m-e

ossv

12eo

ssv

slow

mist

iobp

-sta

rteo

siobp

eoss

v12e

ossv

-hel

loeo

scnb

peo

sbei

jingb

p-eo

scan

nonc

hneo

siosg

1111

1-eo

slaom

aoco

meo

siom

eeto

ne-e

osio

sg11

111

bitfi

nexe

os1-

cert

ikeo

sorg

new

dex

bp-s

low

mist

iobp

coch

ainw

orld

-eos

asia

1111

1bi

tfine

xeos

1-co

chai

nwor

ldce

rtik

eoso

rg-c

ocha

inw

orld

eosa

sia11

111-

eosb

eijin

gbp

new

dex

bp-o

kcap

italb

p1eo

siom

eeto

ne-e

osla

omao

com

okca

pita

lbp1

-slo

wm

istio

bpco

chai

nwor

ld-e

osbe

ijing

bpne

wde

xbp

-sta

rteo

siobp

eosa

sia11

111-

eosc

anno

nchn

eosla

omao

com

-hel

loeo

scnb

pco

chai

nwor

ld-e

osca

nnon

chn

cert

ikeo

sorg

-eos

beiji

ngbp

eoss

v12e

ossv

-hoo

com

bitfi

nexe

os1-

eosa

sia11

111

eosin

fston

es-e

osla

omao

com

okca

pita

lbp1

-sta

rteo

siobp

BP switching (left)Cut-tail (right)

0

5000

10000

15000

20000

25000

BP sw

itchi

ng ev

ents

0

100

200

300

400

500

cu

t-tai

l eve

nts

Figure 10 EOS BP switching and cut-tail events

Table 6 Ethereum unseen transactions

From address Public name Transaction count Miner0xea67⋆ Ethermine 128145 (7242) Ethermine0x2a65⋆ DwarfPool 22955 (1297) DwarfPool0x8fd0⋆ Unknown 11346 (641) SparkPool0x829b⋆ F2Pool 4453 (251) F2Pool0x4c54⋆ HiveonPool 1135 (064) SparkPool0x99c8⋆ BeePool 468 (026) BeePool0xdba7⋆ Unknown 348 (020) UUPool0x464b⋆ FKPool 340 (019) FKPool0xf687⋆ Unknown 217 (012) AntPool0xa801⋆ Unknown 151 (009) AntPool0xbe7c⋆ Unknown 126 (007) AntPool0xb96f⋆ Unknown 101 (006) AntPool

Sum 169785 (9587)

Table 7 Bitcoin unseen transactions

Category Transactioncount

Zero-fee transaction 148 (5068)Zero-fee-transaction-dependent transaction 48 (1644)Multisig transaction input 43 (1473)Conflict with stale transaction 27 (925)OP_RETURN transaction output 26 (890)Sum 292 (10000)

10 Security and Communication Networks

contract users to stake tokens for CPU time that can bededucted by transaction executions A requested transactioncan be rejected thus being stale due to the lack of CPU timeor other resources similarly Replaying the entire statechanges of EOS to find out stale transactions due to lack ofresources is not possible unless all transaction and state logsof the entire BPs are available

On the other hand EOS transactions have two additionalattributes which are not available in the Bitcoin or Ethereumtransaction structures

(i) Reference block every EOS transaction refers to ablock by specifying the block number and hash notonly to prevent replay attacks but also to signal thenetwork that the userrsquos stake is on a specific fork

(ii) Expiration time EOS transactions have explicitexpiration times

If a transactionrsquos reference block is not part of the mainchain at the time of execution the transaction cannot beexecuted (and thus cannot be included in a block) We haveidentified that 18 of stale transactions apply to this case Tofurther identify unknown reasons we consider four timedevents that are relevant to transaction execution

(i) Last irreversible block arrival time arrival(blib) thearrival time of transactionrsquos reference block EOStransactions by default refer to the last irreversibleblock (LIB) [26]

(ii) Head block arrival time arrival(bhead) the scheduledtime of the head block when transaction is arrived

(iii) Transaction arrival time arrival(t) the arrival timeof transaction t

(iv) Expiration time exp(t) the expiration time oftransaction t

e three time differences that is Δexp Δincl and Δtrxare investigated to find characteristics of unseen (Tunseen)and stale (Tstale) transactions over the normal transactions(Tincluded) Figure 11 illustrates the relevant events and timedifferences of them Δexp measures the time difference be-tween the two scheduled (ie virtually timed) events Δincland Δtrx are defined by the arrival events to our monitornode Figure 12 shows the distributions of Δexp Δincl andΔtrx We find that unseen transactions have prolonged Δinclimplying that the delay of newly produced blocks can causenewly generated transactions not promptly delivered be-cause the sync manager is in the Head Catch-Up mode astransactions are only transferred in In-Sync mode by itsdesign [24] Stale transactions with relatively small Δtrx canbe attributable to problematic dApp implementations re-ferring to non-LIB blocks the chain instability caused byblockchain fork mostly due to the cut-tail behavior shown inSection 41 can cause transactions being rejected for im-mature block reference

However we do not find any reason attributable to thetransaction expiration Although the unseen transactionstend to have smallΔexp the expiration times are only as smallas 30 seconds (ie the default expiration time) Particularlyone or more EOS applications set the expiration time to180 seconds (other than the default 30 seconds) and morethan half of the stale transactions are invoked by thoseapplications

While transaction is the smallest unit of execution inBitcoin and Ethereum the unit of contract execution in EOSis action [24] A transaction consists of one or more actionsHowever the constituent actions in a single transactioncannot be separately advertised or executed accordingly weapply the identical transaction model to EOS without loss ofgenerality

5 Block and TransactionArrival Characteristics

51 Arrival Processes All three blockchains we study in thispaper are designed to publish capacity constrained blocks intargeted regular time intervals An incarnation of suchdesign is expected to exhibit a Poisson block arrival processWhile it is claimed that Bitcoin block arrivals do not entirelyexhibit a homogeneous Poisson process due to its difficultadjustment mechanism [46] transaction arrival processes ofblockchains are not studied in the literature to the best of ourknowledge A particularly meaningful step toward under-standing the arrival process of events generated by a complexsystem is examining if the arrival events are independent orexhibiting a correlated structure [47]

e variance-time log-log plots [48] of the block andtransaction arrival event time series are depicted in

Table 8 Stale transactions

Region Bitcoin Ethereum EOSAsia-East 41720 1170706 mdashAsia-South 41653 1194018 504277Europe-North 41693 1192435 470480Europe-West 41668 1123680 450140North America-Northeast 41703 1212210 588711US-Central 41683 1212389 505160US-East 41692 1186488 mdashUS-West 41672 1167627 480207Combined 42023 1351847 672999

Table 9 Identified reasons of stale transactions

Category Transaction count(a) Bitcoin

Conflict 39408 (9378)Stale transaction input 2307 (549)Conflict and stale transaction input 308 (073)Sum 42023 (10000)

(b) EthereumConflict 1208588 (8924)Nonce (skipped) 133161 (983)Nonce (used) 251 (002)Insufficient fund 9847 (727)Sum 1351847 (9982)

(c) EOSFork 12106 (180)Others 660893 (9820)Sum 672999 (10000)

Security and Communication Networks 11

Figure 13(a) As regards the block arrival processes Bitcoinblock arrivals exhibit a linear slope β minus23 e estimatedHurst parameter H 1 + β2 43 implies that the processis not a homogeneous Poisson process but LRD (Long-Range Dependent) contrary to what is expected for a regularinterval event generation [46] Ethereum block arrivalsapproximate the Bitcoinrsquos except for the high aggregationlevel due to high stale block rate EOS block arrivals incontrast follow the slope β minus1 in the low aggregation levelas the block generation is indeed regularly scheduled

Figure 14 shows the variance-time plot of Ethereum andEOS block arrival time series by taking all block arrivalevents (Bobs) and main chain block arrivals only (Bmain) Weconfirm that Ethereum block arrivals indeed exhibit astraight line (close to Bitcoin) if excluding stale blocksHowever EOS block arrivals do not exhibit a straight line

even if we exclude stale blocks due to delayed burst blockarrivals possibly due to cut-tail fork patterns (see Section41)

e transaction arrival processes of all three blockchainsappear to exhibit LRD with Hurst parameter Hgt 56 asβltminus13 To further identify analytical distributions that fitbest the empirical ones the coefficient of variation (σμ) andskewness (ie the standardized third moment) of transac-tion interarrival times are computed for every measurementdataset and compared to the relationships expected for theexponential lognormal Weibull and Gamma distributionsin Figure 13(b) We find that Bitcoin Ethereum and EOStransaction interarrival times are fit best Gamma Weibulland lognormal distribution respectively Individual datasetsare also examined for the fitness of the distribution to findthat the empirical distribution fits the analytical distribution

Virtualclock

Time

Transaction initiator

Time

Blockproducer

Time

Monitornode

Time

Scheduled block time of blib

Scheduled block time of bhead

Scheduled block time of bincl

1 Produce and propagate blib

2 Produce and propagate bhead

Expiration time of t

4 Produce and propagate bincl

Δexp

Δtrx

Δincl

3 Create and propagate t

Figure 11 EOS transaction analysis model

Tincluded

Tstale

Tunseen

0010203040506070809

1

Cum

ulat

ive f

requ

ency

100 200 300 400 5000Time difference (seconds)

(a)

Tincluded

Tunseen

01 1 10 100 1000001Time difference (seconds)

0010203040506070809

1

Cum

ulat

ive f

requ

ency

(b)

Tincluded

Tstale

0010203040506070809

1

Cum

ulat

ive f

requ

ency

01 1 10 100 1000001Time difference (seconds)

(c)

Figure 12 EOS transaction timing analysis (a) Δexp (b) Δincl (c) Δtrx

12 Security and Communication Networks

well except for the small interarrival time ranges For ex-ample Figure 15 depicts the CDF of Ethereum transactioninterarrival times observed in US-West Although the em-pirical distribution fits Weibull with parameters computedwith the maximum likelihood estimator [49] sample pointsunder several milliseconds appear to be unreliable (We areyet unaware of the reason However it is known that thetime source of commodity operating systems is not accurateand we need an external time source for accurate sub-millisecond timing measurement [50])

52AdvertisementRedundancy Bitcoin and Ethereum nodepieces of software are implemented to maintain a large

number of peer connections with multiple random remotenodes Bitcoin Core can connect up to 125 peers where 8 ofthem are outbound connections Go Ethereum maintains 50peer connections where 16 of them are outbound by default(see Table 1) On the other hand partitioning attacks aredeveloped to isolate a blockchain node from the others bytampering with all such peer connections Partitioning at-tacks usually exploit vulnerable peer management mecha-nisms of Bitcoin [51] and Ethereum [52] Such attacks arealso examined in the context of ISPrsquos BGP hijacking [53] anda stealthier variant relieving the attacker from the risk ofgetting exposed [54] e attacks often rely on imple-mentation vulnerabilities for efficient eclipsing of peerswhile known vulnerabilities are getting addressed for ex-ample the lack of parallel block download sessions causing

Slope = ndash1

Trx BitcoinTrx EthereumTrx EOS

Blk BitcoinBlk EthereumBlk EOS

ndash12

ndash10

ndash8

ndash6

ndash4

ndash2

0Lo

g no

rmal

ized

var

ianc

e

124 6 10 140 2 8Aggregation level

(a)

Lognormal

Weibull

Gamma

Exponential

BitcoinEthereumEOS

0

5

10

15

20

Stan

dard

ized

third

mom

ent

1 2 3 40Coefficient of variation

(b)

Figure 13 Transaction arrival characteristics (a) Variance-time plot of block and transaction arrivals (b) Cov versus skewness oftransaction interarrival times

Ethereum - Bobs

Ethereum - Bmain

EOS - Bobs

EOS - Bmain

ndash12

ndash10

ndash8

ndash6

ndash4

ndash2

0

Log

norm

aliz

ed v

aria

nce

2 4 6 8 10 12 140Aggregation level

Figure 14 Variance-time plot of block arrivals including staleblocks (Bobs) and excluding stale blocks (Bmain)

EmpiricalExponential μ = 0024

Lognormal μ = 00354 σ2 = 00486Pareto k = 0000212 a = 0231Weibull c = 0589 a = 00147

00001 0001 001 01 1000001Time (seconds)

0

02

04

06

08

1

Cum

ulat

ive f

requ

ency

Figure 15 Empirical and fitted analytical distributions of Ether-eum transaction interarrival times

Security and Communication Networks 13

temporary denial of blocks (reported in [27] and fixed byrecommending three concurrent download sessions in [55])let attackers successfully partition the node without eclipsingall peer connections [53] A simple countermeasure of in-creasing the number of peer connections on the other handis applied to the reference public blockchain implementa-tions [56 57] to inflate attack complexity

We investigate the degree of a peerrsquos advertisementredundancy on newly generated blocks and transactions toevaluate the efficacy of partitioning attacks and the coun-termeasure of increasing the number of peer connectionsFigure 16 shows how redundantly newly generated blockinformation is offered by peers Bitcoin nodes have main-tained sim43 peer connections that is 8 outbound and ad-ditional 35 inbound connections on average and Ethereumnodes record all 50 peer connections established during theentire observation period

For each newly generated block one-third of peersadvertised the block header to our Bitcoin node and morethan 90 of Ethereum peers signaled availability of theblocks In consequence successfully partitioning a noderequires compromise of peers proportional to the totalnumber of peer connections Increasing the number of peerconnections will burden the attacker linearly as expected

Figure 17 shows how redundantly the newly generatedtransaction information is offered by peers While one out ofthree Bitcoin peers also advertises new transactions viaINVENTORYmessage [58] half of the Ethereum peers havesent new transactions to our node in average Bitcoin andEthereum blocks are advertised with the block header(rather than the direct delivery of all block contents) Bitcointransactions are also advertised with INVENTORY messagebefore the whole contents are transferred HoweverEthereum transaction data that is the entire contents aredirectly sent by peers (Ethereum now has a pooled trans-action delivery model in its newer ETH64 protocol [30])We also find that there are cases with much less advertisedtransactions and have identified that they are indeed mostlystale ones stale transactions are mostly due to conflict (seeSection 42) and the nodes that already queued the conflicttransaction will not relay the stale one

6 Discussion

61 Implication on Mining Attacks Cryptocurrency mininghas been a popular subject in assessing the security ofBitcoin selfish mining [37] block withholding attack [36]and a mixed strategy [38] have been studied Although it isshown that selfish behavior in mining is always moreprofitable than being honest without need for a mutualagreement of not attacking each other [38] we find thatselfish mining is not the preferred strategy All selfish miningstrategies will result in blockchain forks but we observe avery low fork probability (ie 004) for Bitcoin On theother hand selfish mining on Ethereum has been studiedonly recently to unanimously claim that selfish mining isalso profitable for Ethereum miners however it is lessprofitable than Bitcoin due to its uncle reward system [59]Our result in Section 4 shows that a majority of Ethereum

miners choose to add to their own produced blocks over theearliest propagated blocks How does this affect the selfishmining strategy

e selfish mining strategy assumes a parameter c whichdefines the fraction of honest minersrsquo mines on the attackerrsquosfork branch (e parameter comes into play in case (f ) of[27]) If the attacking pool has a network-wise superiorposition in block propagation (ie cgt 05) the selfishmining strategy is profitable for pools with proportionalmining power αgt 25 [37] Absolute network inferiority(ie c 0 due to a defensive mining strategy such as the onepresented in Section 41) increases the required miningpower to 33 the 33 mining power appears to be sig-nificantly harder to achieve in the real world [20]

As for the FAW (Fork-After-Withholding) attackstrategy [38] the network capability parameter C defines theprobability that an attackerrsquos FPoW (Full Proof-of-Work)block (during infiltration mining) is selected as a main chainblock C affects both the attack reward and whether theminerrsquos dilemma holds or not in the mutual attacking gameAs an example case (Section 9 of [38]) of a two-pool gamebetween F2Pool and BitFury the absolute network inferi-ority drops C from 0914 to 03 to make it a dilemmatic gameagain Unfortunately minersrsquo own block preferences cannotbe directly transferred to a single parameter of c or C it callsfor a model change from previous mining studies

62 Conflict Transactions and Double-Spending AttacksDouble-spending attacks have been studied in the context ofBitcoin fast payments where zero or only one confirmation isrequired to complete an offline merchandise transaction[60] real-world cases where two conflict transactions dis-parately arrive at different measurement locations mayimply such attacks Table 10 shows the cases where twotransactions are in conflict (and thus only one of themis included in a block ie inputs(ti)cap inputs(ts)neemptyand existb isin Bmain ti isin transactions(b) (∄b isin Bmain ts isintransactions(b) is indisputable given a consistent transactionledger)) and two different subsets of the monitors havemempooled either one of them We also have identified 27unseen transactions implying possible one-confirmationattack variant requiring the private mining (ie not ad-vertising the double-spending transaction to the network) in

5 10 15 20 25 30 35 40 45 500 of peers

0

005

01

015

02

025

Freq

uenc

y

BitcoinEthereum

Figure 16 Peer redundancy of block advertisement

14 Security and Communication Networks

Section 42 As for the countermeasure of such attacks bydeploying monitors [60] deployment of 8 monitors in thenetwork to detect the attacks would fail at most 27 out of 95times (sim30) assuming that those 27 unseen transactionswe have identified are initially advertised to the network

63 Potential Impact on Blockchain ApplicationsEthereum and EOS are the most widely used smart contractplatforms fostering various decentralized applications Bit-coin which lacks the capability of executing complex smartcontract codes is also recently utilized to execute smartcontracts for decentralized applications [50 61] Eventhough our work focuses on the fundamental blockchainmechanisms in terms of transactionblock production andpropagation the impact of our findings on decentralizedapplications can be foresighted

According to our blockchain fork results (Section 41)the lack of selfish mining in the real world was speculated bya very low stale block rate of Bitcoin network and prevalenceof nonearliest block endorsement by Ethereum miners Asprofitability of selfish mining encourages miners to behavein a way of producing more blockchain forks the perfor-mance degradation is proportionate to the number of minerswho adopt the selfish mining strategy the key performancemetrics affecting the blockchain application performance

such as node response time or block delivery time are shownto be noticeably degraded due to the selfish mining [62] Forexample decentralized identities issued or revoked on suchblockchains [63 64] cannot be responsively finalized due toinflated blockchain forks Our results show that the selfishmining is not prevalent in the real world thus the appli-cation performance impact is overrated even though it istheoretically shown that miners have every reason to beselfish [38] As for EOS we reported cases where a sequenceof (up to 12) blocks being stale are often observed in suc-cessive mining of two BPs however the rate is too low (ie004) to impact the performance of applications (Section32)

Transaction arrival processes being LRD (Section 51)pose a technical challenge in provisioning transactionprocessing scalability especially for Layer-2 blockchain ap-plication solutions [65 66] For example Layer-2 rollupsolutions require transaction relays which aggregate indi-vidual user transactions of a given blockchain applicationdeployed in the network often without a priori knowledge ofnetwork load One way of solving the problem is a properprioritization of transactions based on the applicationcontext

Lastly blockchain network partitioning can be thebiggest concern for blockchain service providers We ob-served that the increased numbers of peer connections inblockchain reference implementations effectively provide ahigher degree of information redundancy (Section 52)However increased number of peer connections can beexploitable for an attacker who has a denial-of-service attackvector or an invalid transaction initiated by a simple ap-plication bug can flood the network [45]

64 Limitation Our measurement study has several limi-tations First of all our results may only capture only a fewmonths of blockchain network operations In the meantimethe permissionless blockchain pieces of software are in activedevelopment for example Ethereum now utilizes the pooledtransaction delivery [67] instead of unsolicited transactiondelivery which was the only mode at the time of our

Table 10 Bitcoin disparately mempooled transactions

monitors mempooledti

monitors mempooledts

Transactioncount

7 1 26 (3824)6 2 14 (2059)5 3 10 (1471)4 4 5 (735)3 5 5 (735)2 6 3 (441)1 7 3 (441)5 1 1 (147)6 1 1 (147)

Sum 68 (10000)

Tincluded

Tstale

5 10 15 20 25 30 35 40 45 500 of peers

0

005

01

015

02

025

03Fr

eque

ncy

(a)

Tincluded

Tstale

0002004006008

01012014016

Freq

uenc

y

4030 500 10 20 of peers

(b)

Figure 17 Peer redundancy of transaction advertisement (a) Bitcoin (b) Ethereum

Security and Communication Networks 15

measurement Both cryptocurrency market values andblockchain network utilizations are rapidly increasing andthus miners are getting more motivated to optimize theirperformance for example Bitcoin fork probability has be-come far smaller than what is reported previously (seeSection 41)

Second the blockchain state information is not collected inour measurement Our analysis is performed based on onlyavailable information stored in block and transaction logs Wehave utilized an Ethereum archive node [44] to query historicalstate information (eg account balance or account nonce) inSection 42 However such proactive state replication is farmore complicated with EOS unless the full node is configuredto operate as a producing node and logging the state infor-mation thus EOS stale transactions could not be fully un-derstood without the missing EOS network state information

7 Related Work

71 Blockchain Data Analysis Historical transaction data ofBitcoin have often been studied for economic aspects such ascryptocurrency abuse [17] anti-money-laundering [18] andmonetary flow of businesses [19] However historicalblockchain data usually available from block explorer ser-vices are not sufficient for our research purpose

72 Blockchain Measurement Researchers have performedblockchain measurement studies to assess the degree ofdecentralization [20] to investigate demographic informa-tion of network nodes [34 68] to study mining pool be-havior [22] and to evaluate security of PoW blockchains [21]against known attacks such as double-spending attack [60]and selfish mining [37] Our work expands the under-standing of previous security evaluations with the keyfindings acquired from our large-scale transaction and blockmeasurement

73 Blockchain Attacks Partitioning attacks usually exploitvulnerable peer management mechanisms of Bitcoin [51]and Ethereum [52] Such attacks are also examined in thecontext of ISPrsquos BGP hijacking [53] and a stealthier variantrelieving the attacker from the risk of getting exposed [54]Cryptocurrency mining has been a popular subject inassessing the security of Bitcoin selfish mining [37] blockwithholding attack [36] and a mixed strategy [38] have beenstudied Double-spending attacks have been studied in thecontext of Bitcoin fast payments [60]

74 Block Explorer Services We have surveyed the popularblock explorer services of Bitcoin [5 10 12] Ethereum[10 13 16] and EOS [11 14 15] to see the availability ofinformation beyond what is recorded in the main chainblock data we have utilized in our study namely

(i) Stale blockstransactions no Bitcoin and EOS blockexplorers provide stale block information (A relatedstudy [36] has utilized a Bitcoin block explorer service[68] to retrieve stale blocks However the service has

been terminated in March 2019) All Ethereum blockexplorers provide only reported stale blocks (ie uncleblocks [23]) (Ethereum provides incentives for unclestale blocks [44] so that miners include them in theirmined blocks for profit)No block explorers provide stale transaction infor-mation unless one is currently pooled

(ii) Blocktransaction arrival times all block explorersprovide block timestamps that are recorded in theblock headers not the actual times of arrival Ourblockchain fork and gap analysis require measuredblock arrival times at multiple locations All blockexplorers show transaction timestamps identical to theblock timestamp to which the transactions belong(Recent Bitcoin transactions have different timestampsthan the block timestamps in [4] while the timestampsare only at a granularity of one minute) [69 70]

8 Conclusion

We have measured transaction and block arrival events ofthe three permissionless blockchains We have devised anoble analysis model and analyzed completeness of ourblock and transaction logs Finally we have studied thediscrepancy in measured events and arrival characteristics toshare our key findings including a false universal assumptionof previous mining-related studies

Data Availability

e measurement data used to support the findings of thisstudy have not been made available because they containprivate information that can be used to identify individualblockchain nodes

Disclosure

is is an extended and revised version of a conference paperpresented in IEEE ICDCS 2021 [41]

Conflicts of Interest

e authors declare that they have no conflicts of interest

Acknowledgments

e authors would like to thank Seungwon Woo DaegeunYoon and Changhyun Lee for helping them with themeasurement instrumentation is work was supported byElectronics and Telecommunications Research Institute(ETRI) grant funded by the Korean Government (21ZR1300Research on Intelligent Cyber Security and Trust Infra)

References

[1] S Nakamoto ldquoBitcoin a peer-to-peer electronic cash systemrdquo2019

[2] V Buterin ldquoEthereum white paperrdquo 2013 httpsethereumorgenwhitepaper

[3] Monero ldquoMonerordquo 2020 httpswebgetmoneroorg

16 Security and Communication Networks

[4] bitcoincashorg httpswwwbitcoincashorg[5] Blockchaincom httpswwwblockchaincom[6] Ripple ldquoXRP e best digital asset for global paymentsrdquo

2020 httpsripplecomxrp[7] I Foundation ldquoIotardquo 2021 httpswwwiotaorg[8] ldquoEosiordquo 2020 httpseosio[9] S Orsquoneal ldquoEos proves yet again that decentralization is not its

priorityrdquo 2018 httpscointelegraphcomnewseos-proves-yet-again-that-decentralization-is-not-its-priority

[10] Blockchair httpsblockchaircom[11] Bloksio httpsbloksio[12] BTCcom ldquoBitcoin block explorerrdquo 2021 httpsbtccom[13] Ethereum block explorer httpsethbtccom[14] eosflareio Eos block explorer httpseosflareio[15] EOSPark ldquoEos block explorerrdquo 2021 httpseosparkcom[16] Etherscan Ethereum explorer httpsetherscanio[17] S Lee C Yoon and H Kang ldquoCybercriminal minds An

investigative study of cryptocurrency abuses in the dark webrdquoin Proceedings of the Network and Distributed System SecuritySymposium pp 1ndash15 Internet Society San Diego CA USAFebruary 2019

[18] MMoser R Bohme and D Breuker ldquoAn inquiry into moneylaundering tools in the bitcoin ecosystemrdquo in Proceedings ofthe 2013 APWG eCrime Researchers summit pp 1ndash14 IEEESan Francisco CA USA September 2013

[19] M Lischke and B Fabian ldquoAnalyzing the bitcoin network thefirst four yearsrdquo Future Internet vol 8 no 1 2016

[20] A E Gencer S Basu I Eyal R V Renesse and E G SirerldquoDecentralization in bitcoin and ethereum networksrdquo inProceedings of the International Conference On FinancialCryptography and Data Security pp 439ndash457 SpringerNieuwport Curaccedilao February 2018

[21] A Gervais G O Karame KWust V Glykantzis H Ritzdorfand S Capkun ldquoOn the security and performance of proof ofwork blockchainsrdquo in Proceedings Of the 2016 ACM SIGSACConference on Computer and Communications Securitypp 3ndash16 Vienna Austria October 2016

[22] C Wang X Chu and Q Yang ldquoMeasurement and analysis ofthe bitcoin networks a view from mining poolsrdquo 2019httpsarxivorgabs190207549

[23] G Wood ldquoEthereum A secure decentralised generalisedtransaction ledgerrdquo Ethereum Project Yellow Paper vol 1512014

[24] ldquoTransactions protocol eosio developer docsrdquo 2018 httpsdeveloperseosiowelcomev20protocoltransactions_protocol

[25] Y Sompolinsky and A Zohar ldquoSecure high-rate transactionprocessing in bitcoinrdquo in Proceedings of the InternationalConference On Financial Cryptography and Data Securitypp 507ndash527 Springer San Juan PR USA January 2015

[26] Blockone ldquoConsensus protocolrdquo 2018 httpsdeveloperseosiowelcomev20protocolconsensus_protocol

[27] A Gervais H Ritzdorf G O Karame and S CapkunldquoTampering with the delivery of blocks and transactions inbitcoinrdquo in Proceedings Of the 22nd ACM SIGSAC ConferenceOn Computer and Communications Security pp 692ndash705Denver CO USA October 2015

[28] ldquoGithub Bit coinrdquo 2020 httpsgithubcombitcoinbitcoin[29] G Ethereum ldquoGo ethereumrdquo 2020 httpsgithubcom

ethereumgo-ethereum[30] Google ldquoGoogle cloudrdquo 2021 httpscloudgooglecom[31] ldquoHow to replay from a snapshotrdquo 2018 httpsdeveloperseos

iomanualseoslatestnodeosreplayshow-to-replay-from-a-snapshot

[32] C Decker and R Wattenhofer ldquoInformation propagation inthe bitcoin networkrdquo in Proceedings of the IEEE P2P 2013Proceedings pp 1ndash10 IEEE Trento Italy September 2013

[33] ldquoEthereum uncle raterdquo 2020 httpsychartscomindicatorsethereum_uncle_rate

[34] J A Donet C P Sola and J H Joancomartı ldquoe bitcoin p2pnetworkrdquo in Proceedings of the International Conference OnFinancial Cryptography and Data Security pp 87ndash102Springer Christ Church Barbados March 2014

[35] G S Davies ldquoBit-booster - offline commit graph drawingtoolrdquo 2016 httpbit-boostercomgraphhtml

[36] N T Courtois and L Bahack ldquoOn subversive miner strategiesand block withholding attack in bitcoin digital currencyrdquo2014 httpsarxivorgabs14021718

[37] I Eyal and E G Sirer ldquoMajority is not enough bitcoin miningis vulnerablerdquo in Proceedings of the International Conferenceon Financial Cryptography and Data Security pp 436ndash454Springer Christ Church Barbados March 2014

[38] Y Kwon D Kim Y Son E Vasserman and Y Kim ldquoBeselfish and avoid dilemmas fork after withholding (faw) at-tacks on bitcoinrdquo in Proceedings Of the 2017 ACM SIGSACConference On Computer and Communications Securitypp 195ndash209 Abu Dhabi UAE April 2017

[39] B Research ldquoDecentralisation governance and eos - a lostcaserdquo 2020 httpsresearchbinancecomenanalysiseos-governance

[40] B Wiki ldquoIrreversible transactions - finney attackrdquo 2012httpsenbitcoinitwikiIrreversible_Transactions∖Finney_attack

[41] J Poon and T Dryja ldquoe bitcoin lightning network scalableoff-chain instant paymentsrdquo 2016

[42] M Bartoletti and L Pompianu ldquoAn analysis of bitcoin op_return metadatardquo in Proceedings of the International Con-ference On Financial Cryptography and Data Securitypp 218ndash230 Springer Sliema Malta April 2017

[43] ldquoReplace by feerdquo 2018 httpsenbitcoinitwikiReplace_by_fee

[44] E Foundation ldquoNode and clientsrdquo 2020 httpsethereumorgendevelopersdocsnodes-and-clients

[45] H Heo and S Shin ldquoBehind block explorers public block-chain measurement and security implicationrdquo in Proceedingsof the 41th IEEE International Conference On DistributedComputing Systems IEEE Washington DC USA In pressWashington DC USA July 2021

[46] R Bowden H P Keeler A E Krzesinski and P G TaylorldquoBlock arrivals in the bitcoin blockchainrdquo 2018 httpsarxivorgabs180107447

[47] M E Crovella and A Bestavros ldquoExplaining world wide webtraffic self-similarityrdquo Technical Report Citeseer PrincetonNJ USA 1995

[48] H Zhang Y Shu and O Yang ldquoEstimation of hurst pa-rameter by variance-time plotsrdquo in Proceedings of the 1997IEEE Pacific Rim Conference on Communications Computersand Signal Processing PACRIM 10 Years Networkingthe Pacific Rim 1987-1997 IEEE Victoria BC CanadaAugust 1997

[49] A Feldmann ldquoCharacteristics of TCP connection arrivalsrdquo inSelf-Similar Network Traffic and Performance EvaluationK Park andWWillinger Eds pp 367ndash399Wiley HobokenNJ USA 2000

[50] RSK ldquoRSKrdquo 2021 httpswwwrskco[51] E Heilman A Kendler A Zohar and S Goldberg ldquoEclipse

attacks on bitcoinrsquos peer-to-peer networkrdquo in Proceedings of

Security and Communication Networks 17

the 24th USENIX Security Symposium pp 129ndash144 Wash-ington DC USA April 2015

[52] Y Marcus E Heilman and S Goldberg ldquoLow-resourceeclipse attacks on ethereumrsquos peer-to-peer networkrdquo IACRCryptology vol 2018 p 236 2018

[53] M Apostolaki A Zohar and L Vanbever ldquoHijacking bitcoinRouting attacks on cryptocurrenciesrdquo in Proceedings of the2017 IEEE Symposium On Security and Privacy (SP)pp 375ndash392 IEEE San Jose CA USA May 2017

[54] M Tran I Choi G J Moon A V Vu and M S Kang ldquoAstealthier partitioning attack against bitcoin peer-to-peernetworkrdquo in Proceedings of the IEEE Symposium On Securityand Privacy (SampP) San Francisco CA USA May 2020

[55] B I Proposal ldquoBip 0152rdquo 2016 httpsenbitcoinitwikiBIP_0152

[56] B Core ldquoBitcoin Core Version 01901 Release Noterdquo 2016httpsbitcoinorgenreleasev01901

[57] ldquoGeth v190rdquo 2019 httpsblogethereumorg20190710geth-v1-9-0

[58] ldquoProtocol documentationrdquo 2016 httpsenbitcoinitwikiProtocoltext_documentation

[59] C Feng and J Niu ldquoSelfish mining in ethereumrdquo in Pro-ceedings of the 2019 IEEE 39th International Conference OnDistributed Computing Systems (ICDCS) pp 1306ndash1316IEEE Dallas TX USA July 2019

[60] G O Karame E Androulaki and S Capkun ldquoDouble-spending fast payments in bitcoinrdquo in Proceedings of the 2012ACM Conference on Computer and Communications Securitypp 906ndash917 Raleigh NC USA October 2012

[61] P Das L Eckey T Frassetto et al ldquoFastkitten practical smartcontracts on bitcoinrdquo in Proceedimgs of the 28th USENIXSecurity Symposium (USENIX Security 19) pp 801ndash818Santa Clara CA USA August 2019

[62] S G Motlagh J Misic and V B Misic ldquoe impact of selfishmining on bitcoin network performancerdquo IEEE Transactionson Network Science and Engineering vol 8 no 1 pp 724ndash7352021

[63] A Muhle A Gruner T Gayvoronskaya and C Meinel ldquoAsurvey on essential components of a self-sovereign identityrdquoComputer Science Review vol 30 pp 80ndash86 2018

[64] M Toorani and C Gehrmann ldquoA decentralized dynamic pkibased on blockchainrdquo in Proceedings Of the 36th Annual ACMSymposium On Applied Computing pp 1646ndash1655 GwangjuKorea March 2021

[65] E foundation ldquoOptimistic-rollupsrdquo 2021 httpsdocsethhubioethereum-roadmaplayer-2-scalingoptimistictext_rollups

[66] ldquoZk-rollupsrdquo 2021 httpsdocsethhubioethereum-roadmaplayer-2-scalingzk-rollups

[67] E foundation ldquoEthereumwire protocolrdquo 2019 httpsgithubcomethereumdevp2pblobmastercapseth

[68] S K Kim Z Ma S Murali J Mason A Miller andM BaileyldquoMeasuring ethereum network peersrdquo in Proceedings of theInternet Measurement Conference 2018 pp 91ndash104 BostonMA USA October 2018

[69] Symmetricom ldquoDelivering sub-microsecond accurate time tolinux applications around the worldrdquo 2012 httpwwwchronoscoukfilespdfswpsWP_AccurateTimeForLinuxApplicationspdf

[70] Ycharts ldquoBlocktrail blockchain data query service (termi-nated)rdquo 2019 httpsblocktrailcom

18 Security and Communication Networks

variables for all block arrival events It shows that thetimestamps are tight as more than 90 of the blocks arrivedwith a time difference less than 100ms Although Bitcoinblock arrivals can be delayed by another block time interval( sim 10 minutes) sim 80 of the blocks are not dispersed bymore than one second EOS blocks show an order-of-magnitude-smaller dispersion in the worst case e longtails implying that block arrival times can be very prolongedin a small number of cases are commonly observed forBitcoin in the literature [32 34]

Consider an ordered arrival timestamp of transaction t

observed at all measurement points M tsi|0le ilt n(M)1113864 1113865

arrival(t)m|forallm isinM where tsi lt tsj for all ilt jlt n(M)Figure 5 shows the distribution of Δ(ts0 ts1) Δ(ts0 ts3) andΔ(ts0 ts7) for Bitcoin transactions Similar to Bitcoin blocksthe long tail shows that the transaction arrival times can bedispersed more than 5 seconds for 5 of the transactions Inthe meantime Δ(ts0 ts1) is tight as more than 99 of thetwo earliest arrivals are not dispersed more than 1 secondEthereum and EOS transactions exhibit much tighterΔ(ts0 ts1) showing that more than 98 of the transactionarrivals are less than 100 milliseconds apart

4 Block and Transaction Discrepancies

In this section we study the discrepancies in blocks andtransactions between the main chain and our observedevents

41 Blockchain Fork As all main chain blocks are observed(ie Bunseen empty) through our measurement the discrep-ancy in blocks only appears as stale blocks (ie Bstale) Anincident of having stale blocks is also called a blockchain forkwhere one or more blocks are appended to a different branchof the main chain

411 Fork Characteristics and Examples A nonoverlappingblockchain fork episode e at block height [m n) is defined byidentifying two blocks

(i) Fork initiating block bf isin Bmain where height(bf)

m and n(children(bf))gt 1(ii) Fork resolving block br isin Bmain where height(br)

n and children(bi) empty for all bi isin Sn

Sn bi|height(bi) n and bi notin Bmain1113864 1113865 Figure 6(a) il-lustrates our fork episode model

We define three characteristic variables (i) its run lengthrun minus length(e) n minus m (ii) the weight (ie the number ofstale blocks in the episode) weight(e) 1113936

nhm(n(Sh)) and

(iii) the fork degree (ie the maximum number of forkbranches) degree(e) maxmlehlen(n(Sh) + 1) Figure 7 showshow characteristic variables are distributed and our findingsare summarized as follows

(i) Due to its long block time (ie sim10minutes) and lowstale block probability (ie lt 005) statisticalcharacterization of Bitcoin fork episodes suffers froma lack of sample events Even three years of live

measurement yield less than a hundred fork episodesas we only expect to observe less than 30 fork eventsper year

(ii) Ethereum fork episodes mostly run one block heightwith a single additional branch e fork degree (iemaximum of branches) is as high as three for sim5 of the episodes and the forks are not immediatelyresolved that is having two or more run lengths inabout 3 of the cases

EOS fork episodes run as long as 12 blocks that is theentire block schedule of a single BP (block producer) [26] asBPs can override the entire block-producing schedule of thepreceding BP

Putting Bitcoin which produces few fork episodes asideEthereum and EOS exhibit very different fork episodepatterns Figure 8 shows two example fork episodes ofEthereum and EOS We have used the commit graphdrawing tool [35] to visualize the fork episodes Figure 8(a)depicts four fork episodes that is [174 176) [177 178)[183 184) and [185 186) of Ethereum and Figure 8(b)shows two EOS fork episodes that is [290 292) and[294 302)e first fork episode [174 176) of Ethereumexhibits the run length of 3 the weight of 4 and the degree of4 with three nonreported (ie thus available only from ourmeasurement) stale blocks e second fork episode[294 302) of EOS exhibits the run length of 9 the weightof 9 and the degree of 2

412 Nonearliest Advertised Block Endorsement of EthereumMiners Our most interesting finding is that Ethereumminers often do not add blocks to the earliest advertisedblock during fork episodes Consider an illustrative forkepisode depicted in Figure 6(b) e episode begins as thethree blocks (ie b1 b2 and b3) are added to the fork ini-tiating block b0 e immediately following blocks (ie bi

and bj) will have their previous blockhash identifying one ofthe three previous blocks of the minerrsquos choice e block bimined by some miner may be added to the earliest block(ie b1) the other block bj is mined by a different miner whochooses a different block (ie b2) to add to To evaluateminersrsquo preference of blocks to which succeeding blocks areadded in the event of blockchain forks we define theconditional probability of miner ma adding a block to aprevious block mined by mb (by not adding to any of adifferent minerrsquos block) in fork episodes for all ma and mb

Pr miner bi( 1113857( mb|miner bj1113872 1113873

ma

prev bj1113872 1113873 bi

existbk height bk( 1113857 height bi( 1113857)

(1)

Figure 9(a) shows a histogram of the above probabilityma (x-axis) adds a block to mbrsquos block (label) over others infork episodes It is apparent that the top ranked minerssignificantly prefer adding blocks to their own mined blocksover other minersrsquo blocks Figure 9(b) depicts the same

6 Security and Communication Networks

bf

br

m

m + 1

n

n + 1

Height

(a)

Time

Arrival (b1)

Arrival (b2)

Arrival (b3)

b0

b1

b2

b3

bi

bj

(b)

Figure 6 Fork analysis model (a) Fork episode (b) Fork resolve example

EthereumEOS

0

02

04

06

08

1

Cum

ulat

ive f

requ

ency

2 4 6 8 10 120 14

Run length

EthereumEOS

0

02

04

06

08

1

Cum

ulat

ive f

requ

ency

2 4 6 8 10 12 140

Weight

EthereumEOS

0

02

04

06

08

1

Cum

ulat

ive f

requ

ency

40 62

Degree

Figure 7 Fork episode characteristics

∆ (ts0 ts1)∆ (ts0 ts3)∆ (ts0 ts7)

0010203040506070809

1Cu

mul

ativ

e fre

quen

cy(

of t

rans

actio

ns)

2 4 6 8 100Time difference (seconds)

(a)

BitcoinEthereumEOS

1 2 3 4 50Time difference (seconds)

0

02

04

06

08

1

Cum

ulat

ive f

requ

ency

( o

f tra

nsac

tions

)

(b)

Figure 5 Transaction arrival time accuracy (a) Transaction arrival time differences of Bitcoin (b) Δ(ts0 ts1) distribution

Security and Communication Networks 7

(a) (b)

Figure 8 Example fork episodes each dot represents a block followed by block hash (last six hexadecimals) arrival time block height (lastthree digits) block timestamp and its miner Each Ethereum stale block is tagged either R (reported uncle) or NR (not reported) Each EOSblock is tagged with the block sequence (out of 12) of the corresponding BPrsquos production schedule (a) Ethereum (b) EOS

SparkPoolEthermine

F2PoolNanopool

MiningPoolHubzhizhutop

Unconditional SparkPool Ethermine F2Pool Nanopool MiningPoolhub

zhizhutop

0

01

02

03

04

05

Freq

uenc

y

(a)

EarliestMixedNonearliest

Spar

kPoo

lEt

herm

ine

F2Po

olN

anop

ool

Min

ingP

oolH

ubzh

izhu

top

UU

Pool

Pand

aMin

erBT

POO

Lxn

pool

Huo

biM

inin

gPoo

lD

war

fPoo

lfir

epoo

lU

nkno

wn

Min

ing

Expr

ess

BTC

com

Pool

Min

eral

lPoo

lBe

ePoo

lH

iveo

nPoo

l2M

iner

sPPL

NS

2Min

ersS

OLO

Coin

otro

nW

POO

LEz

ilPoo

lpo

olin

o

f tot

al fo

rk re

solv

e

(b)

Figure 9 Ethereum fork resolve statistics (a) Probability of ma (x-axis) adding a block to mbrsquos block (b) Probability of adding to the earliestpropagated block

8 Security and Communication Networks

probability by labeling whether or not the chosen block (byma) is the earliest propagated one e ldquoearliestrdquo label in-dicates that the block to which the newly mined block (byma) is added has been observed as the earliest one to arrivecongruently among all eight measurement locations (Asblock arrival times are measured in eight different locationsthe arrival order can be conflicting e ldquomixedrdquo labelrepresents the conflicting cases) For example the topranked pool SparkPool chose the earliest arriving blocksim55 of the time 3409 out of 6234 blocks among the other2825 blocks that were added to nonearliest previous blocksSparkPoolrsquos own blocks were chosen over others 1211 timeswhile other poolsrsquo blocks were preferred to SparkPoolrsquos only24 times In the meantime Nanopool chose the earliest one amajority of the time For the top 25 ranked mining pools onlyfour of them added blocks to the earliest arriving blocks morethan 90 of the timeis contradicts the earliest propagatedblock endorsement assumption that is broadly adopted inmining-related research [36ndash38]

One possible explanation of the phenomenon is that themining pools adopt their own block preferring strategy as asimple precautionary defense against yet unknown selfishmining pools the profitability of selfish mining largelydepends on the probability of honest pools adding to theattacking poolrsquos branch

413 Cut-Tail Fork Pattern of EOS BPs We find that theEOS fork episodes occur in a way that BPs are cutting the tailof the previous BPrsquos produced blocks EOS adopts the DPoSconsensus mechanism [26] 21 block producers (BPs) areelected by voting and scheduled to produce 12 consecutiveblocks in 6 seconds (ie 500ms for each block) in the al-phabetical order of their names Figure 10 shows thenumbers of switching (by schedule) events and cut-tail forkevents of all immediate BP pairs We observe a high fre-quency of such events when bitfinexeos1 is producing blocksby appending to big onersquos blocks while there are accusationsof BPrsquos dishonest behaviors we believe that the reportedbitfinexrsquos performance problem is the compelling reason forthe phenomenon [39]

42 Unseen and Stale Transactions

421 Private Transaction Mining Unseen transactions arecharacterized by the strong evidence that implies that theunseen transactions are indeed never advertised to the net-work Table 6 categorizes 9587 of Ethereum unseentransactions by using the from addresses of the transactions(We use prefixes followed by ⋆ in presenting hash valueseg address (ie pubkey hash) and txid for brevity Weunderstand this does not entirely anonymize identity as thereaders can verify their results against ours by matching theprefixes) Public names are retrieved from Etherscan [16] Aminer is specified in the table only if all blocks that includethe unseen transactions with the from address are con-gruently mined by that single miner It shows that most ofthe unseen transactions are indeed the block minerrsquos owntransactions

Table 7 shows unseen Bitcoin transactions categorized bythe identified reasons sim 67 of the unseen transactions areeither zero-fee transactions or zero-fee-transaction-dependenttransactionsWe define a transaction t isin transactions(b) as adependent transaction if at least one of input transactions oft is included in the same block b

Bitcoin Core [28] implementation does not propagatetransactions with zero transaction fee Also a dependenttransaction cannot be mempooled until the transaction towhich it is dependent is mempooled consequently it cannotbe relayed to peers e Bitcoin Core mempool imple-mentation justifies the inexistence of zero-fee and zero-fee-dependent transactions from our measurement Existence ofa stale transaction which shares the same transaction inputwith the unseen transaction may imply a possible double-spend attempt a variant [40] involving private mining of ablock with ti while advertising a conflict transaction tj suchthat inputs(ti)cap inputs(tj)neempty we have observed 27 suchunseen transactions without a certainty of attack intentionsor if they are not indeed advertised Lastly multisig trans-action inputs often imply off-chain protocols where signedtransactions are exchanged out-of-band [41] and havingOP_RETURN transaction output implies special purposeprotocols of Bitcoin for example sidechains where theirrelationship with miners require further investigation [42]e presence of unseen transactions by either privatetransaction mining or potential out-of-band delivery oftransactions has a subtle security implication One obviousside effect is privatization of transaction fees the transactionfees of privately mined ones are exclusively obtainable by theprivate miner alone unless the network is fully utilized Ifthe network is fully utilized a miner is forced to include herprivate transactions at the expense of not including othertransactions as the block capacity is limited

422 Conflict Stale Transactions Stale transactions arenetwork-transmitted transactions that are not included inany of the blocks

Table 8 shows the stale transaction counts observed ateach location e stale transactions account for 020369 and 047 of Bitcoin Ethereum and EOS transac-tions respectively Ethereum transactions had an order ofmagnitude more chance of being stale than others

As for public blockchains with transaction fees that isBitcoin and Ethereum stale transactions are mostly at-tributable to conflict Table 9 summarizes the identifiedreasons for transactions being stale A stale Bitcoin trans-action is attributable to conflict if there are one or moretransactions sharing at least one transaction input (ie vin)

An Ethereum transaction is attributable to conflict ifthere is another transaction with the same nonce from thesame account A widely known reason for two or moretransactions being in conflict is transaction replacementsuch as replace-by-fee [43] On the other hand slightly morethan 5 of Bitcoin transactions are stale because at least oneof their transaction inputs is also stale

On the other hand roughly one out of ten staleEthereum transactions is attributable to improper ordering

Security and Communication Networks 9

of nonce (e transaction nonce should be equal to thenumber of transactions sent from the address) nonce is toohigh (983) or too low (002) Last but not least 727 ofstale transactions are not included in blocks because theaccount is not sufficiently funded (An Ethereum accountshould have balance ge value+ gastimes gas price to execute thetransaction [44]) An Ethereum account can be

insufficiently funded when executing a transaction for anumber of reasons [45]

423 EOS Transaction Discrepancy EOS exhibits unseenand stale transactions far different from those of Bitcoin orEthereum that is the PoW blockchains with transaction feeEOS software is not bundled with peer discovery rather thenode operator is required to look up for candidate BPrsquospeering services timely delivery of blockchain data andreliability of the node is dependent on the peering nodes ofchoice (Indeed we have experienced service disruption bydisconnecting from peers for unknown reasons)e notionof being conflict in two or more transactions that is themost frequent reason for transactions being stale for Bitcoinand Ethereum is not applicable to EOS (EOS adopts theaccount model without transaction ordering per accountthus there should be no conflict transaction outputs or thesame account nonce) On the other hand EOS requires

eosh

uobi

pool

-eos

infst

ones

eosfl

ytom

ars-

eosh

uobi

pool

zbeo

sbp1

1111

-atti

clab

eosb

attic

labe

osb-

big

one

hoo

com

-new

dex

bpw

hale

exco

m-z

beos

bp11

111

start

eosio

bp-w

hale

exco

meo

sdot

wik

ibp-

eosfl

ytom

ars

eosc

anno

nchn

-eos

dotw

ikib

pbi

gon

e-bi

tfine

xeos

1eo

sinfst

ones

-eos

iom

eeto

nehe

lloeo

scnb

p-ho

oco

meo

slaom

aoco

m-e

ossv

12eo

ssv

slow

mist

iobp

-sta

rteo

siobp

eoss

v12e

ossv

-hel

loeo

scnb

peo

sbei

jingb

p-eo

scan

nonc

hneo

siosg

1111

1-eo

slaom

aoco

meo

siom

eeto

ne-e

osio

sg11

111

bitfi

nexe

os1-

cert

ikeo

sorg

new

dex

bp-s

low

mist

iobp

coch

ainw

orld

-eos

asia

1111

1bi

tfine

xeos

1-co

chai

nwor

ldce

rtik

eoso

rg-c

ocha

inw

orld

eosa

sia11

111-

eosb

eijin

gbp

new

dex

bp-o

kcap

italb

p1eo

siom

eeto

ne-e

osla

omao

com

okca

pita

lbp1

-slo

wm

istio

bpco

chai

nwor

ld-e

osbe

ijing

bpne

wde

xbp

-sta

rteo

siobp

eosa

sia11

111-

eosc

anno

nchn

eosla

omao

com

-hel

loeo

scnb

pco

chai

nwor

ld-e

osca

nnon

chn

cert

ikeo

sorg

-eos

beiji

ngbp

eoss

v12e

ossv

-hoo

com

bitfi

nexe

os1-

eosa

sia11

111

eosin

fston

es-e

osla

omao

com

okca

pita

lbp1

-sta

rteo

siobp

BP switching (left)Cut-tail (right)

0

5000

10000

15000

20000

25000

BP sw

itchi

ng ev

ents

0

100

200

300

400

500

cu

t-tai

l eve

nts

Figure 10 EOS BP switching and cut-tail events

Table 6 Ethereum unseen transactions

From address Public name Transaction count Miner0xea67⋆ Ethermine 128145 (7242) Ethermine0x2a65⋆ DwarfPool 22955 (1297) DwarfPool0x8fd0⋆ Unknown 11346 (641) SparkPool0x829b⋆ F2Pool 4453 (251) F2Pool0x4c54⋆ HiveonPool 1135 (064) SparkPool0x99c8⋆ BeePool 468 (026) BeePool0xdba7⋆ Unknown 348 (020) UUPool0x464b⋆ FKPool 340 (019) FKPool0xf687⋆ Unknown 217 (012) AntPool0xa801⋆ Unknown 151 (009) AntPool0xbe7c⋆ Unknown 126 (007) AntPool0xb96f⋆ Unknown 101 (006) AntPool

Sum 169785 (9587)

Table 7 Bitcoin unseen transactions

Category Transactioncount

Zero-fee transaction 148 (5068)Zero-fee-transaction-dependent transaction 48 (1644)Multisig transaction input 43 (1473)Conflict with stale transaction 27 (925)OP_RETURN transaction output 26 (890)Sum 292 (10000)

10 Security and Communication Networks

contract users to stake tokens for CPU time that can bededucted by transaction executions A requested transactioncan be rejected thus being stale due to the lack of CPU timeor other resources similarly Replaying the entire statechanges of EOS to find out stale transactions due to lack ofresources is not possible unless all transaction and state logsof the entire BPs are available

On the other hand EOS transactions have two additionalattributes which are not available in the Bitcoin or Ethereumtransaction structures

(i) Reference block every EOS transaction refers to ablock by specifying the block number and hash notonly to prevent replay attacks but also to signal thenetwork that the userrsquos stake is on a specific fork

(ii) Expiration time EOS transactions have explicitexpiration times

If a transactionrsquos reference block is not part of the mainchain at the time of execution the transaction cannot beexecuted (and thus cannot be included in a block) We haveidentified that 18 of stale transactions apply to this case Tofurther identify unknown reasons we consider four timedevents that are relevant to transaction execution

(i) Last irreversible block arrival time arrival(blib) thearrival time of transactionrsquos reference block EOStransactions by default refer to the last irreversibleblock (LIB) [26]

(ii) Head block arrival time arrival(bhead) the scheduledtime of the head block when transaction is arrived

(iii) Transaction arrival time arrival(t) the arrival timeof transaction t

(iv) Expiration time exp(t) the expiration time oftransaction t

e three time differences that is Δexp Δincl and Δtrxare investigated to find characteristics of unseen (Tunseen)and stale (Tstale) transactions over the normal transactions(Tincluded) Figure 11 illustrates the relevant events and timedifferences of them Δexp measures the time difference be-tween the two scheduled (ie virtually timed) events Δincland Δtrx are defined by the arrival events to our monitornode Figure 12 shows the distributions of Δexp Δincl andΔtrx We find that unseen transactions have prolonged Δinclimplying that the delay of newly produced blocks can causenewly generated transactions not promptly delivered be-cause the sync manager is in the Head Catch-Up mode astransactions are only transferred in In-Sync mode by itsdesign [24] Stale transactions with relatively small Δtrx canbe attributable to problematic dApp implementations re-ferring to non-LIB blocks the chain instability caused byblockchain fork mostly due to the cut-tail behavior shown inSection 41 can cause transactions being rejected for im-mature block reference

However we do not find any reason attributable to thetransaction expiration Although the unseen transactionstend to have smallΔexp the expiration times are only as smallas 30 seconds (ie the default expiration time) Particularlyone or more EOS applications set the expiration time to180 seconds (other than the default 30 seconds) and morethan half of the stale transactions are invoked by thoseapplications

While transaction is the smallest unit of execution inBitcoin and Ethereum the unit of contract execution in EOSis action [24] A transaction consists of one or more actionsHowever the constituent actions in a single transactioncannot be separately advertised or executed accordingly weapply the identical transaction model to EOS without loss ofgenerality

5 Block and TransactionArrival Characteristics

51 Arrival Processes All three blockchains we study in thispaper are designed to publish capacity constrained blocks intargeted regular time intervals An incarnation of suchdesign is expected to exhibit a Poisson block arrival processWhile it is claimed that Bitcoin block arrivals do not entirelyexhibit a homogeneous Poisson process due to its difficultadjustment mechanism [46] transaction arrival processes ofblockchains are not studied in the literature to the best of ourknowledge A particularly meaningful step toward under-standing the arrival process of events generated by a complexsystem is examining if the arrival events are independent orexhibiting a correlated structure [47]

e variance-time log-log plots [48] of the block andtransaction arrival event time series are depicted in

Table 8 Stale transactions

Region Bitcoin Ethereum EOSAsia-East 41720 1170706 mdashAsia-South 41653 1194018 504277Europe-North 41693 1192435 470480Europe-West 41668 1123680 450140North America-Northeast 41703 1212210 588711US-Central 41683 1212389 505160US-East 41692 1186488 mdashUS-West 41672 1167627 480207Combined 42023 1351847 672999

Table 9 Identified reasons of stale transactions

Category Transaction count(a) Bitcoin

Conflict 39408 (9378)Stale transaction input 2307 (549)Conflict and stale transaction input 308 (073)Sum 42023 (10000)

(b) EthereumConflict 1208588 (8924)Nonce (skipped) 133161 (983)Nonce (used) 251 (002)Insufficient fund 9847 (727)Sum 1351847 (9982)

(c) EOSFork 12106 (180)Others 660893 (9820)Sum 672999 (10000)

Security and Communication Networks 11

Figure 13(a) As regards the block arrival processes Bitcoinblock arrivals exhibit a linear slope β minus23 e estimatedHurst parameter H 1 + β2 43 implies that the processis not a homogeneous Poisson process but LRD (Long-Range Dependent) contrary to what is expected for a regularinterval event generation [46] Ethereum block arrivalsapproximate the Bitcoinrsquos except for the high aggregationlevel due to high stale block rate EOS block arrivals incontrast follow the slope β minus1 in the low aggregation levelas the block generation is indeed regularly scheduled

Figure 14 shows the variance-time plot of Ethereum andEOS block arrival time series by taking all block arrivalevents (Bobs) and main chain block arrivals only (Bmain) Weconfirm that Ethereum block arrivals indeed exhibit astraight line (close to Bitcoin) if excluding stale blocksHowever EOS block arrivals do not exhibit a straight line

even if we exclude stale blocks due to delayed burst blockarrivals possibly due to cut-tail fork patterns (see Section41)

e transaction arrival processes of all three blockchainsappear to exhibit LRD with Hurst parameter Hgt 56 asβltminus13 To further identify analytical distributions that fitbest the empirical ones the coefficient of variation (σμ) andskewness (ie the standardized third moment) of transac-tion interarrival times are computed for every measurementdataset and compared to the relationships expected for theexponential lognormal Weibull and Gamma distributionsin Figure 13(b) We find that Bitcoin Ethereum and EOStransaction interarrival times are fit best Gamma Weibulland lognormal distribution respectively Individual datasetsare also examined for the fitness of the distribution to findthat the empirical distribution fits the analytical distribution

Virtualclock

Time

Transaction initiator

Time

Blockproducer

Time

Monitornode

Time

Scheduled block time of blib

Scheduled block time of bhead

Scheduled block time of bincl

1 Produce and propagate blib

2 Produce and propagate bhead

Expiration time of t

4 Produce and propagate bincl

Δexp

Δtrx

Δincl

3 Create and propagate t

Figure 11 EOS transaction analysis model

Tincluded

Tstale

Tunseen

0010203040506070809

1

Cum

ulat

ive f

requ

ency

100 200 300 400 5000Time difference (seconds)

(a)

Tincluded

Tunseen

01 1 10 100 1000001Time difference (seconds)

0010203040506070809

1

Cum

ulat

ive f

requ

ency

(b)

Tincluded

Tstale

0010203040506070809

1

Cum

ulat

ive f

requ

ency

01 1 10 100 1000001Time difference (seconds)

(c)

Figure 12 EOS transaction timing analysis (a) Δexp (b) Δincl (c) Δtrx

12 Security and Communication Networks

well except for the small interarrival time ranges For ex-ample Figure 15 depicts the CDF of Ethereum transactioninterarrival times observed in US-West Although the em-pirical distribution fits Weibull with parameters computedwith the maximum likelihood estimator [49] sample pointsunder several milliseconds appear to be unreliable (We areyet unaware of the reason However it is known that thetime source of commodity operating systems is not accurateand we need an external time source for accurate sub-millisecond timing measurement [50])

52AdvertisementRedundancy Bitcoin and Ethereum nodepieces of software are implemented to maintain a large

number of peer connections with multiple random remotenodes Bitcoin Core can connect up to 125 peers where 8 ofthem are outbound connections Go Ethereum maintains 50peer connections where 16 of them are outbound by default(see Table 1) On the other hand partitioning attacks aredeveloped to isolate a blockchain node from the others bytampering with all such peer connections Partitioning at-tacks usually exploit vulnerable peer management mecha-nisms of Bitcoin [51] and Ethereum [52] Such attacks arealso examined in the context of ISPrsquos BGP hijacking [53] anda stealthier variant relieving the attacker from the risk ofgetting exposed [54] e attacks often rely on imple-mentation vulnerabilities for efficient eclipsing of peerswhile known vulnerabilities are getting addressed for ex-ample the lack of parallel block download sessions causing

Slope = ndash1

Trx BitcoinTrx EthereumTrx EOS

Blk BitcoinBlk EthereumBlk EOS

ndash12

ndash10

ndash8

ndash6

ndash4

ndash2

0Lo

g no

rmal

ized

var

ianc

e

124 6 10 140 2 8Aggregation level

(a)

Lognormal

Weibull

Gamma

Exponential

BitcoinEthereumEOS

0

5

10

15

20

Stan

dard

ized

third

mom

ent

1 2 3 40Coefficient of variation

(b)

Figure 13 Transaction arrival characteristics (a) Variance-time plot of block and transaction arrivals (b) Cov versus skewness oftransaction interarrival times

Ethereum - Bobs

Ethereum - Bmain

EOS - Bobs

EOS - Bmain

ndash12

ndash10

ndash8

ndash6

ndash4

ndash2

0

Log

norm

aliz

ed v

aria

nce

2 4 6 8 10 12 140Aggregation level

Figure 14 Variance-time plot of block arrivals including staleblocks (Bobs) and excluding stale blocks (Bmain)

EmpiricalExponential μ = 0024

Lognormal μ = 00354 σ2 = 00486Pareto k = 0000212 a = 0231Weibull c = 0589 a = 00147

00001 0001 001 01 1000001Time (seconds)

0

02

04

06

08

1

Cum

ulat

ive f

requ

ency

Figure 15 Empirical and fitted analytical distributions of Ether-eum transaction interarrival times

Security and Communication Networks 13

temporary denial of blocks (reported in [27] and fixed byrecommending three concurrent download sessions in [55])let attackers successfully partition the node without eclipsingall peer connections [53] A simple countermeasure of in-creasing the number of peer connections on the other handis applied to the reference public blockchain implementa-tions [56 57] to inflate attack complexity

We investigate the degree of a peerrsquos advertisementredundancy on newly generated blocks and transactions toevaluate the efficacy of partitioning attacks and the coun-termeasure of increasing the number of peer connectionsFigure 16 shows how redundantly newly generated blockinformation is offered by peers Bitcoin nodes have main-tained sim43 peer connections that is 8 outbound and ad-ditional 35 inbound connections on average and Ethereumnodes record all 50 peer connections established during theentire observation period

For each newly generated block one-third of peersadvertised the block header to our Bitcoin node and morethan 90 of Ethereum peers signaled availability of theblocks In consequence successfully partitioning a noderequires compromise of peers proportional to the totalnumber of peer connections Increasing the number of peerconnections will burden the attacker linearly as expected

Figure 17 shows how redundantly the newly generatedtransaction information is offered by peers While one out ofthree Bitcoin peers also advertises new transactions viaINVENTORYmessage [58] half of the Ethereum peers havesent new transactions to our node in average Bitcoin andEthereum blocks are advertised with the block header(rather than the direct delivery of all block contents) Bitcointransactions are also advertised with INVENTORY messagebefore the whole contents are transferred HoweverEthereum transaction data that is the entire contents aredirectly sent by peers (Ethereum now has a pooled trans-action delivery model in its newer ETH64 protocol [30])We also find that there are cases with much less advertisedtransactions and have identified that they are indeed mostlystale ones stale transactions are mostly due to conflict (seeSection 42) and the nodes that already queued the conflicttransaction will not relay the stale one

6 Discussion

61 Implication on Mining Attacks Cryptocurrency mininghas been a popular subject in assessing the security ofBitcoin selfish mining [37] block withholding attack [36]and a mixed strategy [38] have been studied Although it isshown that selfish behavior in mining is always moreprofitable than being honest without need for a mutualagreement of not attacking each other [38] we find thatselfish mining is not the preferred strategy All selfish miningstrategies will result in blockchain forks but we observe avery low fork probability (ie 004) for Bitcoin On theother hand selfish mining on Ethereum has been studiedonly recently to unanimously claim that selfish mining isalso profitable for Ethereum miners however it is lessprofitable than Bitcoin due to its uncle reward system [59]Our result in Section 4 shows that a majority of Ethereum

miners choose to add to their own produced blocks over theearliest propagated blocks How does this affect the selfishmining strategy

e selfish mining strategy assumes a parameter c whichdefines the fraction of honest minersrsquo mines on the attackerrsquosfork branch (e parameter comes into play in case (f ) of[27]) If the attacking pool has a network-wise superiorposition in block propagation (ie cgt 05) the selfishmining strategy is profitable for pools with proportionalmining power αgt 25 [37] Absolute network inferiority(ie c 0 due to a defensive mining strategy such as the onepresented in Section 41) increases the required miningpower to 33 the 33 mining power appears to be sig-nificantly harder to achieve in the real world [20]

As for the FAW (Fork-After-Withholding) attackstrategy [38] the network capability parameter C defines theprobability that an attackerrsquos FPoW (Full Proof-of-Work)block (during infiltration mining) is selected as a main chainblock C affects both the attack reward and whether theminerrsquos dilemma holds or not in the mutual attacking gameAs an example case (Section 9 of [38]) of a two-pool gamebetween F2Pool and BitFury the absolute network inferi-ority drops C from 0914 to 03 to make it a dilemmatic gameagain Unfortunately minersrsquo own block preferences cannotbe directly transferred to a single parameter of c or C it callsfor a model change from previous mining studies

62 Conflict Transactions and Double-Spending AttacksDouble-spending attacks have been studied in the context ofBitcoin fast payments where zero or only one confirmation isrequired to complete an offline merchandise transaction[60] real-world cases where two conflict transactions dis-parately arrive at different measurement locations mayimply such attacks Table 10 shows the cases where twotransactions are in conflict (and thus only one of themis included in a block ie inputs(ti)cap inputs(ts)neemptyand existb isin Bmain ti isin transactions(b) (∄b isin Bmain ts isintransactions(b) is indisputable given a consistent transactionledger)) and two different subsets of the monitors havemempooled either one of them We also have identified 27unseen transactions implying possible one-confirmationattack variant requiring the private mining (ie not ad-vertising the double-spending transaction to the network) in

5 10 15 20 25 30 35 40 45 500 of peers

0

005

01

015

02

025

Freq

uenc

y

BitcoinEthereum

Figure 16 Peer redundancy of block advertisement

14 Security and Communication Networks

Section 42 As for the countermeasure of such attacks bydeploying monitors [60] deployment of 8 monitors in thenetwork to detect the attacks would fail at most 27 out of 95times (sim30) assuming that those 27 unseen transactionswe have identified are initially advertised to the network

63 Potential Impact on Blockchain ApplicationsEthereum and EOS are the most widely used smart contractplatforms fostering various decentralized applications Bit-coin which lacks the capability of executing complex smartcontract codes is also recently utilized to execute smartcontracts for decentralized applications [50 61] Eventhough our work focuses on the fundamental blockchainmechanisms in terms of transactionblock production andpropagation the impact of our findings on decentralizedapplications can be foresighted

According to our blockchain fork results (Section 41)the lack of selfish mining in the real world was speculated bya very low stale block rate of Bitcoin network and prevalenceof nonearliest block endorsement by Ethereum miners Asprofitability of selfish mining encourages miners to behavein a way of producing more blockchain forks the perfor-mance degradation is proportionate to the number of minerswho adopt the selfish mining strategy the key performancemetrics affecting the blockchain application performance

such as node response time or block delivery time are shownto be noticeably degraded due to the selfish mining [62] Forexample decentralized identities issued or revoked on suchblockchains [63 64] cannot be responsively finalized due toinflated blockchain forks Our results show that the selfishmining is not prevalent in the real world thus the appli-cation performance impact is overrated even though it istheoretically shown that miners have every reason to beselfish [38] As for EOS we reported cases where a sequenceof (up to 12) blocks being stale are often observed in suc-cessive mining of two BPs however the rate is too low (ie004) to impact the performance of applications (Section32)

Transaction arrival processes being LRD (Section 51)pose a technical challenge in provisioning transactionprocessing scalability especially for Layer-2 blockchain ap-plication solutions [65 66] For example Layer-2 rollupsolutions require transaction relays which aggregate indi-vidual user transactions of a given blockchain applicationdeployed in the network often without a priori knowledge ofnetwork load One way of solving the problem is a properprioritization of transactions based on the applicationcontext

Lastly blockchain network partitioning can be thebiggest concern for blockchain service providers We ob-served that the increased numbers of peer connections inblockchain reference implementations effectively provide ahigher degree of information redundancy (Section 52)However increased number of peer connections can beexploitable for an attacker who has a denial-of-service attackvector or an invalid transaction initiated by a simple ap-plication bug can flood the network [45]

64 Limitation Our measurement study has several limi-tations First of all our results may only capture only a fewmonths of blockchain network operations In the meantimethe permissionless blockchain pieces of software are in activedevelopment for example Ethereum now utilizes the pooledtransaction delivery [67] instead of unsolicited transactiondelivery which was the only mode at the time of our

Table 10 Bitcoin disparately mempooled transactions

monitors mempooledti

monitors mempooledts

Transactioncount

7 1 26 (3824)6 2 14 (2059)5 3 10 (1471)4 4 5 (735)3 5 5 (735)2 6 3 (441)1 7 3 (441)5 1 1 (147)6 1 1 (147)

Sum 68 (10000)

Tincluded

Tstale

5 10 15 20 25 30 35 40 45 500 of peers

0

005

01

015

02

025

03Fr

eque

ncy

(a)

Tincluded

Tstale

0002004006008

01012014016

Freq

uenc

y

4030 500 10 20 of peers

(b)

Figure 17 Peer redundancy of transaction advertisement (a) Bitcoin (b) Ethereum

Security and Communication Networks 15

measurement Both cryptocurrency market values andblockchain network utilizations are rapidly increasing andthus miners are getting more motivated to optimize theirperformance for example Bitcoin fork probability has be-come far smaller than what is reported previously (seeSection 41)

Second the blockchain state information is not collected inour measurement Our analysis is performed based on onlyavailable information stored in block and transaction logs Wehave utilized an Ethereum archive node [44] to query historicalstate information (eg account balance or account nonce) inSection 42 However such proactive state replication is farmore complicated with EOS unless the full node is configuredto operate as a producing node and logging the state infor-mation thus EOS stale transactions could not be fully un-derstood without the missing EOS network state information

7 Related Work

71 Blockchain Data Analysis Historical transaction data ofBitcoin have often been studied for economic aspects such ascryptocurrency abuse [17] anti-money-laundering [18] andmonetary flow of businesses [19] However historicalblockchain data usually available from block explorer ser-vices are not sufficient for our research purpose

72 Blockchain Measurement Researchers have performedblockchain measurement studies to assess the degree ofdecentralization [20] to investigate demographic informa-tion of network nodes [34 68] to study mining pool be-havior [22] and to evaluate security of PoW blockchains [21]against known attacks such as double-spending attack [60]and selfish mining [37] Our work expands the under-standing of previous security evaluations with the keyfindings acquired from our large-scale transaction and blockmeasurement

73 Blockchain Attacks Partitioning attacks usually exploitvulnerable peer management mechanisms of Bitcoin [51]and Ethereum [52] Such attacks are also examined in thecontext of ISPrsquos BGP hijacking [53] and a stealthier variantrelieving the attacker from the risk of getting exposed [54]Cryptocurrency mining has been a popular subject inassessing the security of Bitcoin selfish mining [37] blockwithholding attack [36] and a mixed strategy [38] have beenstudied Double-spending attacks have been studied in thecontext of Bitcoin fast payments [60]

74 Block Explorer Services We have surveyed the popularblock explorer services of Bitcoin [5 10 12] Ethereum[10 13 16] and EOS [11 14 15] to see the availability ofinformation beyond what is recorded in the main chainblock data we have utilized in our study namely

(i) Stale blockstransactions no Bitcoin and EOS blockexplorers provide stale block information (A relatedstudy [36] has utilized a Bitcoin block explorer service[68] to retrieve stale blocks However the service has

been terminated in March 2019) All Ethereum blockexplorers provide only reported stale blocks (ie uncleblocks [23]) (Ethereum provides incentives for unclestale blocks [44] so that miners include them in theirmined blocks for profit)No block explorers provide stale transaction infor-mation unless one is currently pooled

(ii) Blocktransaction arrival times all block explorersprovide block timestamps that are recorded in theblock headers not the actual times of arrival Ourblockchain fork and gap analysis require measuredblock arrival times at multiple locations All blockexplorers show transaction timestamps identical to theblock timestamp to which the transactions belong(Recent Bitcoin transactions have different timestampsthan the block timestamps in [4] while the timestampsare only at a granularity of one minute) [69 70]

8 Conclusion

We have measured transaction and block arrival events ofthe three permissionless blockchains We have devised anoble analysis model and analyzed completeness of ourblock and transaction logs Finally we have studied thediscrepancy in measured events and arrival characteristics toshare our key findings including a false universal assumptionof previous mining-related studies

Data Availability

e measurement data used to support the findings of thisstudy have not been made available because they containprivate information that can be used to identify individualblockchain nodes

Disclosure

is is an extended and revised version of a conference paperpresented in IEEE ICDCS 2021 [41]

Conflicts of Interest

e authors declare that they have no conflicts of interest

Acknowledgments

e authors would like to thank Seungwon Woo DaegeunYoon and Changhyun Lee for helping them with themeasurement instrumentation is work was supported byElectronics and Telecommunications Research Institute(ETRI) grant funded by the Korean Government (21ZR1300Research on Intelligent Cyber Security and Trust Infra)

References

[1] S Nakamoto ldquoBitcoin a peer-to-peer electronic cash systemrdquo2019

[2] V Buterin ldquoEthereum white paperrdquo 2013 httpsethereumorgenwhitepaper

[3] Monero ldquoMonerordquo 2020 httpswebgetmoneroorg

16 Security and Communication Networks

[4] bitcoincashorg httpswwwbitcoincashorg[5] Blockchaincom httpswwwblockchaincom[6] Ripple ldquoXRP e best digital asset for global paymentsrdquo

2020 httpsripplecomxrp[7] I Foundation ldquoIotardquo 2021 httpswwwiotaorg[8] ldquoEosiordquo 2020 httpseosio[9] S Orsquoneal ldquoEos proves yet again that decentralization is not its

priorityrdquo 2018 httpscointelegraphcomnewseos-proves-yet-again-that-decentralization-is-not-its-priority

[10] Blockchair httpsblockchaircom[11] Bloksio httpsbloksio[12] BTCcom ldquoBitcoin block explorerrdquo 2021 httpsbtccom[13] Ethereum block explorer httpsethbtccom[14] eosflareio Eos block explorer httpseosflareio[15] EOSPark ldquoEos block explorerrdquo 2021 httpseosparkcom[16] Etherscan Ethereum explorer httpsetherscanio[17] S Lee C Yoon and H Kang ldquoCybercriminal minds An

investigative study of cryptocurrency abuses in the dark webrdquoin Proceedings of the Network and Distributed System SecuritySymposium pp 1ndash15 Internet Society San Diego CA USAFebruary 2019

[18] MMoser R Bohme and D Breuker ldquoAn inquiry into moneylaundering tools in the bitcoin ecosystemrdquo in Proceedings ofthe 2013 APWG eCrime Researchers summit pp 1ndash14 IEEESan Francisco CA USA September 2013

[19] M Lischke and B Fabian ldquoAnalyzing the bitcoin network thefirst four yearsrdquo Future Internet vol 8 no 1 2016

[20] A E Gencer S Basu I Eyal R V Renesse and E G SirerldquoDecentralization in bitcoin and ethereum networksrdquo inProceedings of the International Conference On FinancialCryptography and Data Security pp 439ndash457 SpringerNieuwport Curaccedilao February 2018

[21] A Gervais G O Karame KWust V Glykantzis H Ritzdorfand S Capkun ldquoOn the security and performance of proof ofwork blockchainsrdquo in Proceedings Of the 2016 ACM SIGSACConference on Computer and Communications Securitypp 3ndash16 Vienna Austria October 2016

[22] C Wang X Chu and Q Yang ldquoMeasurement and analysis ofthe bitcoin networks a view from mining poolsrdquo 2019httpsarxivorgabs190207549

[23] G Wood ldquoEthereum A secure decentralised generalisedtransaction ledgerrdquo Ethereum Project Yellow Paper vol 1512014

[24] ldquoTransactions protocol eosio developer docsrdquo 2018 httpsdeveloperseosiowelcomev20protocoltransactions_protocol

[25] Y Sompolinsky and A Zohar ldquoSecure high-rate transactionprocessing in bitcoinrdquo in Proceedings of the InternationalConference On Financial Cryptography and Data Securitypp 507ndash527 Springer San Juan PR USA January 2015

[26] Blockone ldquoConsensus protocolrdquo 2018 httpsdeveloperseosiowelcomev20protocolconsensus_protocol

[27] A Gervais H Ritzdorf G O Karame and S CapkunldquoTampering with the delivery of blocks and transactions inbitcoinrdquo in Proceedings Of the 22nd ACM SIGSAC ConferenceOn Computer and Communications Security pp 692ndash705Denver CO USA October 2015

[28] ldquoGithub Bit coinrdquo 2020 httpsgithubcombitcoinbitcoin[29] G Ethereum ldquoGo ethereumrdquo 2020 httpsgithubcom

ethereumgo-ethereum[30] Google ldquoGoogle cloudrdquo 2021 httpscloudgooglecom[31] ldquoHow to replay from a snapshotrdquo 2018 httpsdeveloperseos

iomanualseoslatestnodeosreplayshow-to-replay-from-a-snapshot

[32] C Decker and R Wattenhofer ldquoInformation propagation inthe bitcoin networkrdquo in Proceedings of the IEEE P2P 2013Proceedings pp 1ndash10 IEEE Trento Italy September 2013

[33] ldquoEthereum uncle raterdquo 2020 httpsychartscomindicatorsethereum_uncle_rate

[34] J A Donet C P Sola and J H Joancomartı ldquoe bitcoin p2pnetworkrdquo in Proceedings of the International Conference OnFinancial Cryptography and Data Security pp 87ndash102Springer Christ Church Barbados March 2014

[35] G S Davies ldquoBit-booster - offline commit graph drawingtoolrdquo 2016 httpbit-boostercomgraphhtml

[36] N T Courtois and L Bahack ldquoOn subversive miner strategiesand block withholding attack in bitcoin digital currencyrdquo2014 httpsarxivorgabs14021718

[37] I Eyal and E G Sirer ldquoMajority is not enough bitcoin miningis vulnerablerdquo in Proceedings of the International Conferenceon Financial Cryptography and Data Security pp 436ndash454Springer Christ Church Barbados March 2014

[38] Y Kwon D Kim Y Son E Vasserman and Y Kim ldquoBeselfish and avoid dilemmas fork after withholding (faw) at-tacks on bitcoinrdquo in Proceedings Of the 2017 ACM SIGSACConference On Computer and Communications Securitypp 195ndash209 Abu Dhabi UAE April 2017

[39] B Research ldquoDecentralisation governance and eos - a lostcaserdquo 2020 httpsresearchbinancecomenanalysiseos-governance

[40] B Wiki ldquoIrreversible transactions - finney attackrdquo 2012httpsenbitcoinitwikiIrreversible_Transactions∖Finney_attack

[41] J Poon and T Dryja ldquoe bitcoin lightning network scalableoff-chain instant paymentsrdquo 2016

[42] M Bartoletti and L Pompianu ldquoAn analysis of bitcoin op_return metadatardquo in Proceedings of the International Con-ference On Financial Cryptography and Data Securitypp 218ndash230 Springer Sliema Malta April 2017

[43] ldquoReplace by feerdquo 2018 httpsenbitcoinitwikiReplace_by_fee

[44] E Foundation ldquoNode and clientsrdquo 2020 httpsethereumorgendevelopersdocsnodes-and-clients

[45] H Heo and S Shin ldquoBehind block explorers public block-chain measurement and security implicationrdquo in Proceedingsof the 41th IEEE International Conference On DistributedComputing Systems IEEE Washington DC USA In pressWashington DC USA July 2021

[46] R Bowden H P Keeler A E Krzesinski and P G TaylorldquoBlock arrivals in the bitcoin blockchainrdquo 2018 httpsarxivorgabs180107447

[47] M E Crovella and A Bestavros ldquoExplaining world wide webtraffic self-similarityrdquo Technical Report Citeseer PrincetonNJ USA 1995

[48] H Zhang Y Shu and O Yang ldquoEstimation of hurst pa-rameter by variance-time plotsrdquo in Proceedings of the 1997IEEE Pacific Rim Conference on Communications Computersand Signal Processing PACRIM 10 Years Networkingthe Pacific Rim 1987-1997 IEEE Victoria BC CanadaAugust 1997

[49] A Feldmann ldquoCharacteristics of TCP connection arrivalsrdquo inSelf-Similar Network Traffic and Performance EvaluationK Park andWWillinger Eds pp 367ndash399Wiley HobokenNJ USA 2000

[50] RSK ldquoRSKrdquo 2021 httpswwwrskco[51] E Heilman A Kendler A Zohar and S Goldberg ldquoEclipse

attacks on bitcoinrsquos peer-to-peer networkrdquo in Proceedings of

Security and Communication Networks 17

the 24th USENIX Security Symposium pp 129ndash144 Wash-ington DC USA April 2015

[52] Y Marcus E Heilman and S Goldberg ldquoLow-resourceeclipse attacks on ethereumrsquos peer-to-peer networkrdquo IACRCryptology vol 2018 p 236 2018

[53] M Apostolaki A Zohar and L Vanbever ldquoHijacking bitcoinRouting attacks on cryptocurrenciesrdquo in Proceedings of the2017 IEEE Symposium On Security and Privacy (SP)pp 375ndash392 IEEE San Jose CA USA May 2017

[54] M Tran I Choi G J Moon A V Vu and M S Kang ldquoAstealthier partitioning attack against bitcoin peer-to-peernetworkrdquo in Proceedings of the IEEE Symposium On Securityand Privacy (SampP) San Francisco CA USA May 2020

[55] B I Proposal ldquoBip 0152rdquo 2016 httpsenbitcoinitwikiBIP_0152

[56] B Core ldquoBitcoin Core Version 01901 Release Noterdquo 2016httpsbitcoinorgenreleasev01901

[57] ldquoGeth v190rdquo 2019 httpsblogethereumorg20190710geth-v1-9-0

[58] ldquoProtocol documentationrdquo 2016 httpsenbitcoinitwikiProtocoltext_documentation

[59] C Feng and J Niu ldquoSelfish mining in ethereumrdquo in Pro-ceedings of the 2019 IEEE 39th International Conference OnDistributed Computing Systems (ICDCS) pp 1306ndash1316IEEE Dallas TX USA July 2019

[60] G O Karame E Androulaki and S Capkun ldquoDouble-spending fast payments in bitcoinrdquo in Proceedings of the 2012ACM Conference on Computer and Communications Securitypp 906ndash917 Raleigh NC USA October 2012

[61] P Das L Eckey T Frassetto et al ldquoFastkitten practical smartcontracts on bitcoinrdquo in Proceedimgs of the 28th USENIXSecurity Symposium (USENIX Security 19) pp 801ndash818Santa Clara CA USA August 2019

[62] S G Motlagh J Misic and V B Misic ldquoe impact of selfishmining on bitcoin network performancerdquo IEEE Transactionson Network Science and Engineering vol 8 no 1 pp 724ndash7352021

[63] A Muhle A Gruner T Gayvoronskaya and C Meinel ldquoAsurvey on essential components of a self-sovereign identityrdquoComputer Science Review vol 30 pp 80ndash86 2018

[64] M Toorani and C Gehrmann ldquoA decentralized dynamic pkibased on blockchainrdquo in Proceedings Of the 36th Annual ACMSymposium On Applied Computing pp 1646ndash1655 GwangjuKorea March 2021

[65] E foundation ldquoOptimistic-rollupsrdquo 2021 httpsdocsethhubioethereum-roadmaplayer-2-scalingoptimistictext_rollups

[66] ldquoZk-rollupsrdquo 2021 httpsdocsethhubioethereum-roadmaplayer-2-scalingzk-rollups

[67] E foundation ldquoEthereumwire protocolrdquo 2019 httpsgithubcomethereumdevp2pblobmastercapseth

[68] S K Kim Z Ma S Murali J Mason A Miller andM BaileyldquoMeasuring ethereum network peersrdquo in Proceedings of theInternet Measurement Conference 2018 pp 91ndash104 BostonMA USA October 2018

[69] Symmetricom ldquoDelivering sub-microsecond accurate time tolinux applications around the worldrdquo 2012 httpwwwchronoscoukfilespdfswpsWP_AccurateTimeForLinuxApplicationspdf

[70] Ycharts ldquoBlocktrail blockchain data query service (termi-nated)rdquo 2019 httpsblocktrailcom

18 Security and Communication Networks

bf

br

m

m + 1

n

n + 1

Height

(a)

Time

Arrival (b1)

Arrival (b2)

Arrival (b3)

b0

b1

b2

b3

bi

bj

(b)

Figure 6 Fork analysis model (a) Fork episode (b) Fork resolve example

EthereumEOS

0

02

04

06

08

1

Cum

ulat

ive f

requ

ency

2 4 6 8 10 120 14

Run length

EthereumEOS

0

02

04

06

08

1

Cum

ulat

ive f

requ

ency

2 4 6 8 10 12 140

Weight

EthereumEOS

0

02

04

06

08

1

Cum

ulat

ive f

requ

ency

40 62

Degree

Figure 7 Fork episode characteristics

∆ (ts0 ts1)∆ (ts0 ts3)∆ (ts0 ts7)

0010203040506070809

1Cu

mul

ativ

e fre

quen

cy(

of t

rans

actio

ns)

2 4 6 8 100Time difference (seconds)

(a)

BitcoinEthereumEOS

1 2 3 4 50Time difference (seconds)

0

02

04

06

08

1

Cum

ulat

ive f

requ

ency

( o

f tra

nsac

tions

)

(b)

Figure 5 Transaction arrival time accuracy (a) Transaction arrival time differences of Bitcoin (b) Δ(ts0 ts1) distribution

Security and Communication Networks 7

(a) (b)

Figure 8 Example fork episodes each dot represents a block followed by block hash (last six hexadecimals) arrival time block height (lastthree digits) block timestamp and its miner Each Ethereum stale block is tagged either R (reported uncle) or NR (not reported) Each EOSblock is tagged with the block sequence (out of 12) of the corresponding BPrsquos production schedule (a) Ethereum (b) EOS

SparkPoolEthermine

F2PoolNanopool

MiningPoolHubzhizhutop

Unconditional SparkPool Ethermine F2Pool Nanopool MiningPoolhub

zhizhutop

0

01

02

03

04

05

Freq

uenc

y

(a)

EarliestMixedNonearliest

Spar

kPoo

lEt

herm

ine

F2Po

olN

anop

ool

Min

ingP

oolH

ubzh

izhu

top

UU

Pool

Pand

aMin

erBT

POO

Lxn

pool

Huo

biM

inin

gPoo

lD

war

fPoo

lfir

epoo

lU

nkno

wn

Min

ing

Expr

ess

BTC

com

Pool

Min

eral

lPoo

lBe

ePoo

lH

iveo

nPoo

l2M

iner

sPPL

NS

2Min

ersS

OLO

Coin

otro

nW

POO

LEz

ilPoo

lpo

olin

o

f tot

al fo

rk re

solv

e

(b)

Figure 9 Ethereum fork resolve statistics (a) Probability of ma (x-axis) adding a block to mbrsquos block (b) Probability of adding to the earliestpropagated block

8 Security and Communication Networks

probability by labeling whether or not the chosen block (byma) is the earliest propagated one e ldquoearliestrdquo label in-dicates that the block to which the newly mined block (byma) is added has been observed as the earliest one to arrivecongruently among all eight measurement locations (Asblock arrival times are measured in eight different locationsthe arrival order can be conflicting e ldquomixedrdquo labelrepresents the conflicting cases) For example the topranked pool SparkPool chose the earliest arriving blocksim55 of the time 3409 out of 6234 blocks among the other2825 blocks that were added to nonearliest previous blocksSparkPoolrsquos own blocks were chosen over others 1211 timeswhile other poolsrsquo blocks were preferred to SparkPoolrsquos only24 times In the meantime Nanopool chose the earliest one amajority of the time For the top 25 ranked mining pools onlyfour of them added blocks to the earliest arriving blocks morethan 90 of the timeis contradicts the earliest propagatedblock endorsement assumption that is broadly adopted inmining-related research [36ndash38]

One possible explanation of the phenomenon is that themining pools adopt their own block preferring strategy as asimple precautionary defense against yet unknown selfishmining pools the profitability of selfish mining largelydepends on the probability of honest pools adding to theattacking poolrsquos branch

413 Cut-Tail Fork Pattern of EOS BPs We find that theEOS fork episodes occur in a way that BPs are cutting the tailof the previous BPrsquos produced blocks EOS adopts the DPoSconsensus mechanism [26] 21 block producers (BPs) areelected by voting and scheduled to produce 12 consecutiveblocks in 6 seconds (ie 500ms for each block) in the al-phabetical order of their names Figure 10 shows thenumbers of switching (by schedule) events and cut-tail forkevents of all immediate BP pairs We observe a high fre-quency of such events when bitfinexeos1 is producing blocksby appending to big onersquos blocks while there are accusationsof BPrsquos dishonest behaviors we believe that the reportedbitfinexrsquos performance problem is the compelling reason forthe phenomenon [39]

42 Unseen and Stale Transactions

421 Private Transaction Mining Unseen transactions arecharacterized by the strong evidence that implies that theunseen transactions are indeed never advertised to the net-work Table 6 categorizes 9587 of Ethereum unseentransactions by using the from addresses of the transactions(We use prefixes followed by ⋆ in presenting hash valueseg address (ie pubkey hash) and txid for brevity Weunderstand this does not entirely anonymize identity as thereaders can verify their results against ours by matching theprefixes) Public names are retrieved from Etherscan [16] Aminer is specified in the table only if all blocks that includethe unseen transactions with the from address are con-gruently mined by that single miner It shows that most ofthe unseen transactions are indeed the block minerrsquos owntransactions

Table 7 shows unseen Bitcoin transactions categorized bythe identified reasons sim 67 of the unseen transactions areeither zero-fee transactions or zero-fee-transaction-dependenttransactionsWe define a transaction t isin transactions(b) as adependent transaction if at least one of input transactions oft is included in the same block b

Bitcoin Core [28] implementation does not propagatetransactions with zero transaction fee Also a dependenttransaction cannot be mempooled until the transaction towhich it is dependent is mempooled consequently it cannotbe relayed to peers e Bitcoin Core mempool imple-mentation justifies the inexistence of zero-fee and zero-fee-dependent transactions from our measurement Existence ofa stale transaction which shares the same transaction inputwith the unseen transaction may imply a possible double-spend attempt a variant [40] involving private mining of ablock with ti while advertising a conflict transaction tj suchthat inputs(ti)cap inputs(tj)neempty we have observed 27 suchunseen transactions without a certainty of attack intentionsor if they are not indeed advertised Lastly multisig trans-action inputs often imply off-chain protocols where signedtransactions are exchanged out-of-band [41] and havingOP_RETURN transaction output implies special purposeprotocols of Bitcoin for example sidechains where theirrelationship with miners require further investigation [42]e presence of unseen transactions by either privatetransaction mining or potential out-of-band delivery oftransactions has a subtle security implication One obviousside effect is privatization of transaction fees the transactionfees of privately mined ones are exclusively obtainable by theprivate miner alone unless the network is fully utilized Ifthe network is fully utilized a miner is forced to include herprivate transactions at the expense of not including othertransactions as the block capacity is limited

422 Conflict Stale Transactions Stale transactions arenetwork-transmitted transactions that are not included inany of the blocks

Table 8 shows the stale transaction counts observed ateach location e stale transactions account for 020369 and 047 of Bitcoin Ethereum and EOS transac-tions respectively Ethereum transactions had an order ofmagnitude more chance of being stale than others

As for public blockchains with transaction fees that isBitcoin and Ethereum stale transactions are mostly at-tributable to conflict Table 9 summarizes the identifiedreasons for transactions being stale A stale Bitcoin trans-action is attributable to conflict if there are one or moretransactions sharing at least one transaction input (ie vin)

An Ethereum transaction is attributable to conflict ifthere is another transaction with the same nonce from thesame account A widely known reason for two or moretransactions being in conflict is transaction replacementsuch as replace-by-fee [43] On the other hand slightly morethan 5 of Bitcoin transactions are stale because at least oneof their transaction inputs is also stale

On the other hand roughly one out of ten staleEthereum transactions is attributable to improper ordering

Security and Communication Networks 9

of nonce (e transaction nonce should be equal to thenumber of transactions sent from the address) nonce is toohigh (983) or too low (002) Last but not least 727 ofstale transactions are not included in blocks because theaccount is not sufficiently funded (An Ethereum accountshould have balance ge value+ gastimes gas price to execute thetransaction [44]) An Ethereum account can be

insufficiently funded when executing a transaction for anumber of reasons [45]

423 EOS Transaction Discrepancy EOS exhibits unseenand stale transactions far different from those of Bitcoin orEthereum that is the PoW blockchains with transaction feeEOS software is not bundled with peer discovery rather thenode operator is required to look up for candidate BPrsquospeering services timely delivery of blockchain data andreliability of the node is dependent on the peering nodes ofchoice (Indeed we have experienced service disruption bydisconnecting from peers for unknown reasons)e notionof being conflict in two or more transactions that is themost frequent reason for transactions being stale for Bitcoinand Ethereum is not applicable to EOS (EOS adopts theaccount model without transaction ordering per accountthus there should be no conflict transaction outputs or thesame account nonce) On the other hand EOS requires

eosh

uobi

pool

-eos

infst

ones

eosfl

ytom

ars-

eosh

uobi

pool

zbeo

sbp1

1111

-atti

clab

eosb

attic

labe

osb-

big

one

hoo

com

-new

dex

bpw

hale

exco

m-z

beos

bp11

111

start

eosio

bp-w

hale

exco

meo

sdot

wik

ibp-

eosfl

ytom

ars

eosc

anno

nchn

-eos

dotw

ikib

pbi

gon

e-bi

tfine

xeos

1eo

sinfst

ones

-eos

iom

eeto

nehe

lloeo

scnb

p-ho

oco

meo

slaom

aoco

m-e

ossv

12eo

ssv

slow

mist

iobp

-sta

rteo

siobp

eoss

v12e

ossv

-hel

loeo

scnb

peo

sbei

jingb

p-eo

scan

nonc

hneo

siosg

1111

1-eo

slaom

aoco

meo

siom

eeto

ne-e

osio

sg11

111

bitfi

nexe

os1-

cert

ikeo

sorg

new

dex

bp-s

low

mist

iobp

coch

ainw

orld

-eos

asia

1111

1bi

tfine

xeos

1-co

chai

nwor

ldce

rtik

eoso

rg-c

ocha

inw

orld

eosa

sia11

111-

eosb

eijin

gbp

new

dex

bp-o

kcap

italb

p1eo

siom

eeto

ne-e

osla

omao

com

okca

pita

lbp1

-slo

wm

istio

bpco

chai

nwor

ld-e

osbe

ijing

bpne

wde

xbp

-sta

rteo

siobp

eosa

sia11

111-

eosc

anno

nchn

eosla

omao

com

-hel

loeo

scnb

pco

chai

nwor

ld-e

osca

nnon

chn

cert

ikeo

sorg

-eos

beiji

ngbp

eoss

v12e

ossv

-hoo

com

bitfi

nexe

os1-

eosa

sia11

111

eosin

fston

es-e

osla

omao

com

okca

pita

lbp1

-sta

rteo

siobp

BP switching (left)Cut-tail (right)

0

5000

10000

15000

20000

25000

BP sw

itchi

ng ev

ents

0

100

200

300

400

500

cu

t-tai

l eve

nts

Figure 10 EOS BP switching and cut-tail events

Table 6 Ethereum unseen transactions

From address Public name Transaction count Miner0xea67⋆ Ethermine 128145 (7242) Ethermine0x2a65⋆ DwarfPool 22955 (1297) DwarfPool0x8fd0⋆ Unknown 11346 (641) SparkPool0x829b⋆ F2Pool 4453 (251) F2Pool0x4c54⋆ HiveonPool 1135 (064) SparkPool0x99c8⋆ BeePool 468 (026) BeePool0xdba7⋆ Unknown 348 (020) UUPool0x464b⋆ FKPool 340 (019) FKPool0xf687⋆ Unknown 217 (012) AntPool0xa801⋆ Unknown 151 (009) AntPool0xbe7c⋆ Unknown 126 (007) AntPool0xb96f⋆ Unknown 101 (006) AntPool

Sum 169785 (9587)

Table 7 Bitcoin unseen transactions

Category Transactioncount

Zero-fee transaction 148 (5068)Zero-fee-transaction-dependent transaction 48 (1644)Multisig transaction input 43 (1473)Conflict with stale transaction 27 (925)OP_RETURN transaction output 26 (890)Sum 292 (10000)

10 Security and Communication Networks

contract users to stake tokens for CPU time that can bededucted by transaction executions A requested transactioncan be rejected thus being stale due to the lack of CPU timeor other resources similarly Replaying the entire statechanges of EOS to find out stale transactions due to lack ofresources is not possible unless all transaction and state logsof the entire BPs are available

On the other hand EOS transactions have two additionalattributes which are not available in the Bitcoin or Ethereumtransaction structures

(i) Reference block every EOS transaction refers to ablock by specifying the block number and hash notonly to prevent replay attacks but also to signal thenetwork that the userrsquos stake is on a specific fork

(ii) Expiration time EOS transactions have explicitexpiration times

If a transactionrsquos reference block is not part of the mainchain at the time of execution the transaction cannot beexecuted (and thus cannot be included in a block) We haveidentified that 18 of stale transactions apply to this case Tofurther identify unknown reasons we consider four timedevents that are relevant to transaction execution

(i) Last irreversible block arrival time arrival(blib) thearrival time of transactionrsquos reference block EOStransactions by default refer to the last irreversibleblock (LIB) [26]

(ii) Head block arrival time arrival(bhead) the scheduledtime of the head block when transaction is arrived

(iii) Transaction arrival time arrival(t) the arrival timeof transaction t

(iv) Expiration time exp(t) the expiration time oftransaction t

e three time differences that is Δexp Δincl and Δtrxare investigated to find characteristics of unseen (Tunseen)and stale (Tstale) transactions over the normal transactions(Tincluded) Figure 11 illustrates the relevant events and timedifferences of them Δexp measures the time difference be-tween the two scheduled (ie virtually timed) events Δincland Δtrx are defined by the arrival events to our monitornode Figure 12 shows the distributions of Δexp Δincl andΔtrx We find that unseen transactions have prolonged Δinclimplying that the delay of newly produced blocks can causenewly generated transactions not promptly delivered be-cause the sync manager is in the Head Catch-Up mode astransactions are only transferred in In-Sync mode by itsdesign [24] Stale transactions with relatively small Δtrx canbe attributable to problematic dApp implementations re-ferring to non-LIB blocks the chain instability caused byblockchain fork mostly due to the cut-tail behavior shown inSection 41 can cause transactions being rejected for im-mature block reference

However we do not find any reason attributable to thetransaction expiration Although the unseen transactionstend to have smallΔexp the expiration times are only as smallas 30 seconds (ie the default expiration time) Particularlyone or more EOS applications set the expiration time to180 seconds (other than the default 30 seconds) and morethan half of the stale transactions are invoked by thoseapplications

While transaction is the smallest unit of execution inBitcoin and Ethereum the unit of contract execution in EOSis action [24] A transaction consists of one or more actionsHowever the constituent actions in a single transactioncannot be separately advertised or executed accordingly weapply the identical transaction model to EOS without loss ofgenerality

5 Block and TransactionArrival Characteristics

51 Arrival Processes All three blockchains we study in thispaper are designed to publish capacity constrained blocks intargeted regular time intervals An incarnation of suchdesign is expected to exhibit a Poisson block arrival processWhile it is claimed that Bitcoin block arrivals do not entirelyexhibit a homogeneous Poisson process due to its difficultadjustment mechanism [46] transaction arrival processes ofblockchains are not studied in the literature to the best of ourknowledge A particularly meaningful step toward under-standing the arrival process of events generated by a complexsystem is examining if the arrival events are independent orexhibiting a correlated structure [47]

e variance-time log-log plots [48] of the block andtransaction arrival event time series are depicted in

Table 8 Stale transactions

Region Bitcoin Ethereum EOSAsia-East 41720 1170706 mdashAsia-South 41653 1194018 504277Europe-North 41693 1192435 470480Europe-West 41668 1123680 450140North America-Northeast 41703 1212210 588711US-Central 41683 1212389 505160US-East 41692 1186488 mdashUS-West 41672 1167627 480207Combined 42023 1351847 672999

Table 9 Identified reasons of stale transactions

Category Transaction count(a) Bitcoin

Conflict 39408 (9378)Stale transaction input 2307 (549)Conflict and stale transaction input 308 (073)Sum 42023 (10000)

(b) EthereumConflict 1208588 (8924)Nonce (skipped) 133161 (983)Nonce (used) 251 (002)Insufficient fund 9847 (727)Sum 1351847 (9982)

(c) EOSFork 12106 (180)Others 660893 (9820)Sum 672999 (10000)

Security and Communication Networks 11

Figure 13(a) As regards the block arrival processes Bitcoinblock arrivals exhibit a linear slope β minus23 e estimatedHurst parameter H 1 + β2 43 implies that the processis not a homogeneous Poisson process but LRD (Long-Range Dependent) contrary to what is expected for a regularinterval event generation [46] Ethereum block arrivalsapproximate the Bitcoinrsquos except for the high aggregationlevel due to high stale block rate EOS block arrivals incontrast follow the slope β minus1 in the low aggregation levelas the block generation is indeed regularly scheduled

Figure 14 shows the variance-time plot of Ethereum andEOS block arrival time series by taking all block arrivalevents (Bobs) and main chain block arrivals only (Bmain) Weconfirm that Ethereum block arrivals indeed exhibit astraight line (close to Bitcoin) if excluding stale blocksHowever EOS block arrivals do not exhibit a straight line

even if we exclude stale blocks due to delayed burst blockarrivals possibly due to cut-tail fork patterns (see Section41)

e transaction arrival processes of all three blockchainsappear to exhibit LRD with Hurst parameter Hgt 56 asβltminus13 To further identify analytical distributions that fitbest the empirical ones the coefficient of variation (σμ) andskewness (ie the standardized third moment) of transac-tion interarrival times are computed for every measurementdataset and compared to the relationships expected for theexponential lognormal Weibull and Gamma distributionsin Figure 13(b) We find that Bitcoin Ethereum and EOStransaction interarrival times are fit best Gamma Weibulland lognormal distribution respectively Individual datasetsare also examined for the fitness of the distribution to findthat the empirical distribution fits the analytical distribution

Virtualclock

Time

Transaction initiator

Time

Blockproducer

Time

Monitornode

Time

Scheduled block time of blib

Scheduled block time of bhead

Scheduled block time of bincl

1 Produce and propagate blib

2 Produce and propagate bhead

Expiration time of t

4 Produce and propagate bincl

Δexp

Δtrx

Δincl

3 Create and propagate t

Figure 11 EOS transaction analysis model

Tincluded

Tstale

Tunseen

0010203040506070809

1

Cum

ulat

ive f

requ

ency

100 200 300 400 5000Time difference (seconds)

(a)

Tincluded

Tunseen

01 1 10 100 1000001Time difference (seconds)

0010203040506070809

1

Cum

ulat

ive f

requ

ency

(b)

Tincluded

Tstale

0010203040506070809

1

Cum

ulat

ive f

requ

ency

01 1 10 100 1000001Time difference (seconds)

(c)

Figure 12 EOS transaction timing analysis (a) Δexp (b) Δincl (c) Δtrx

12 Security and Communication Networks

well except for the small interarrival time ranges For ex-ample Figure 15 depicts the CDF of Ethereum transactioninterarrival times observed in US-West Although the em-pirical distribution fits Weibull with parameters computedwith the maximum likelihood estimator [49] sample pointsunder several milliseconds appear to be unreliable (We areyet unaware of the reason However it is known that thetime source of commodity operating systems is not accurateand we need an external time source for accurate sub-millisecond timing measurement [50])

52AdvertisementRedundancy Bitcoin and Ethereum nodepieces of software are implemented to maintain a large

number of peer connections with multiple random remotenodes Bitcoin Core can connect up to 125 peers where 8 ofthem are outbound connections Go Ethereum maintains 50peer connections where 16 of them are outbound by default(see Table 1) On the other hand partitioning attacks aredeveloped to isolate a blockchain node from the others bytampering with all such peer connections Partitioning at-tacks usually exploit vulnerable peer management mecha-nisms of Bitcoin [51] and Ethereum [52] Such attacks arealso examined in the context of ISPrsquos BGP hijacking [53] anda stealthier variant relieving the attacker from the risk ofgetting exposed [54] e attacks often rely on imple-mentation vulnerabilities for efficient eclipsing of peerswhile known vulnerabilities are getting addressed for ex-ample the lack of parallel block download sessions causing

Slope = ndash1

Trx BitcoinTrx EthereumTrx EOS

Blk BitcoinBlk EthereumBlk EOS

ndash12

ndash10

ndash8

ndash6

ndash4

ndash2

0Lo

g no

rmal

ized

var

ianc

e

124 6 10 140 2 8Aggregation level

(a)

Lognormal

Weibull

Gamma

Exponential

BitcoinEthereumEOS

0

5

10

15

20

Stan

dard

ized

third

mom

ent

1 2 3 40Coefficient of variation

(b)

Figure 13 Transaction arrival characteristics (a) Variance-time plot of block and transaction arrivals (b) Cov versus skewness oftransaction interarrival times

Ethereum - Bobs

Ethereum - Bmain

EOS - Bobs

EOS - Bmain

ndash12

ndash10

ndash8

ndash6

ndash4

ndash2

0

Log

norm

aliz

ed v

aria

nce

2 4 6 8 10 12 140Aggregation level

Figure 14 Variance-time plot of block arrivals including staleblocks (Bobs) and excluding stale blocks (Bmain)

EmpiricalExponential μ = 0024

Lognormal μ = 00354 σ2 = 00486Pareto k = 0000212 a = 0231Weibull c = 0589 a = 00147

00001 0001 001 01 1000001Time (seconds)

0

02

04

06

08

1

Cum

ulat

ive f

requ

ency

Figure 15 Empirical and fitted analytical distributions of Ether-eum transaction interarrival times

Security and Communication Networks 13

temporary denial of blocks (reported in [27] and fixed byrecommending three concurrent download sessions in [55])let attackers successfully partition the node without eclipsingall peer connections [53] A simple countermeasure of in-creasing the number of peer connections on the other handis applied to the reference public blockchain implementa-tions [56 57] to inflate attack complexity

We investigate the degree of a peerrsquos advertisementredundancy on newly generated blocks and transactions toevaluate the efficacy of partitioning attacks and the coun-termeasure of increasing the number of peer connectionsFigure 16 shows how redundantly newly generated blockinformation is offered by peers Bitcoin nodes have main-tained sim43 peer connections that is 8 outbound and ad-ditional 35 inbound connections on average and Ethereumnodes record all 50 peer connections established during theentire observation period

For each newly generated block one-third of peersadvertised the block header to our Bitcoin node and morethan 90 of Ethereum peers signaled availability of theblocks In consequence successfully partitioning a noderequires compromise of peers proportional to the totalnumber of peer connections Increasing the number of peerconnections will burden the attacker linearly as expected

Figure 17 shows how redundantly the newly generatedtransaction information is offered by peers While one out ofthree Bitcoin peers also advertises new transactions viaINVENTORYmessage [58] half of the Ethereum peers havesent new transactions to our node in average Bitcoin andEthereum blocks are advertised with the block header(rather than the direct delivery of all block contents) Bitcointransactions are also advertised with INVENTORY messagebefore the whole contents are transferred HoweverEthereum transaction data that is the entire contents aredirectly sent by peers (Ethereum now has a pooled trans-action delivery model in its newer ETH64 protocol [30])We also find that there are cases with much less advertisedtransactions and have identified that they are indeed mostlystale ones stale transactions are mostly due to conflict (seeSection 42) and the nodes that already queued the conflicttransaction will not relay the stale one

6 Discussion

61 Implication on Mining Attacks Cryptocurrency mininghas been a popular subject in assessing the security ofBitcoin selfish mining [37] block withholding attack [36]and a mixed strategy [38] have been studied Although it isshown that selfish behavior in mining is always moreprofitable than being honest without need for a mutualagreement of not attacking each other [38] we find thatselfish mining is not the preferred strategy All selfish miningstrategies will result in blockchain forks but we observe avery low fork probability (ie 004) for Bitcoin On theother hand selfish mining on Ethereum has been studiedonly recently to unanimously claim that selfish mining isalso profitable for Ethereum miners however it is lessprofitable than Bitcoin due to its uncle reward system [59]Our result in Section 4 shows that a majority of Ethereum

miners choose to add to their own produced blocks over theearliest propagated blocks How does this affect the selfishmining strategy

e selfish mining strategy assumes a parameter c whichdefines the fraction of honest minersrsquo mines on the attackerrsquosfork branch (e parameter comes into play in case (f ) of[27]) If the attacking pool has a network-wise superiorposition in block propagation (ie cgt 05) the selfishmining strategy is profitable for pools with proportionalmining power αgt 25 [37] Absolute network inferiority(ie c 0 due to a defensive mining strategy such as the onepresented in Section 41) increases the required miningpower to 33 the 33 mining power appears to be sig-nificantly harder to achieve in the real world [20]

As for the FAW (Fork-After-Withholding) attackstrategy [38] the network capability parameter C defines theprobability that an attackerrsquos FPoW (Full Proof-of-Work)block (during infiltration mining) is selected as a main chainblock C affects both the attack reward and whether theminerrsquos dilemma holds or not in the mutual attacking gameAs an example case (Section 9 of [38]) of a two-pool gamebetween F2Pool and BitFury the absolute network inferi-ority drops C from 0914 to 03 to make it a dilemmatic gameagain Unfortunately minersrsquo own block preferences cannotbe directly transferred to a single parameter of c or C it callsfor a model change from previous mining studies

62 Conflict Transactions and Double-Spending AttacksDouble-spending attacks have been studied in the context ofBitcoin fast payments where zero or only one confirmation isrequired to complete an offline merchandise transaction[60] real-world cases where two conflict transactions dis-parately arrive at different measurement locations mayimply such attacks Table 10 shows the cases where twotransactions are in conflict (and thus only one of themis included in a block ie inputs(ti)cap inputs(ts)neemptyand existb isin Bmain ti isin transactions(b) (∄b isin Bmain ts isintransactions(b) is indisputable given a consistent transactionledger)) and two different subsets of the monitors havemempooled either one of them We also have identified 27unseen transactions implying possible one-confirmationattack variant requiring the private mining (ie not ad-vertising the double-spending transaction to the network) in

5 10 15 20 25 30 35 40 45 500 of peers

0

005

01

015

02

025

Freq

uenc

y

BitcoinEthereum

Figure 16 Peer redundancy of block advertisement

14 Security and Communication Networks

Section 42 As for the countermeasure of such attacks bydeploying monitors [60] deployment of 8 monitors in thenetwork to detect the attacks would fail at most 27 out of 95times (sim30) assuming that those 27 unseen transactionswe have identified are initially advertised to the network

63 Potential Impact on Blockchain ApplicationsEthereum and EOS are the most widely used smart contractplatforms fostering various decentralized applications Bit-coin which lacks the capability of executing complex smartcontract codes is also recently utilized to execute smartcontracts for decentralized applications [50 61] Eventhough our work focuses on the fundamental blockchainmechanisms in terms of transactionblock production andpropagation the impact of our findings on decentralizedapplications can be foresighted

According to our blockchain fork results (Section 41)the lack of selfish mining in the real world was speculated bya very low stale block rate of Bitcoin network and prevalenceof nonearliest block endorsement by Ethereum miners Asprofitability of selfish mining encourages miners to behavein a way of producing more blockchain forks the perfor-mance degradation is proportionate to the number of minerswho adopt the selfish mining strategy the key performancemetrics affecting the blockchain application performance

such as node response time or block delivery time are shownto be noticeably degraded due to the selfish mining [62] Forexample decentralized identities issued or revoked on suchblockchains [63 64] cannot be responsively finalized due toinflated blockchain forks Our results show that the selfishmining is not prevalent in the real world thus the appli-cation performance impact is overrated even though it istheoretically shown that miners have every reason to beselfish [38] As for EOS we reported cases where a sequenceof (up to 12) blocks being stale are often observed in suc-cessive mining of two BPs however the rate is too low (ie004) to impact the performance of applications (Section32)

Transaction arrival processes being LRD (Section 51)pose a technical challenge in provisioning transactionprocessing scalability especially for Layer-2 blockchain ap-plication solutions [65 66] For example Layer-2 rollupsolutions require transaction relays which aggregate indi-vidual user transactions of a given blockchain applicationdeployed in the network often without a priori knowledge ofnetwork load One way of solving the problem is a properprioritization of transactions based on the applicationcontext

Lastly blockchain network partitioning can be thebiggest concern for blockchain service providers We ob-served that the increased numbers of peer connections inblockchain reference implementations effectively provide ahigher degree of information redundancy (Section 52)However increased number of peer connections can beexploitable for an attacker who has a denial-of-service attackvector or an invalid transaction initiated by a simple ap-plication bug can flood the network [45]

64 Limitation Our measurement study has several limi-tations First of all our results may only capture only a fewmonths of blockchain network operations In the meantimethe permissionless blockchain pieces of software are in activedevelopment for example Ethereum now utilizes the pooledtransaction delivery [67] instead of unsolicited transactiondelivery which was the only mode at the time of our

Table 10 Bitcoin disparately mempooled transactions

monitors mempooledti

monitors mempooledts

Transactioncount

7 1 26 (3824)6 2 14 (2059)5 3 10 (1471)4 4 5 (735)3 5 5 (735)2 6 3 (441)1 7 3 (441)5 1 1 (147)6 1 1 (147)

Sum 68 (10000)

Tincluded

Tstale

5 10 15 20 25 30 35 40 45 500 of peers

0

005

01

015

02

025

03Fr

eque

ncy

(a)

Tincluded

Tstale

0002004006008

01012014016

Freq

uenc

y

4030 500 10 20 of peers

(b)

Figure 17 Peer redundancy of transaction advertisement (a) Bitcoin (b) Ethereum

Security and Communication Networks 15

measurement Both cryptocurrency market values andblockchain network utilizations are rapidly increasing andthus miners are getting more motivated to optimize theirperformance for example Bitcoin fork probability has be-come far smaller than what is reported previously (seeSection 41)

Second the blockchain state information is not collected inour measurement Our analysis is performed based on onlyavailable information stored in block and transaction logs Wehave utilized an Ethereum archive node [44] to query historicalstate information (eg account balance or account nonce) inSection 42 However such proactive state replication is farmore complicated with EOS unless the full node is configuredto operate as a producing node and logging the state infor-mation thus EOS stale transactions could not be fully un-derstood without the missing EOS network state information

7 Related Work

71 Blockchain Data Analysis Historical transaction data ofBitcoin have often been studied for economic aspects such ascryptocurrency abuse [17] anti-money-laundering [18] andmonetary flow of businesses [19] However historicalblockchain data usually available from block explorer ser-vices are not sufficient for our research purpose

72 Blockchain Measurement Researchers have performedblockchain measurement studies to assess the degree ofdecentralization [20] to investigate demographic informa-tion of network nodes [34 68] to study mining pool be-havior [22] and to evaluate security of PoW blockchains [21]against known attacks such as double-spending attack [60]and selfish mining [37] Our work expands the under-standing of previous security evaluations with the keyfindings acquired from our large-scale transaction and blockmeasurement

73 Blockchain Attacks Partitioning attacks usually exploitvulnerable peer management mechanisms of Bitcoin [51]and Ethereum [52] Such attacks are also examined in thecontext of ISPrsquos BGP hijacking [53] and a stealthier variantrelieving the attacker from the risk of getting exposed [54]Cryptocurrency mining has been a popular subject inassessing the security of Bitcoin selfish mining [37] blockwithholding attack [36] and a mixed strategy [38] have beenstudied Double-spending attacks have been studied in thecontext of Bitcoin fast payments [60]

74 Block Explorer Services We have surveyed the popularblock explorer services of Bitcoin [5 10 12] Ethereum[10 13 16] and EOS [11 14 15] to see the availability ofinformation beyond what is recorded in the main chainblock data we have utilized in our study namely

(i) Stale blockstransactions no Bitcoin and EOS blockexplorers provide stale block information (A relatedstudy [36] has utilized a Bitcoin block explorer service[68] to retrieve stale blocks However the service has

been terminated in March 2019) All Ethereum blockexplorers provide only reported stale blocks (ie uncleblocks [23]) (Ethereum provides incentives for unclestale blocks [44] so that miners include them in theirmined blocks for profit)No block explorers provide stale transaction infor-mation unless one is currently pooled

(ii) Blocktransaction arrival times all block explorersprovide block timestamps that are recorded in theblock headers not the actual times of arrival Ourblockchain fork and gap analysis require measuredblock arrival times at multiple locations All blockexplorers show transaction timestamps identical to theblock timestamp to which the transactions belong(Recent Bitcoin transactions have different timestampsthan the block timestamps in [4] while the timestampsare only at a granularity of one minute) [69 70]

8 Conclusion

We have measured transaction and block arrival events ofthe three permissionless blockchains We have devised anoble analysis model and analyzed completeness of ourblock and transaction logs Finally we have studied thediscrepancy in measured events and arrival characteristics toshare our key findings including a false universal assumptionof previous mining-related studies

Data Availability

e measurement data used to support the findings of thisstudy have not been made available because they containprivate information that can be used to identify individualblockchain nodes

Disclosure

is is an extended and revised version of a conference paperpresented in IEEE ICDCS 2021 [41]

Conflicts of Interest

e authors declare that they have no conflicts of interest

Acknowledgments

e authors would like to thank Seungwon Woo DaegeunYoon and Changhyun Lee for helping them with themeasurement instrumentation is work was supported byElectronics and Telecommunications Research Institute(ETRI) grant funded by the Korean Government (21ZR1300Research on Intelligent Cyber Security and Trust Infra)

References

[1] S Nakamoto ldquoBitcoin a peer-to-peer electronic cash systemrdquo2019

[2] V Buterin ldquoEthereum white paperrdquo 2013 httpsethereumorgenwhitepaper

[3] Monero ldquoMonerordquo 2020 httpswebgetmoneroorg

16 Security and Communication Networks

[4] bitcoincashorg httpswwwbitcoincashorg[5] Blockchaincom httpswwwblockchaincom[6] Ripple ldquoXRP e best digital asset for global paymentsrdquo

2020 httpsripplecomxrp[7] I Foundation ldquoIotardquo 2021 httpswwwiotaorg[8] ldquoEosiordquo 2020 httpseosio[9] S Orsquoneal ldquoEos proves yet again that decentralization is not its

priorityrdquo 2018 httpscointelegraphcomnewseos-proves-yet-again-that-decentralization-is-not-its-priority

[10] Blockchair httpsblockchaircom[11] Bloksio httpsbloksio[12] BTCcom ldquoBitcoin block explorerrdquo 2021 httpsbtccom[13] Ethereum block explorer httpsethbtccom[14] eosflareio Eos block explorer httpseosflareio[15] EOSPark ldquoEos block explorerrdquo 2021 httpseosparkcom[16] Etherscan Ethereum explorer httpsetherscanio[17] S Lee C Yoon and H Kang ldquoCybercriminal minds An

investigative study of cryptocurrency abuses in the dark webrdquoin Proceedings of the Network and Distributed System SecuritySymposium pp 1ndash15 Internet Society San Diego CA USAFebruary 2019

[18] MMoser R Bohme and D Breuker ldquoAn inquiry into moneylaundering tools in the bitcoin ecosystemrdquo in Proceedings ofthe 2013 APWG eCrime Researchers summit pp 1ndash14 IEEESan Francisco CA USA September 2013

[19] M Lischke and B Fabian ldquoAnalyzing the bitcoin network thefirst four yearsrdquo Future Internet vol 8 no 1 2016

[20] A E Gencer S Basu I Eyal R V Renesse and E G SirerldquoDecentralization in bitcoin and ethereum networksrdquo inProceedings of the International Conference On FinancialCryptography and Data Security pp 439ndash457 SpringerNieuwport Curaccedilao February 2018

[21] A Gervais G O Karame KWust V Glykantzis H Ritzdorfand S Capkun ldquoOn the security and performance of proof ofwork blockchainsrdquo in Proceedings Of the 2016 ACM SIGSACConference on Computer and Communications Securitypp 3ndash16 Vienna Austria October 2016

[22] C Wang X Chu and Q Yang ldquoMeasurement and analysis ofthe bitcoin networks a view from mining poolsrdquo 2019httpsarxivorgabs190207549

[23] G Wood ldquoEthereum A secure decentralised generalisedtransaction ledgerrdquo Ethereum Project Yellow Paper vol 1512014

[24] ldquoTransactions protocol eosio developer docsrdquo 2018 httpsdeveloperseosiowelcomev20protocoltransactions_protocol

[25] Y Sompolinsky and A Zohar ldquoSecure high-rate transactionprocessing in bitcoinrdquo in Proceedings of the InternationalConference On Financial Cryptography and Data Securitypp 507ndash527 Springer San Juan PR USA January 2015

[26] Blockone ldquoConsensus protocolrdquo 2018 httpsdeveloperseosiowelcomev20protocolconsensus_protocol

[27] A Gervais H Ritzdorf G O Karame and S CapkunldquoTampering with the delivery of blocks and transactions inbitcoinrdquo in Proceedings Of the 22nd ACM SIGSAC ConferenceOn Computer and Communications Security pp 692ndash705Denver CO USA October 2015

[28] ldquoGithub Bit coinrdquo 2020 httpsgithubcombitcoinbitcoin[29] G Ethereum ldquoGo ethereumrdquo 2020 httpsgithubcom

ethereumgo-ethereum[30] Google ldquoGoogle cloudrdquo 2021 httpscloudgooglecom[31] ldquoHow to replay from a snapshotrdquo 2018 httpsdeveloperseos

iomanualseoslatestnodeosreplayshow-to-replay-from-a-snapshot

[32] C Decker and R Wattenhofer ldquoInformation propagation inthe bitcoin networkrdquo in Proceedings of the IEEE P2P 2013Proceedings pp 1ndash10 IEEE Trento Italy September 2013

[33] ldquoEthereum uncle raterdquo 2020 httpsychartscomindicatorsethereum_uncle_rate

[34] J A Donet C P Sola and J H Joancomartı ldquoe bitcoin p2pnetworkrdquo in Proceedings of the International Conference OnFinancial Cryptography and Data Security pp 87ndash102Springer Christ Church Barbados March 2014

[35] G S Davies ldquoBit-booster - offline commit graph drawingtoolrdquo 2016 httpbit-boostercomgraphhtml

[36] N T Courtois and L Bahack ldquoOn subversive miner strategiesand block withholding attack in bitcoin digital currencyrdquo2014 httpsarxivorgabs14021718

[37] I Eyal and E G Sirer ldquoMajority is not enough bitcoin miningis vulnerablerdquo in Proceedings of the International Conferenceon Financial Cryptography and Data Security pp 436ndash454Springer Christ Church Barbados March 2014

[38] Y Kwon D Kim Y Son E Vasserman and Y Kim ldquoBeselfish and avoid dilemmas fork after withholding (faw) at-tacks on bitcoinrdquo in Proceedings Of the 2017 ACM SIGSACConference On Computer and Communications Securitypp 195ndash209 Abu Dhabi UAE April 2017

[39] B Research ldquoDecentralisation governance and eos - a lostcaserdquo 2020 httpsresearchbinancecomenanalysiseos-governance

[40] B Wiki ldquoIrreversible transactions - finney attackrdquo 2012httpsenbitcoinitwikiIrreversible_Transactions∖Finney_attack

[41] J Poon and T Dryja ldquoe bitcoin lightning network scalableoff-chain instant paymentsrdquo 2016

[42] M Bartoletti and L Pompianu ldquoAn analysis of bitcoin op_return metadatardquo in Proceedings of the International Con-ference On Financial Cryptography and Data Securitypp 218ndash230 Springer Sliema Malta April 2017

[43] ldquoReplace by feerdquo 2018 httpsenbitcoinitwikiReplace_by_fee

[44] E Foundation ldquoNode and clientsrdquo 2020 httpsethereumorgendevelopersdocsnodes-and-clients

[45] H Heo and S Shin ldquoBehind block explorers public block-chain measurement and security implicationrdquo in Proceedingsof the 41th IEEE International Conference On DistributedComputing Systems IEEE Washington DC USA In pressWashington DC USA July 2021

[46] R Bowden H P Keeler A E Krzesinski and P G TaylorldquoBlock arrivals in the bitcoin blockchainrdquo 2018 httpsarxivorgabs180107447

[47] M E Crovella and A Bestavros ldquoExplaining world wide webtraffic self-similarityrdquo Technical Report Citeseer PrincetonNJ USA 1995

[48] H Zhang Y Shu and O Yang ldquoEstimation of hurst pa-rameter by variance-time plotsrdquo in Proceedings of the 1997IEEE Pacific Rim Conference on Communications Computersand Signal Processing PACRIM 10 Years Networkingthe Pacific Rim 1987-1997 IEEE Victoria BC CanadaAugust 1997

[49] A Feldmann ldquoCharacteristics of TCP connection arrivalsrdquo inSelf-Similar Network Traffic and Performance EvaluationK Park andWWillinger Eds pp 367ndash399Wiley HobokenNJ USA 2000

[50] RSK ldquoRSKrdquo 2021 httpswwwrskco[51] E Heilman A Kendler A Zohar and S Goldberg ldquoEclipse

attacks on bitcoinrsquos peer-to-peer networkrdquo in Proceedings of

Security and Communication Networks 17

the 24th USENIX Security Symposium pp 129ndash144 Wash-ington DC USA April 2015

[52] Y Marcus E Heilman and S Goldberg ldquoLow-resourceeclipse attacks on ethereumrsquos peer-to-peer networkrdquo IACRCryptology vol 2018 p 236 2018

[53] M Apostolaki A Zohar and L Vanbever ldquoHijacking bitcoinRouting attacks on cryptocurrenciesrdquo in Proceedings of the2017 IEEE Symposium On Security and Privacy (SP)pp 375ndash392 IEEE San Jose CA USA May 2017

[54] M Tran I Choi G J Moon A V Vu and M S Kang ldquoAstealthier partitioning attack against bitcoin peer-to-peernetworkrdquo in Proceedings of the IEEE Symposium On Securityand Privacy (SampP) San Francisco CA USA May 2020

[55] B I Proposal ldquoBip 0152rdquo 2016 httpsenbitcoinitwikiBIP_0152

[56] B Core ldquoBitcoin Core Version 01901 Release Noterdquo 2016httpsbitcoinorgenreleasev01901

[57] ldquoGeth v190rdquo 2019 httpsblogethereumorg20190710geth-v1-9-0

[58] ldquoProtocol documentationrdquo 2016 httpsenbitcoinitwikiProtocoltext_documentation

[59] C Feng and J Niu ldquoSelfish mining in ethereumrdquo in Pro-ceedings of the 2019 IEEE 39th International Conference OnDistributed Computing Systems (ICDCS) pp 1306ndash1316IEEE Dallas TX USA July 2019

[60] G O Karame E Androulaki and S Capkun ldquoDouble-spending fast payments in bitcoinrdquo in Proceedings of the 2012ACM Conference on Computer and Communications Securitypp 906ndash917 Raleigh NC USA October 2012

[61] P Das L Eckey T Frassetto et al ldquoFastkitten practical smartcontracts on bitcoinrdquo in Proceedimgs of the 28th USENIXSecurity Symposium (USENIX Security 19) pp 801ndash818Santa Clara CA USA August 2019

[62] S G Motlagh J Misic and V B Misic ldquoe impact of selfishmining on bitcoin network performancerdquo IEEE Transactionson Network Science and Engineering vol 8 no 1 pp 724ndash7352021

[63] A Muhle A Gruner T Gayvoronskaya and C Meinel ldquoAsurvey on essential components of a self-sovereign identityrdquoComputer Science Review vol 30 pp 80ndash86 2018

[64] M Toorani and C Gehrmann ldquoA decentralized dynamic pkibased on blockchainrdquo in Proceedings Of the 36th Annual ACMSymposium On Applied Computing pp 1646ndash1655 GwangjuKorea March 2021

[65] E foundation ldquoOptimistic-rollupsrdquo 2021 httpsdocsethhubioethereum-roadmaplayer-2-scalingoptimistictext_rollups

[66] ldquoZk-rollupsrdquo 2021 httpsdocsethhubioethereum-roadmaplayer-2-scalingzk-rollups

[67] E foundation ldquoEthereumwire protocolrdquo 2019 httpsgithubcomethereumdevp2pblobmastercapseth

[68] S K Kim Z Ma S Murali J Mason A Miller andM BaileyldquoMeasuring ethereum network peersrdquo in Proceedings of theInternet Measurement Conference 2018 pp 91ndash104 BostonMA USA October 2018

[69] Symmetricom ldquoDelivering sub-microsecond accurate time tolinux applications around the worldrdquo 2012 httpwwwchronoscoukfilespdfswpsWP_AccurateTimeForLinuxApplicationspdf

[70] Ycharts ldquoBlocktrail blockchain data query service (termi-nated)rdquo 2019 httpsblocktrailcom

18 Security and Communication Networks

(a) (b)

Figure 8 Example fork episodes each dot represents a block followed by block hash (last six hexadecimals) arrival time block height (lastthree digits) block timestamp and its miner Each Ethereum stale block is tagged either R (reported uncle) or NR (not reported) Each EOSblock is tagged with the block sequence (out of 12) of the corresponding BPrsquos production schedule (a) Ethereum (b) EOS

SparkPoolEthermine

F2PoolNanopool

MiningPoolHubzhizhutop

Unconditional SparkPool Ethermine F2Pool Nanopool MiningPoolhub

zhizhutop

0

01

02

03

04

05

Freq

uenc

y

(a)

EarliestMixedNonearliest

Spar

kPoo

lEt

herm

ine

F2Po

olN

anop

ool

Min

ingP

oolH

ubzh

izhu

top

UU

Pool

Pand

aMin

erBT

POO

Lxn

pool

Huo

biM

inin

gPoo

lD

war

fPoo

lfir

epoo

lU

nkno

wn

Min

ing

Expr

ess

BTC

com

Pool

Min

eral

lPoo

lBe

ePoo

lH

iveo

nPoo

l2M

iner

sPPL

NS

2Min

ersS

OLO

Coin

otro

nW

POO

LEz

ilPoo

lpo

olin

o

f tot

al fo

rk re

solv

e

(b)

Figure 9 Ethereum fork resolve statistics (a) Probability of ma (x-axis) adding a block to mbrsquos block (b) Probability of adding to the earliestpropagated block

8 Security and Communication Networks

probability by labeling whether or not the chosen block (byma) is the earliest propagated one e ldquoearliestrdquo label in-dicates that the block to which the newly mined block (byma) is added has been observed as the earliest one to arrivecongruently among all eight measurement locations (Asblock arrival times are measured in eight different locationsthe arrival order can be conflicting e ldquomixedrdquo labelrepresents the conflicting cases) For example the topranked pool SparkPool chose the earliest arriving blocksim55 of the time 3409 out of 6234 blocks among the other2825 blocks that were added to nonearliest previous blocksSparkPoolrsquos own blocks were chosen over others 1211 timeswhile other poolsrsquo blocks were preferred to SparkPoolrsquos only24 times In the meantime Nanopool chose the earliest one amajority of the time For the top 25 ranked mining pools onlyfour of them added blocks to the earliest arriving blocks morethan 90 of the timeis contradicts the earliest propagatedblock endorsement assumption that is broadly adopted inmining-related research [36ndash38]

One possible explanation of the phenomenon is that themining pools adopt their own block preferring strategy as asimple precautionary defense against yet unknown selfishmining pools the profitability of selfish mining largelydepends on the probability of honest pools adding to theattacking poolrsquos branch

413 Cut-Tail Fork Pattern of EOS BPs We find that theEOS fork episodes occur in a way that BPs are cutting the tailof the previous BPrsquos produced blocks EOS adopts the DPoSconsensus mechanism [26] 21 block producers (BPs) areelected by voting and scheduled to produce 12 consecutiveblocks in 6 seconds (ie 500ms for each block) in the al-phabetical order of their names Figure 10 shows thenumbers of switching (by schedule) events and cut-tail forkevents of all immediate BP pairs We observe a high fre-quency of such events when bitfinexeos1 is producing blocksby appending to big onersquos blocks while there are accusationsof BPrsquos dishonest behaviors we believe that the reportedbitfinexrsquos performance problem is the compelling reason forthe phenomenon [39]

42 Unseen and Stale Transactions

421 Private Transaction Mining Unseen transactions arecharacterized by the strong evidence that implies that theunseen transactions are indeed never advertised to the net-work Table 6 categorizes 9587 of Ethereum unseentransactions by using the from addresses of the transactions(We use prefixes followed by ⋆ in presenting hash valueseg address (ie pubkey hash) and txid for brevity Weunderstand this does not entirely anonymize identity as thereaders can verify their results against ours by matching theprefixes) Public names are retrieved from Etherscan [16] Aminer is specified in the table only if all blocks that includethe unseen transactions with the from address are con-gruently mined by that single miner It shows that most ofthe unseen transactions are indeed the block minerrsquos owntransactions

Table 7 shows unseen Bitcoin transactions categorized bythe identified reasons sim 67 of the unseen transactions areeither zero-fee transactions or zero-fee-transaction-dependenttransactionsWe define a transaction t isin transactions(b) as adependent transaction if at least one of input transactions oft is included in the same block b

Bitcoin Core [28] implementation does not propagatetransactions with zero transaction fee Also a dependenttransaction cannot be mempooled until the transaction towhich it is dependent is mempooled consequently it cannotbe relayed to peers e Bitcoin Core mempool imple-mentation justifies the inexistence of zero-fee and zero-fee-dependent transactions from our measurement Existence ofa stale transaction which shares the same transaction inputwith the unseen transaction may imply a possible double-spend attempt a variant [40] involving private mining of ablock with ti while advertising a conflict transaction tj suchthat inputs(ti)cap inputs(tj)neempty we have observed 27 suchunseen transactions without a certainty of attack intentionsor if they are not indeed advertised Lastly multisig trans-action inputs often imply off-chain protocols where signedtransactions are exchanged out-of-band [41] and havingOP_RETURN transaction output implies special purposeprotocols of Bitcoin for example sidechains where theirrelationship with miners require further investigation [42]e presence of unseen transactions by either privatetransaction mining or potential out-of-band delivery oftransactions has a subtle security implication One obviousside effect is privatization of transaction fees the transactionfees of privately mined ones are exclusively obtainable by theprivate miner alone unless the network is fully utilized Ifthe network is fully utilized a miner is forced to include herprivate transactions at the expense of not including othertransactions as the block capacity is limited

422 Conflict Stale Transactions Stale transactions arenetwork-transmitted transactions that are not included inany of the blocks

Table 8 shows the stale transaction counts observed ateach location e stale transactions account for 020369 and 047 of Bitcoin Ethereum and EOS transac-tions respectively Ethereum transactions had an order ofmagnitude more chance of being stale than others

As for public blockchains with transaction fees that isBitcoin and Ethereum stale transactions are mostly at-tributable to conflict Table 9 summarizes the identifiedreasons for transactions being stale A stale Bitcoin trans-action is attributable to conflict if there are one or moretransactions sharing at least one transaction input (ie vin)

An Ethereum transaction is attributable to conflict ifthere is another transaction with the same nonce from thesame account A widely known reason for two or moretransactions being in conflict is transaction replacementsuch as replace-by-fee [43] On the other hand slightly morethan 5 of Bitcoin transactions are stale because at least oneof their transaction inputs is also stale

On the other hand roughly one out of ten staleEthereum transactions is attributable to improper ordering

Security and Communication Networks 9

of nonce (e transaction nonce should be equal to thenumber of transactions sent from the address) nonce is toohigh (983) or too low (002) Last but not least 727 ofstale transactions are not included in blocks because theaccount is not sufficiently funded (An Ethereum accountshould have balance ge value+ gastimes gas price to execute thetransaction [44]) An Ethereum account can be

insufficiently funded when executing a transaction for anumber of reasons [45]

423 EOS Transaction Discrepancy EOS exhibits unseenand stale transactions far different from those of Bitcoin orEthereum that is the PoW blockchains with transaction feeEOS software is not bundled with peer discovery rather thenode operator is required to look up for candidate BPrsquospeering services timely delivery of blockchain data andreliability of the node is dependent on the peering nodes ofchoice (Indeed we have experienced service disruption bydisconnecting from peers for unknown reasons)e notionof being conflict in two or more transactions that is themost frequent reason for transactions being stale for Bitcoinand Ethereum is not applicable to EOS (EOS adopts theaccount model without transaction ordering per accountthus there should be no conflict transaction outputs or thesame account nonce) On the other hand EOS requires

eosh

uobi

pool

-eos

infst

ones

eosfl

ytom

ars-

eosh

uobi

pool

zbeo

sbp1

1111

-atti

clab

eosb

attic

labe

osb-

big

one

hoo

com

-new

dex

bpw

hale

exco

m-z

beos

bp11

111

start

eosio

bp-w

hale

exco

meo

sdot

wik

ibp-

eosfl

ytom

ars

eosc

anno

nchn

-eos

dotw

ikib

pbi

gon

e-bi

tfine

xeos

1eo

sinfst

ones

-eos

iom

eeto

nehe

lloeo

scnb

p-ho

oco

meo

slaom

aoco

m-e

ossv

12eo

ssv

slow

mist

iobp

-sta

rteo

siobp

eoss

v12e

ossv

-hel

loeo

scnb

peo

sbei

jingb

p-eo

scan

nonc

hneo

siosg

1111

1-eo

slaom

aoco

meo

siom

eeto

ne-e

osio

sg11

111

bitfi

nexe

os1-

cert

ikeo

sorg

new

dex

bp-s

low

mist

iobp

coch

ainw

orld

-eos

asia

1111

1bi

tfine

xeos

1-co

chai

nwor

ldce

rtik

eoso

rg-c

ocha

inw

orld

eosa

sia11

111-

eosb

eijin

gbp

new

dex

bp-o

kcap

italb

p1eo

siom

eeto

ne-e

osla

omao

com

okca

pita

lbp1

-slo

wm

istio

bpco

chai

nwor

ld-e

osbe

ijing

bpne

wde

xbp

-sta

rteo

siobp

eosa

sia11

111-

eosc

anno

nchn

eosla

omao

com

-hel

loeo

scnb

pco

chai

nwor

ld-e

osca

nnon

chn

cert

ikeo

sorg

-eos

beiji

ngbp

eoss

v12e

ossv

-hoo

com

bitfi

nexe

os1-

eosa

sia11

111

eosin

fston

es-e

osla

omao

com

okca

pita

lbp1

-sta

rteo

siobp

BP switching (left)Cut-tail (right)

0

5000

10000

15000

20000

25000

BP sw

itchi

ng ev

ents

0

100

200

300

400

500

cu

t-tai

l eve

nts

Figure 10 EOS BP switching and cut-tail events

Table 6 Ethereum unseen transactions

From address Public name Transaction count Miner0xea67⋆ Ethermine 128145 (7242) Ethermine0x2a65⋆ DwarfPool 22955 (1297) DwarfPool0x8fd0⋆ Unknown 11346 (641) SparkPool0x829b⋆ F2Pool 4453 (251) F2Pool0x4c54⋆ HiveonPool 1135 (064) SparkPool0x99c8⋆ BeePool 468 (026) BeePool0xdba7⋆ Unknown 348 (020) UUPool0x464b⋆ FKPool 340 (019) FKPool0xf687⋆ Unknown 217 (012) AntPool0xa801⋆ Unknown 151 (009) AntPool0xbe7c⋆ Unknown 126 (007) AntPool0xb96f⋆ Unknown 101 (006) AntPool

Sum 169785 (9587)

Table 7 Bitcoin unseen transactions

Category Transactioncount

Zero-fee transaction 148 (5068)Zero-fee-transaction-dependent transaction 48 (1644)Multisig transaction input 43 (1473)Conflict with stale transaction 27 (925)OP_RETURN transaction output 26 (890)Sum 292 (10000)

10 Security and Communication Networks

contract users to stake tokens for CPU time that can bededucted by transaction executions A requested transactioncan be rejected thus being stale due to the lack of CPU timeor other resources similarly Replaying the entire statechanges of EOS to find out stale transactions due to lack ofresources is not possible unless all transaction and state logsof the entire BPs are available

On the other hand EOS transactions have two additionalattributes which are not available in the Bitcoin or Ethereumtransaction structures

(i) Reference block every EOS transaction refers to ablock by specifying the block number and hash notonly to prevent replay attacks but also to signal thenetwork that the userrsquos stake is on a specific fork

(ii) Expiration time EOS transactions have explicitexpiration times

If a transactionrsquos reference block is not part of the mainchain at the time of execution the transaction cannot beexecuted (and thus cannot be included in a block) We haveidentified that 18 of stale transactions apply to this case Tofurther identify unknown reasons we consider four timedevents that are relevant to transaction execution

(i) Last irreversible block arrival time arrival(blib) thearrival time of transactionrsquos reference block EOStransactions by default refer to the last irreversibleblock (LIB) [26]

(ii) Head block arrival time arrival(bhead) the scheduledtime of the head block when transaction is arrived

(iii) Transaction arrival time arrival(t) the arrival timeof transaction t

(iv) Expiration time exp(t) the expiration time oftransaction t

e three time differences that is Δexp Δincl and Δtrxare investigated to find characteristics of unseen (Tunseen)and stale (Tstale) transactions over the normal transactions(Tincluded) Figure 11 illustrates the relevant events and timedifferences of them Δexp measures the time difference be-tween the two scheduled (ie virtually timed) events Δincland Δtrx are defined by the arrival events to our monitornode Figure 12 shows the distributions of Δexp Δincl andΔtrx We find that unseen transactions have prolonged Δinclimplying that the delay of newly produced blocks can causenewly generated transactions not promptly delivered be-cause the sync manager is in the Head Catch-Up mode astransactions are only transferred in In-Sync mode by itsdesign [24] Stale transactions with relatively small Δtrx canbe attributable to problematic dApp implementations re-ferring to non-LIB blocks the chain instability caused byblockchain fork mostly due to the cut-tail behavior shown inSection 41 can cause transactions being rejected for im-mature block reference

However we do not find any reason attributable to thetransaction expiration Although the unseen transactionstend to have smallΔexp the expiration times are only as smallas 30 seconds (ie the default expiration time) Particularlyone or more EOS applications set the expiration time to180 seconds (other than the default 30 seconds) and morethan half of the stale transactions are invoked by thoseapplications

While transaction is the smallest unit of execution inBitcoin and Ethereum the unit of contract execution in EOSis action [24] A transaction consists of one or more actionsHowever the constituent actions in a single transactioncannot be separately advertised or executed accordingly weapply the identical transaction model to EOS without loss ofgenerality

5 Block and TransactionArrival Characteristics

51 Arrival Processes All three blockchains we study in thispaper are designed to publish capacity constrained blocks intargeted regular time intervals An incarnation of suchdesign is expected to exhibit a Poisson block arrival processWhile it is claimed that Bitcoin block arrivals do not entirelyexhibit a homogeneous Poisson process due to its difficultadjustment mechanism [46] transaction arrival processes ofblockchains are not studied in the literature to the best of ourknowledge A particularly meaningful step toward under-standing the arrival process of events generated by a complexsystem is examining if the arrival events are independent orexhibiting a correlated structure [47]

e variance-time log-log plots [48] of the block andtransaction arrival event time series are depicted in

Table 8 Stale transactions

Region Bitcoin Ethereum EOSAsia-East 41720 1170706 mdashAsia-South 41653 1194018 504277Europe-North 41693 1192435 470480Europe-West 41668 1123680 450140North America-Northeast 41703 1212210 588711US-Central 41683 1212389 505160US-East 41692 1186488 mdashUS-West 41672 1167627 480207Combined 42023 1351847 672999

Table 9 Identified reasons of stale transactions

Category Transaction count(a) Bitcoin

Conflict 39408 (9378)Stale transaction input 2307 (549)Conflict and stale transaction input 308 (073)Sum 42023 (10000)

(b) EthereumConflict 1208588 (8924)Nonce (skipped) 133161 (983)Nonce (used) 251 (002)Insufficient fund 9847 (727)Sum 1351847 (9982)

(c) EOSFork 12106 (180)Others 660893 (9820)Sum 672999 (10000)

Security and Communication Networks 11

Figure 13(a) As regards the block arrival processes Bitcoinblock arrivals exhibit a linear slope β minus23 e estimatedHurst parameter H 1 + β2 43 implies that the processis not a homogeneous Poisson process but LRD (Long-Range Dependent) contrary to what is expected for a regularinterval event generation [46] Ethereum block arrivalsapproximate the Bitcoinrsquos except for the high aggregationlevel due to high stale block rate EOS block arrivals incontrast follow the slope β minus1 in the low aggregation levelas the block generation is indeed regularly scheduled

Figure 14 shows the variance-time plot of Ethereum andEOS block arrival time series by taking all block arrivalevents (Bobs) and main chain block arrivals only (Bmain) Weconfirm that Ethereum block arrivals indeed exhibit astraight line (close to Bitcoin) if excluding stale blocksHowever EOS block arrivals do not exhibit a straight line

even if we exclude stale blocks due to delayed burst blockarrivals possibly due to cut-tail fork patterns (see Section41)

e transaction arrival processes of all three blockchainsappear to exhibit LRD with Hurst parameter Hgt 56 asβltminus13 To further identify analytical distributions that fitbest the empirical ones the coefficient of variation (σμ) andskewness (ie the standardized third moment) of transac-tion interarrival times are computed for every measurementdataset and compared to the relationships expected for theexponential lognormal Weibull and Gamma distributionsin Figure 13(b) We find that Bitcoin Ethereum and EOStransaction interarrival times are fit best Gamma Weibulland lognormal distribution respectively Individual datasetsare also examined for the fitness of the distribution to findthat the empirical distribution fits the analytical distribution

Virtualclock

Time

Transaction initiator

Time

Blockproducer

Time

Monitornode

Time

Scheduled block time of blib

Scheduled block time of bhead

Scheduled block time of bincl

1 Produce and propagate blib

2 Produce and propagate bhead

Expiration time of t

4 Produce and propagate bincl

Δexp

Δtrx

Δincl

3 Create and propagate t

Figure 11 EOS transaction analysis model

Tincluded

Tstale

Tunseen

0010203040506070809

1

Cum

ulat

ive f

requ

ency

100 200 300 400 5000Time difference (seconds)

(a)

Tincluded

Tunseen

01 1 10 100 1000001Time difference (seconds)

0010203040506070809

1

Cum

ulat

ive f

requ

ency

(b)

Tincluded

Tstale

0010203040506070809

1

Cum

ulat

ive f

requ

ency

01 1 10 100 1000001Time difference (seconds)

(c)

Figure 12 EOS transaction timing analysis (a) Δexp (b) Δincl (c) Δtrx

12 Security and Communication Networks

well except for the small interarrival time ranges For ex-ample Figure 15 depicts the CDF of Ethereum transactioninterarrival times observed in US-West Although the em-pirical distribution fits Weibull with parameters computedwith the maximum likelihood estimator [49] sample pointsunder several milliseconds appear to be unreliable (We areyet unaware of the reason However it is known that thetime source of commodity operating systems is not accurateand we need an external time source for accurate sub-millisecond timing measurement [50])

52AdvertisementRedundancy Bitcoin and Ethereum nodepieces of software are implemented to maintain a large

number of peer connections with multiple random remotenodes Bitcoin Core can connect up to 125 peers where 8 ofthem are outbound connections Go Ethereum maintains 50peer connections where 16 of them are outbound by default(see Table 1) On the other hand partitioning attacks aredeveloped to isolate a blockchain node from the others bytampering with all such peer connections Partitioning at-tacks usually exploit vulnerable peer management mecha-nisms of Bitcoin [51] and Ethereum [52] Such attacks arealso examined in the context of ISPrsquos BGP hijacking [53] anda stealthier variant relieving the attacker from the risk ofgetting exposed [54] e attacks often rely on imple-mentation vulnerabilities for efficient eclipsing of peerswhile known vulnerabilities are getting addressed for ex-ample the lack of parallel block download sessions causing

Slope = ndash1

Trx BitcoinTrx EthereumTrx EOS

Blk BitcoinBlk EthereumBlk EOS

ndash12

ndash10

ndash8

ndash6

ndash4

ndash2

0Lo

g no

rmal

ized

var

ianc

e

124 6 10 140 2 8Aggregation level

(a)

Lognormal

Weibull

Gamma

Exponential

BitcoinEthereumEOS

0

5

10

15

20

Stan

dard

ized

third

mom

ent

1 2 3 40Coefficient of variation

(b)

Figure 13 Transaction arrival characteristics (a) Variance-time plot of block and transaction arrivals (b) Cov versus skewness oftransaction interarrival times

Ethereum - Bobs

Ethereum - Bmain

EOS - Bobs

EOS - Bmain

ndash12

ndash10

ndash8

ndash6

ndash4

ndash2

0

Log

norm

aliz

ed v

aria

nce

2 4 6 8 10 12 140Aggregation level

Figure 14 Variance-time plot of block arrivals including staleblocks (Bobs) and excluding stale blocks (Bmain)

EmpiricalExponential μ = 0024

Lognormal μ = 00354 σ2 = 00486Pareto k = 0000212 a = 0231Weibull c = 0589 a = 00147

00001 0001 001 01 1000001Time (seconds)

0

02

04

06

08

1

Cum

ulat

ive f

requ

ency

Figure 15 Empirical and fitted analytical distributions of Ether-eum transaction interarrival times

Security and Communication Networks 13

temporary denial of blocks (reported in [27] and fixed byrecommending three concurrent download sessions in [55])let attackers successfully partition the node without eclipsingall peer connections [53] A simple countermeasure of in-creasing the number of peer connections on the other handis applied to the reference public blockchain implementa-tions [56 57] to inflate attack complexity

We investigate the degree of a peerrsquos advertisementredundancy on newly generated blocks and transactions toevaluate the efficacy of partitioning attacks and the coun-termeasure of increasing the number of peer connectionsFigure 16 shows how redundantly newly generated blockinformation is offered by peers Bitcoin nodes have main-tained sim43 peer connections that is 8 outbound and ad-ditional 35 inbound connections on average and Ethereumnodes record all 50 peer connections established during theentire observation period

For each newly generated block one-third of peersadvertised the block header to our Bitcoin node and morethan 90 of Ethereum peers signaled availability of theblocks In consequence successfully partitioning a noderequires compromise of peers proportional to the totalnumber of peer connections Increasing the number of peerconnections will burden the attacker linearly as expected

Figure 17 shows how redundantly the newly generatedtransaction information is offered by peers While one out ofthree Bitcoin peers also advertises new transactions viaINVENTORYmessage [58] half of the Ethereum peers havesent new transactions to our node in average Bitcoin andEthereum blocks are advertised with the block header(rather than the direct delivery of all block contents) Bitcointransactions are also advertised with INVENTORY messagebefore the whole contents are transferred HoweverEthereum transaction data that is the entire contents aredirectly sent by peers (Ethereum now has a pooled trans-action delivery model in its newer ETH64 protocol [30])We also find that there are cases with much less advertisedtransactions and have identified that they are indeed mostlystale ones stale transactions are mostly due to conflict (seeSection 42) and the nodes that already queued the conflicttransaction will not relay the stale one

6 Discussion

61 Implication on Mining Attacks Cryptocurrency mininghas been a popular subject in assessing the security ofBitcoin selfish mining [37] block withholding attack [36]and a mixed strategy [38] have been studied Although it isshown that selfish behavior in mining is always moreprofitable than being honest without need for a mutualagreement of not attacking each other [38] we find thatselfish mining is not the preferred strategy All selfish miningstrategies will result in blockchain forks but we observe avery low fork probability (ie 004) for Bitcoin On theother hand selfish mining on Ethereum has been studiedonly recently to unanimously claim that selfish mining isalso profitable for Ethereum miners however it is lessprofitable than Bitcoin due to its uncle reward system [59]Our result in Section 4 shows that a majority of Ethereum

miners choose to add to their own produced blocks over theearliest propagated blocks How does this affect the selfishmining strategy

e selfish mining strategy assumes a parameter c whichdefines the fraction of honest minersrsquo mines on the attackerrsquosfork branch (e parameter comes into play in case (f ) of[27]) If the attacking pool has a network-wise superiorposition in block propagation (ie cgt 05) the selfishmining strategy is profitable for pools with proportionalmining power αgt 25 [37] Absolute network inferiority(ie c 0 due to a defensive mining strategy such as the onepresented in Section 41) increases the required miningpower to 33 the 33 mining power appears to be sig-nificantly harder to achieve in the real world [20]

As for the FAW (Fork-After-Withholding) attackstrategy [38] the network capability parameter C defines theprobability that an attackerrsquos FPoW (Full Proof-of-Work)block (during infiltration mining) is selected as a main chainblock C affects both the attack reward and whether theminerrsquos dilemma holds or not in the mutual attacking gameAs an example case (Section 9 of [38]) of a two-pool gamebetween F2Pool and BitFury the absolute network inferi-ority drops C from 0914 to 03 to make it a dilemmatic gameagain Unfortunately minersrsquo own block preferences cannotbe directly transferred to a single parameter of c or C it callsfor a model change from previous mining studies

62 Conflict Transactions and Double-Spending AttacksDouble-spending attacks have been studied in the context ofBitcoin fast payments where zero or only one confirmation isrequired to complete an offline merchandise transaction[60] real-world cases where two conflict transactions dis-parately arrive at different measurement locations mayimply such attacks Table 10 shows the cases where twotransactions are in conflict (and thus only one of themis included in a block ie inputs(ti)cap inputs(ts)neemptyand existb isin Bmain ti isin transactions(b) (∄b isin Bmain ts isintransactions(b) is indisputable given a consistent transactionledger)) and two different subsets of the monitors havemempooled either one of them We also have identified 27unseen transactions implying possible one-confirmationattack variant requiring the private mining (ie not ad-vertising the double-spending transaction to the network) in

5 10 15 20 25 30 35 40 45 500 of peers

0

005

01

015

02

025

Freq

uenc

y

BitcoinEthereum

Figure 16 Peer redundancy of block advertisement

14 Security and Communication Networks

Section 42 As for the countermeasure of such attacks bydeploying monitors [60] deployment of 8 monitors in thenetwork to detect the attacks would fail at most 27 out of 95times (sim30) assuming that those 27 unseen transactionswe have identified are initially advertised to the network

63 Potential Impact on Blockchain ApplicationsEthereum and EOS are the most widely used smart contractplatforms fostering various decentralized applications Bit-coin which lacks the capability of executing complex smartcontract codes is also recently utilized to execute smartcontracts for decentralized applications [50 61] Eventhough our work focuses on the fundamental blockchainmechanisms in terms of transactionblock production andpropagation the impact of our findings on decentralizedapplications can be foresighted

According to our blockchain fork results (Section 41)the lack of selfish mining in the real world was speculated bya very low stale block rate of Bitcoin network and prevalenceof nonearliest block endorsement by Ethereum miners Asprofitability of selfish mining encourages miners to behavein a way of producing more blockchain forks the perfor-mance degradation is proportionate to the number of minerswho adopt the selfish mining strategy the key performancemetrics affecting the blockchain application performance

such as node response time or block delivery time are shownto be noticeably degraded due to the selfish mining [62] Forexample decentralized identities issued or revoked on suchblockchains [63 64] cannot be responsively finalized due toinflated blockchain forks Our results show that the selfishmining is not prevalent in the real world thus the appli-cation performance impact is overrated even though it istheoretically shown that miners have every reason to beselfish [38] As for EOS we reported cases where a sequenceof (up to 12) blocks being stale are often observed in suc-cessive mining of two BPs however the rate is too low (ie004) to impact the performance of applications (Section32)

Transaction arrival processes being LRD (Section 51)pose a technical challenge in provisioning transactionprocessing scalability especially for Layer-2 blockchain ap-plication solutions [65 66] For example Layer-2 rollupsolutions require transaction relays which aggregate indi-vidual user transactions of a given blockchain applicationdeployed in the network often without a priori knowledge ofnetwork load One way of solving the problem is a properprioritization of transactions based on the applicationcontext

Lastly blockchain network partitioning can be thebiggest concern for blockchain service providers We ob-served that the increased numbers of peer connections inblockchain reference implementations effectively provide ahigher degree of information redundancy (Section 52)However increased number of peer connections can beexploitable for an attacker who has a denial-of-service attackvector or an invalid transaction initiated by a simple ap-plication bug can flood the network [45]

64 Limitation Our measurement study has several limi-tations First of all our results may only capture only a fewmonths of blockchain network operations In the meantimethe permissionless blockchain pieces of software are in activedevelopment for example Ethereum now utilizes the pooledtransaction delivery [67] instead of unsolicited transactiondelivery which was the only mode at the time of our

Table 10 Bitcoin disparately mempooled transactions

monitors mempooledti

monitors mempooledts

Transactioncount

7 1 26 (3824)6 2 14 (2059)5 3 10 (1471)4 4 5 (735)3 5 5 (735)2 6 3 (441)1 7 3 (441)5 1 1 (147)6 1 1 (147)

Sum 68 (10000)

Tincluded

Tstale

5 10 15 20 25 30 35 40 45 500 of peers

0

005

01

015

02

025

03Fr

eque

ncy

(a)

Tincluded

Tstale

0002004006008

01012014016

Freq

uenc

y

4030 500 10 20 of peers

(b)

Figure 17 Peer redundancy of transaction advertisement (a) Bitcoin (b) Ethereum

Security and Communication Networks 15

measurement Both cryptocurrency market values andblockchain network utilizations are rapidly increasing andthus miners are getting more motivated to optimize theirperformance for example Bitcoin fork probability has be-come far smaller than what is reported previously (seeSection 41)

Second the blockchain state information is not collected inour measurement Our analysis is performed based on onlyavailable information stored in block and transaction logs Wehave utilized an Ethereum archive node [44] to query historicalstate information (eg account balance or account nonce) inSection 42 However such proactive state replication is farmore complicated with EOS unless the full node is configuredto operate as a producing node and logging the state infor-mation thus EOS stale transactions could not be fully un-derstood without the missing EOS network state information

7 Related Work

71 Blockchain Data Analysis Historical transaction data ofBitcoin have often been studied for economic aspects such ascryptocurrency abuse [17] anti-money-laundering [18] andmonetary flow of businesses [19] However historicalblockchain data usually available from block explorer ser-vices are not sufficient for our research purpose

72 Blockchain Measurement Researchers have performedblockchain measurement studies to assess the degree ofdecentralization [20] to investigate demographic informa-tion of network nodes [34 68] to study mining pool be-havior [22] and to evaluate security of PoW blockchains [21]against known attacks such as double-spending attack [60]and selfish mining [37] Our work expands the under-standing of previous security evaluations with the keyfindings acquired from our large-scale transaction and blockmeasurement

73 Blockchain Attacks Partitioning attacks usually exploitvulnerable peer management mechanisms of Bitcoin [51]and Ethereum [52] Such attacks are also examined in thecontext of ISPrsquos BGP hijacking [53] and a stealthier variantrelieving the attacker from the risk of getting exposed [54]Cryptocurrency mining has been a popular subject inassessing the security of Bitcoin selfish mining [37] blockwithholding attack [36] and a mixed strategy [38] have beenstudied Double-spending attacks have been studied in thecontext of Bitcoin fast payments [60]

74 Block Explorer Services We have surveyed the popularblock explorer services of Bitcoin [5 10 12] Ethereum[10 13 16] and EOS [11 14 15] to see the availability ofinformation beyond what is recorded in the main chainblock data we have utilized in our study namely

(i) Stale blockstransactions no Bitcoin and EOS blockexplorers provide stale block information (A relatedstudy [36] has utilized a Bitcoin block explorer service[68] to retrieve stale blocks However the service has

been terminated in March 2019) All Ethereum blockexplorers provide only reported stale blocks (ie uncleblocks [23]) (Ethereum provides incentives for unclestale blocks [44] so that miners include them in theirmined blocks for profit)No block explorers provide stale transaction infor-mation unless one is currently pooled

(ii) Blocktransaction arrival times all block explorersprovide block timestamps that are recorded in theblock headers not the actual times of arrival Ourblockchain fork and gap analysis require measuredblock arrival times at multiple locations All blockexplorers show transaction timestamps identical to theblock timestamp to which the transactions belong(Recent Bitcoin transactions have different timestampsthan the block timestamps in [4] while the timestampsare only at a granularity of one minute) [69 70]

8 Conclusion

We have measured transaction and block arrival events ofthe three permissionless blockchains We have devised anoble analysis model and analyzed completeness of ourblock and transaction logs Finally we have studied thediscrepancy in measured events and arrival characteristics toshare our key findings including a false universal assumptionof previous mining-related studies

Data Availability

e measurement data used to support the findings of thisstudy have not been made available because they containprivate information that can be used to identify individualblockchain nodes

Disclosure

is is an extended and revised version of a conference paperpresented in IEEE ICDCS 2021 [41]

Conflicts of Interest

e authors declare that they have no conflicts of interest

Acknowledgments

e authors would like to thank Seungwon Woo DaegeunYoon and Changhyun Lee for helping them with themeasurement instrumentation is work was supported byElectronics and Telecommunications Research Institute(ETRI) grant funded by the Korean Government (21ZR1300Research on Intelligent Cyber Security and Trust Infra)

References

[1] S Nakamoto ldquoBitcoin a peer-to-peer electronic cash systemrdquo2019

[2] V Buterin ldquoEthereum white paperrdquo 2013 httpsethereumorgenwhitepaper

[3] Monero ldquoMonerordquo 2020 httpswebgetmoneroorg

16 Security and Communication Networks

[4] bitcoincashorg httpswwwbitcoincashorg[5] Blockchaincom httpswwwblockchaincom[6] Ripple ldquoXRP e best digital asset for global paymentsrdquo

2020 httpsripplecomxrp[7] I Foundation ldquoIotardquo 2021 httpswwwiotaorg[8] ldquoEosiordquo 2020 httpseosio[9] S Orsquoneal ldquoEos proves yet again that decentralization is not its

priorityrdquo 2018 httpscointelegraphcomnewseos-proves-yet-again-that-decentralization-is-not-its-priority

[10] Blockchair httpsblockchaircom[11] Bloksio httpsbloksio[12] BTCcom ldquoBitcoin block explorerrdquo 2021 httpsbtccom[13] Ethereum block explorer httpsethbtccom[14] eosflareio Eos block explorer httpseosflareio[15] EOSPark ldquoEos block explorerrdquo 2021 httpseosparkcom[16] Etherscan Ethereum explorer httpsetherscanio[17] S Lee C Yoon and H Kang ldquoCybercriminal minds An

investigative study of cryptocurrency abuses in the dark webrdquoin Proceedings of the Network and Distributed System SecuritySymposium pp 1ndash15 Internet Society San Diego CA USAFebruary 2019

[18] MMoser R Bohme and D Breuker ldquoAn inquiry into moneylaundering tools in the bitcoin ecosystemrdquo in Proceedings ofthe 2013 APWG eCrime Researchers summit pp 1ndash14 IEEESan Francisco CA USA September 2013

[19] M Lischke and B Fabian ldquoAnalyzing the bitcoin network thefirst four yearsrdquo Future Internet vol 8 no 1 2016

[20] A E Gencer S Basu I Eyal R V Renesse and E G SirerldquoDecentralization in bitcoin and ethereum networksrdquo inProceedings of the International Conference On FinancialCryptography and Data Security pp 439ndash457 SpringerNieuwport Curaccedilao February 2018

[21] A Gervais G O Karame KWust V Glykantzis H Ritzdorfand S Capkun ldquoOn the security and performance of proof ofwork blockchainsrdquo in Proceedings Of the 2016 ACM SIGSACConference on Computer and Communications Securitypp 3ndash16 Vienna Austria October 2016

[22] C Wang X Chu and Q Yang ldquoMeasurement and analysis ofthe bitcoin networks a view from mining poolsrdquo 2019httpsarxivorgabs190207549

[23] G Wood ldquoEthereum A secure decentralised generalisedtransaction ledgerrdquo Ethereum Project Yellow Paper vol 1512014

[24] ldquoTransactions protocol eosio developer docsrdquo 2018 httpsdeveloperseosiowelcomev20protocoltransactions_protocol

[25] Y Sompolinsky and A Zohar ldquoSecure high-rate transactionprocessing in bitcoinrdquo in Proceedings of the InternationalConference On Financial Cryptography and Data Securitypp 507ndash527 Springer San Juan PR USA January 2015

[26] Blockone ldquoConsensus protocolrdquo 2018 httpsdeveloperseosiowelcomev20protocolconsensus_protocol

[27] A Gervais H Ritzdorf G O Karame and S CapkunldquoTampering with the delivery of blocks and transactions inbitcoinrdquo in Proceedings Of the 22nd ACM SIGSAC ConferenceOn Computer and Communications Security pp 692ndash705Denver CO USA October 2015

[28] ldquoGithub Bit coinrdquo 2020 httpsgithubcombitcoinbitcoin[29] G Ethereum ldquoGo ethereumrdquo 2020 httpsgithubcom

ethereumgo-ethereum[30] Google ldquoGoogle cloudrdquo 2021 httpscloudgooglecom[31] ldquoHow to replay from a snapshotrdquo 2018 httpsdeveloperseos

iomanualseoslatestnodeosreplayshow-to-replay-from-a-snapshot

[32] C Decker and R Wattenhofer ldquoInformation propagation inthe bitcoin networkrdquo in Proceedings of the IEEE P2P 2013Proceedings pp 1ndash10 IEEE Trento Italy September 2013

[33] ldquoEthereum uncle raterdquo 2020 httpsychartscomindicatorsethereum_uncle_rate

[34] J A Donet C P Sola and J H Joancomartı ldquoe bitcoin p2pnetworkrdquo in Proceedings of the International Conference OnFinancial Cryptography and Data Security pp 87ndash102Springer Christ Church Barbados March 2014

[35] G S Davies ldquoBit-booster - offline commit graph drawingtoolrdquo 2016 httpbit-boostercomgraphhtml

[36] N T Courtois and L Bahack ldquoOn subversive miner strategiesand block withholding attack in bitcoin digital currencyrdquo2014 httpsarxivorgabs14021718

[37] I Eyal and E G Sirer ldquoMajority is not enough bitcoin miningis vulnerablerdquo in Proceedings of the International Conferenceon Financial Cryptography and Data Security pp 436ndash454Springer Christ Church Barbados March 2014

[38] Y Kwon D Kim Y Son E Vasserman and Y Kim ldquoBeselfish and avoid dilemmas fork after withholding (faw) at-tacks on bitcoinrdquo in Proceedings Of the 2017 ACM SIGSACConference On Computer and Communications Securitypp 195ndash209 Abu Dhabi UAE April 2017

[39] B Research ldquoDecentralisation governance and eos - a lostcaserdquo 2020 httpsresearchbinancecomenanalysiseos-governance

[40] B Wiki ldquoIrreversible transactions - finney attackrdquo 2012httpsenbitcoinitwikiIrreversible_Transactions∖Finney_attack

[41] J Poon and T Dryja ldquoe bitcoin lightning network scalableoff-chain instant paymentsrdquo 2016

[42] M Bartoletti and L Pompianu ldquoAn analysis of bitcoin op_return metadatardquo in Proceedings of the International Con-ference On Financial Cryptography and Data Securitypp 218ndash230 Springer Sliema Malta April 2017

[43] ldquoReplace by feerdquo 2018 httpsenbitcoinitwikiReplace_by_fee

[44] E Foundation ldquoNode and clientsrdquo 2020 httpsethereumorgendevelopersdocsnodes-and-clients

[45] H Heo and S Shin ldquoBehind block explorers public block-chain measurement and security implicationrdquo in Proceedingsof the 41th IEEE International Conference On DistributedComputing Systems IEEE Washington DC USA In pressWashington DC USA July 2021

[46] R Bowden H P Keeler A E Krzesinski and P G TaylorldquoBlock arrivals in the bitcoin blockchainrdquo 2018 httpsarxivorgabs180107447

[47] M E Crovella and A Bestavros ldquoExplaining world wide webtraffic self-similarityrdquo Technical Report Citeseer PrincetonNJ USA 1995

[48] H Zhang Y Shu and O Yang ldquoEstimation of hurst pa-rameter by variance-time plotsrdquo in Proceedings of the 1997IEEE Pacific Rim Conference on Communications Computersand Signal Processing PACRIM 10 Years Networkingthe Pacific Rim 1987-1997 IEEE Victoria BC CanadaAugust 1997

[49] A Feldmann ldquoCharacteristics of TCP connection arrivalsrdquo inSelf-Similar Network Traffic and Performance EvaluationK Park andWWillinger Eds pp 367ndash399Wiley HobokenNJ USA 2000

[50] RSK ldquoRSKrdquo 2021 httpswwwrskco[51] E Heilman A Kendler A Zohar and S Goldberg ldquoEclipse

attacks on bitcoinrsquos peer-to-peer networkrdquo in Proceedings of

Security and Communication Networks 17

the 24th USENIX Security Symposium pp 129ndash144 Wash-ington DC USA April 2015

[52] Y Marcus E Heilman and S Goldberg ldquoLow-resourceeclipse attacks on ethereumrsquos peer-to-peer networkrdquo IACRCryptology vol 2018 p 236 2018

[53] M Apostolaki A Zohar and L Vanbever ldquoHijacking bitcoinRouting attacks on cryptocurrenciesrdquo in Proceedings of the2017 IEEE Symposium On Security and Privacy (SP)pp 375ndash392 IEEE San Jose CA USA May 2017

[54] M Tran I Choi G J Moon A V Vu and M S Kang ldquoAstealthier partitioning attack against bitcoin peer-to-peernetworkrdquo in Proceedings of the IEEE Symposium On Securityand Privacy (SampP) San Francisco CA USA May 2020

[55] B I Proposal ldquoBip 0152rdquo 2016 httpsenbitcoinitwikiBIP_0152

[56] B Core ldquoBitcoin Core Version 01901 Release Noterdquo 2016httpsbitcoinorgenreleasev01901

[57] ldquoGeth v190rdquo 2019 httpsblogethereumorg20190710geth-v1-9-0

[58] ldquoProtocol documentationrdquo 2016 httpsenbitcoinitwikiProtocoltext_documentation

[59] C Feng and J Niu ldquoSelfish mining in ethereumrdquo in Pro-ceedings of the 2019 IEEE 39th International Conference OnDistributed Computing Systems (ICDCS) pp 1306ndash1316IEEE Dallas TX USA July 2019

[60] G O Karame E Androulaki and S Capkun ldquoDouble-spending fast payments in bitcoinrdquo in Proceedings of the 2012ACM Conference on Computer and Communications Securitypp 906ndash917 Raleigh NC USA October 2012

[61] P Das L Eckey T Frassetto et al ldquoFastkitten practical smartcontracts on bitcoinrdquo in Proceedimgs of the 28th USENIXSecurity Symposium (USENIX Security 19) pp 801ndash818Santa Clara CA USA August 2019

[62] S G Motlagh J Misic and V B Misic ldquoe impact of selfishmining on bitcoin network performancerdquo IEEE Transactionson Network Science and Engineering vol 8 no 1 pp 724ndash7352021

[63] A Muhle A Gruner T Gayvoronskaya and C Meinel ldquoAsurvey on essential components of a self-sovereign identityrdquoComputer Science Review vol 30 pp 80ndash86 2018

[64] M Toorani and C Gehrmann ldquoA decentralized dynamic pkibased on blockchainrdquo in Proceedings Of the 36th Annual ACMSymposium On Applied Computing pp 1646ndash1655 GwangjuKorea March 2021

[65] E foundation ldquoOptimistic-rollupsrdquo 2021 httpsdocsethhubioethereum-roadmaplayer-2-scalingoptimistictext_rollups

[66] ldquoZk-rollupsrdquo 2021 httpsdocsethhubioethereum-roadmaplayer-2-scalingzk-rollups

[67] E foundation ldquoEthereumwire protocolrdquo 2019 httpsgithubcomethereumdevp2pblobmastercapseth

[68] S K Kim Z Ma S Murali J Mason A Miller andM BaileyldquoMeasuring ethereum network peersrdquo in Proceedings of theInternet Measurement Conference 2018 pp 91ndash104 BostonMA USA October 2018

[69] Symmetricom ldquoDelivering sub-microsecond accurate time tolinux applications around the worldrdquo 2012 httpwwwchronoscoukfilespdfswpsWP_AccurateTimeForLinuxApplicationspdf

[70] Ycharts ldquoBlocktrail blockchain data query service (termi-nated)rdquo 2019 httpsblocktrailcom

18 Security and Communication Networks

probability by labeling whether or not the chosen block (byma) is the earliest propagated one e ldquoearliestrdquo label in-dicates that the block to which the newly mined block (byma) is added has been observed as the earliest one to arrivecongruently among all eight measurement locations (Asblock arrival times are measured in eight different locationsthe arrival order can be conflicting e ldquomixedrdquo labelrepresents the conflicting cases) For example the topranked pool SparkPool chose the earliest arriving blocksim55 of the time 3409 out of 6234 blocks among the other2825 blocks that were added to nonearliest previous blocksSparkPoolrsquos own blocks were chosen over others 1211 timeswhile other poolsrsquo blocks were preferred to SparkPoolrsquos only24 times In the meantime Nanopool chose the earliest one amajority of the time For the top 25 ranked mining pools onlyfour of them added blocks to the earliest arriving blocks morethan 90 of the timeis contradicts the earliest propagatedblock endorsement assumption that is broadly adopted inmining-related research [36ndash38]

One possible explanation of the phenomenon is that themining pools adopt their own block preferring strategy as asimple precautionary defense against yet unknown selfishmining pools the profitability of selfish mining largelydepends on the probability of honest pools adding to theattacking poolrsquos branch

413 Cut-Tail Fork Pattern of EOS BPs We find that theEOS fork episodes occur in a way that BPs are cutting the tailof the previous BPrsquos produced blocks EOS adopts the DPoSconsensus mechanism [26] 21 block producers (BPs) areelected by voting and scheduled to produce 12 consecutiveblocks in 6 seconds (ie 500ms for each block) in the al-phabetical order of their names Figure 10 shows thenumbers of switching (by schedule) events and cut-tail forkevents of all immediate BP pairs We observe a high fre-quency of such events when bitfinexeos1 is producing blocksby appending to big onersquos blocks while there are accusationsof BPrsquos dishonest behaviors we believe that the reportedbitfinexrsquos performance problem is the compelling reason forthe phenomenon [39]

42 Unseen and Stale Transactions

421 Private Transaction Mining Unseen transactions arecharacterized by the strong evidence that implies that theunseen transactions are indeed never advertised to the net-work Table 6 categorizes 9587 of Ethereum unseentransactions by using the from addresses of the transactions(We use prefixes followed by ⋆ in presenting hash valueseg address (ie pubkey hash) and txid for brevity Weunderstand this does not entirely anonymize identity as thereaders can verify their results against ours by matching theprefixes) Public names are retrieved from Etherscan [16] Aminer is specified in the table only if all blocks that includethe unseen transactions with the from address are con-gruently mined by that single miner It shows that most ofthe unseen transactions are indeed the block minerrsquos owntransactions

Table 7 shows unseen Bitcoin transactions categorized bythe identified reasons sim 67 of the unseen transactions areeither zero-fee transactions or zero-fee-transaction-dependenttransactionsWe define a transaction t isin transactions(b) as adependent transaction if at least one of input transactions oft is included in the same block b

Bitcoin Core [28] implementation does not propagatetransactions with zero transaction fee Also a dependenttransaction cannot be mempooled until the transaction towhich it is dependent is mempooled consequently it cannotbe relayed to peers e Bitcoin Core mempool imple-mentation justifies the inexistence of zero-fee and zero-fee-dependent transactions from our measurement Existence ofa stale transaction which shares the same transaction inputwith the unseen transaction may imply a possible double-spend attempt a variant [40] involving private mining of ablock with ti while advertising a conflict transaction tj suchthat inputs(ti)cap inputs(tj)neempty we have observed 27 suchunseen transactions without a certainty of attack intentionsor if they are not indeed advertised Lastly multisig trans-action inputs often imply off-chain protocols where signedtransactions are exchanged out-of-band [41] and havingOP_RETURN transaction output implies special purposeprotocols of Bitcoin for example sidechains where theirrelationship with miners require further investigation [42]e presence of unseen transactions by either privatetransaction mining or potential out-of-band delivery oftransactions has a subtle security implication One obviousside effect is privatization of transaction fees the transactionfees of privately mined ones are exclusively obtainable by theprivate miner alone unless the network is fully utilized Ifthe network is fully utilized a miner is forced to include herprivate transactions at the expense of not including othertransactions as the block capacity is limited

422 Conflict Stale Transactions Stale transactions arenetwork-transmitted transactions that are not included inany of the blocks

Table 8 shows the stale transaction counts observed ateach location e stale transactions account for 020369 and 047 of Bitcoin Ethereum and EOS transac-tions respectively Ethereum transactions had an order ofmagnitude more chance of being stale than others

As for public blockchains with transaction fees that isBitcoin and Ethereum stale transactions are mostly at-tributable to conflict Table 9 summarizes the identifiedreasons for transactions being stale A stale Bitcoin trans-action is attributable to conflict if there are one or moretransactions sharing at least one transaction input (ie vin)

An Ethereum transaction is attributable to conflict ifthere is another transaction with the same nonce from thesame account A widely known reason for two or moretransactions being in conflict is transaction replacementsuch as replace-by-fee [43] On the other hand slightly morethan 5 of Bitcoin transactions are stale because at least oneof their transaction inputs is also stale

On the other hand roughly one out of ten staleEthereum transactions is attributable to improper ordering

Security and Communication Networks 9

of nonce (e transaction nonce should be equal to thenumber of transactions sent from the address) nonce is toohigh (983) or too low (002) Last but not least 727 ofstale transactions are not included in blocks because theaccount is not sufficiently funded (An Ethereum accountshould have balance ge value+ gastimes gas price to execute thetransaction [44]) An Ethereum account can be

insufficiently funded when executing a transaction for anumber of reasons [45]

423 EOS Transaction Discrepancy EOS exhibits unseenand stale transactions far different from those of Bitcoin orEthereum that is the PoW blockchains with transaction feeEOS software is not bundled with peer discovery rather thenode operator is required to look up for candidate BPrsquospeering services timely delivery of blockchain data andreliability of the node is dependent on the peering nodes ofchoice (Indeed we have experienced service disruption bydisconnecting from peers for unknown reasons)e notionof being conflict in two or more transactions that is themost frequent reason for transactions being stale for Bitcoinand Ethereum is not applicable to EOS (EOS adopts theaccount model without transaction ordering per accountthus there should be no conflict transaction outputs or thesame account nonce) On the other hand EOS requires

eosh

uobi

pool

-eos

infst

ones

eosfl

ytom

ars-

eosh

uobi

pool

zbeo

sbp1

1111

-atti

clab

eosb

attic

labe

osb-

big

one

hoo

com

-new

dex

bpw

hale

exco

m-z

beos

bp11

111

start

eosio

bp-w

hale

exco

meo

sdot

wik

ibp-

eosfl

ytom

ars

eosc

anno

nchn

-eos

dotw

ikib

pbi

gon

e-bi

tfine

xeos

1eo

sinfst

ones

-eos

iom

eeto

nehe

lloeo

scnb

p-ho

oco

meo

slaom

aoco

m-e

ossv

12eo

ssv

slow

mist

iobp

-sta

rteo

siobp

eoss

v12e

ossv

-hel

loeo

scnb

peo

sbei

jingb

p-eo

scan

nonc

hneo

siosg

1111

1-eo

slaom

aoco

meo

siom

eeto

ne-e

osio

sg11

111

bitfi

nexe

os1-

cert

ikeo

sorg

new

dex

bp-s

low

mist

iobp

coch

ainw

orld

-eos

asia

1111

1bi

tfine

xeos

1-co

chai

nwor

ldce

rtik

eoso

rg-c

ocha

inw

orld

eosa

sia11

111-

eosb

eijin

gbp

new

dex

bp-o

kcap

italb

p1eo

siom

eeto

ne-e

osla

omao

com

okca

pita

lbp1

-slo

wm

istio

bpco

chai

nwor

ld-e

osbe

ijing

bpne

wde

xbp

-sta

rteo

siobp

eosa

sia11

111-

eosc

anno

nchn

eosla

omao

com

-hel

loeo

scnb

pco

chai

nwor

ld-e

osca

nnon

chn

cert

ikeo

sorg

-eos

beiji

ngbp

eoss

v12e

ossv

-hoo

com

bitfi

nexe

os1-

eosa

sia11

111

eosin

fston

es-e

osla

omao

com

okca

pita

lbp1

-sta

rteo

siobp

BP switching (left)Cut-tail (right)

0

5000

10000

15000

20000

25000

BP sw

itchi

ng ev

ents

0

100

200

300

400

500

cu

t-tai

l eve

nts

Figure 10 EOS BP switching and cut-tail events

Table 6 Ethereum unseen transactions

From address Public name Transaction count Miner0xea67⋆ Ethermine 128145 (7242) Ethermine0x2a65⋆ DwarfPool 22955 (1297) DwarfPool0x8fd0⋆ Unknown 11346 (641) SparkPool0x829b⋆ F2Pool 4453 (251) F2Pool0x4c54⋆ HiveonPool 1135 (064) SparkPool0x99c8⋆ BeePool 468 (026) BeePool0xdba7⋆ Unknown 348 (020) UUPool0x464b⋆ FKPool 340 (019) FKPool0xf687⋆ Unknown 217 (012) AntPool0xa801⋆ Unknown 151 (009) AntPool0xbe7c⋆ Unknown 126 (007) AntPool0xb96f⋆ Unknown 101 (006) AntPool

Sum 169785 (9587)

Table 7 Bitcoin unseen transactions

Category Transactioncount

Zero-fee transaction 148 (5068)Zero-fee-transaction-dependent transaction 48 (1644)Multisig transaction input 43 (1473)Conflict with stale transaction 27 (925)OP_RETURN transaction output 26 (890)Sum 292 (10000)

10 Security and Communication Networks

contract users to stake tokens for CPU time that can bededucted by transaction executions A requested transactioncan be rejected thus being stale due to the lack of CPU timeor other resources similarly Replaying the entire statechanges of EOS to find out stale transactions due to lack ofresources is not possible unless all transaction and state logsof the entire BPs are available

On the other hand EOS transactions have two additionalattributes which are not available in the Bitcoin or Ethereumtransaction structures

(i) Reference block every EOS transaction refers to ablock by specifying the block number and hash notonly to prevent replay attacks but also to signal thenetwork that the userrsquos stake is on a specific fork

(ii) Expiration time EOS transactions have explicitexpiration times

If a transactionrsquos reference block is not part of the mainchain at the time of execution the transaction cannot beexecuted (and thus cannot be included in a block) We haveidentified that 18 of stale transactions apply to this case Tofurther identify unknown reasons we consider four timedevents that are relevant to transaction execution

(i) Last irreversible block arrival time arrival(blib) thearrival time of transactionrsquos reference block EOStransactions by default refer to the last irreversibleblock (LIB) [26]

(ii) Head block arrival time arrival(bhead) the scheduledtime of the head block when transaction is arrived

(iii) Transaction arrival time arrival(t) the arrival timeof transaction t

(iv) Expiration time exp(t) the expiration time oftransaction t

e three time differences that is Δexp Δincl and Δtrxare investigated to find characteristics of unseen (Tunseen)and stale (Tstale) transactions over the normal transactions(Tincluded) Figure 11 illustrates the relevant events and timedifferences of them Δexp measures the time difference be-tween the two scheduled (ie virtually timed) events Δincland Δtrx are defined by the arrival events to our monitornode Figure 12 shows the distributions of Δexp Δincl andΔtrx We find that unseen transactions have prolonged Δinclimplying that the delay of newly produced blocks can causenewly generated transactions not promptly delivered be-cause the sync manager is in the Head Catch-Up mode astransactions are only transferred in In-Sync mode by itsdesign [24] Stale transactions with relatively small Δtrx canbe attributable to problematic dApp implementations re-ferring to non-LIB blocks the chain instability caused byblockchain fork mostly due to the cut-tail behavior shown inSection 41 can cause transactions being rejected for im-mature block reference

However we do not find any reason attributable to thetransaction expiration Although the unseen transactionstend to have smallΔexp the expiration times are only as smallas 30 seconds (ie the default expiration time) Particularlyone or more EOS applications set the expiration time to180 seconds (other than the default 30 seconds) and morethan half of the stale transactions are invoked by thoseapplications

While transaction is the smallest unit of execution inBitcoin and Ethereum the unit of contract execution in EOSis action [24] A transaction consists of one or more actionsHowever the constituent actions in a single transactioncannot be separately advertised or executed accordingly weapply the identical transaction model to EOS without loss ofgenerality

5 Block and TransactionArrival Characteristics

51 Arrival Processes All three blockchains we study in thispaper are designed to publish capacity constrained blocks intargeted regular time intervals An incarnation of suchdesign is expected to exhibit a Poisson block arrival processWhile it is claimed that Bitcoin block arrivals do not entirelyexhibit a homogeneous Poisson process due to its difficultadjustment mechanism [46] transaction arrival processes ofblockchains are not studied in the literature to the best of ourknowledge A particularly meaningful step toward under-standing the arrival process of events generated by a complexsystem is examining if the arrival events are independent orexhibiting a correlated structure [47]

e variance-time log-log plots [48] of the block andtransaction arrival event time series are depicted in

Table 8 Stale transactions

Region Bitcoin Ethereum EOSAsia-East 41720 1170706 mdashAsia-South 41653 1194018 504277Europe-North 41693 1192435 470480Europe-West 41668 1123680 450140North America-Northeast 41703 1212210 588711US-Central 41683 1212389 505160US-East 41692 1186488 mdashUS-West 41672 1167627 480207Combined 42023 1351847 672999

Table 9 Identified reasons of stale transactions

Category Transaction count(a) Bitcoin

Conflict 39408 (9378)Stale transaction input 2307 (549)Conflict and stale transaction input 308 (073)Sum 42023 (10000)

(b) EthereumConflict 1208588 (8924)Nonce (skipped) 133161 (983)Nonce (used) 251 (002)Insufficient fund 9847 (727)Sum 1351847 (9982)

(c) EOSFork 12106 (180)Others 660893 (9820)Sum 672999 (10000)

Security and Communication Networks 11

Figure 13(a) As regards the block arrival processes Bitcoinblock arrivals exhibit a linear slope β minus23 e estimatedHurst parameter H 1 + β2 43 implies that the processis not a homogeneous Poisson process but LRD (Long-Range Dependent) contrary to what is expected for a regularinterval event generation [46] Ethereum block arrivalsapproximate the Bitcoinrsquos except for the high aggregationlevel due to high stale block rate EOS block arrivals incontrast follow the slope β minus1 in the low aggregation levelas the block generation is indeed regularly scheduled

Figure 14 shows the variance-time plot of Ethereum andEOS block arrival time series by taking all block arrivalevents (Bobs) and main chain block arrivals only (Bmain) Weconfirm that Ethereum block arrivals indeed exhibit astraight line (close to Bitcoin) if excluding stale blocksHowever EOS block arrivals do not exhibit a straight line

even if we exclude stale blocks due to delayed burst blockarrivals possibly due to cut-tail fork patterns (see Section41)

e transaction arrival processes of all three blockchainsappear to exhibit LRD with Hurst parameter Hgt 56 asβltminus13 To further identify analytical distributions that fitbest the empirical ones the coefficient of variation (σμ) andskewness (ie the standardized third moment) of transac-tion interarrival times are computed for every measurementdataset and compared to the relationships expected for theexponential lognormal Weibull and Gamma distributionsin Figure 13(b) We find that Bitcoin Ethereum and EOStransaction interarrival times are fit best Gamma Weibulland lognormal distribution respectively Individual datasetsare also examined for the fitness of the distribution to findthat the empirical distribution fits the analytical distribution

Virtualclock

Time

Transaction initiator

Time

Blockproducer

Time

Monitornode

Time

Scheduled block time of blib

Scheduled block time of bhead

Scheduled block time of bincl

1 Produce and propagate blib

2 Produce and propagate bhead

Expiration time of t

4 Produce and propagate bincl

Δexp

Δtrx

Δincl

3 Create and propagate t

Figure 11 EOS transaction analysis model

Tincluded

Tstale

Tunseen

0010203040506070809

1

Cum

ulat

ive f

requ

ency

100 200 300 400 5000Time difference (seconds)

(a)

Tincluded

Tunseen

01 1 10 100 1000001Time difference (seconds)

0010203040506070809

1

Cum

ulat

ive f

requ

ency

(b)

Tincluded

Tstale

0010203040506070809

1

Cum

ulat

ive f

requ

ency

01 1 10 100 1000001Time difference (seconds)

(c)

Figure 12 EOS transaction timing analysis (a) Δexp (b) Δincl (c) Δtrx

12 Security and Communication Networks

well except for the small interarrival time ranges For ex-ample Figure 15 depicts the CDF of Ethereum transactioninterarrival times observed in US-West Although the em-pirical distribution fits Weibull with parameters computedwith the maximum likelihood estimator [49] sample pointsunder several milliseconds appear to be unreliable (We areyet unaware of the reason However it is known that thetime source of commodity operating systems is not accurateand we need an external time source for accurate sub-millisecond timing measurement [50])

52AdvertisementRedundancy Bitcoin and Ethereum nodepieces of software are implemented to maintain a large

number of peer connections with multiple random remotenodes Bitcoin Core can connect up to 125 peers where 8 ofthem are outbound connections Go Ethereum maintains 50peer connections where 16 of them are outbound by default(see Table 1) On the other hand partitioning attacks aredeveloped to isolate a blockchain node from the others bytampering with all such peer connections Partitioning at-tacks usually exploit vulnerable peer management mecha-nisms of Bitcoin [51] and Ethereum [52] Such attacks arealso examined in the context of ISPrsquos BGP hijacking [53] anda stealthier variant relieving the attacker from the risk ofgetting exposed [54] e attacks often rely on imple-mentation vulnerabilities for efficient eclipsing of peerswhile known vulnerabilities are getting addressed for ex-ample the lack of parallel block download sessions causing

Slope = ndash1

Trx BitcoinTrx EthereumTrx EOS

Blk BitcoinBlk EthereumBlk EOS

ndash12

ndash10

ndash8

ndash6

ndash4

ndash2

0Lo

g no

rmal

ized

var

ianc

e

124 6 10 140 2 8Aggregation level

(a)

Lognormal

Weibull

Gamma

Exponential

BitcoinEthereumEOS

0

5

10

15

20

Stan

dard

ized

third

mom

ent

1 2 3 40Coefficient of variation

(b)

Figure 13 Transaction arrival characteristics (a) Variance-time plot of block and transaction arrivals (b) Cov versus skewness oftransaction interarrival times

Ethereum - Bobs

Ethereum - Bmain

EOS - Bobs

EOS - Bmain

ndash12

ndash10

ndash8

ndash6

ndash4

ndash2

0

Log

norm

aliz

ed v

aria

nce

2 4 6 8 10 12 140Aggregation level

Figure 14 Variance-time plot of block arrivals including staleblocks (Bobs) and excluding stale blocks (Bmain)

EmpiricalExponential μ = 0024

Lognormal μ = 00354 σ2 = 00486Pareto k = 0000212 a = 0231Weibull c = 0589 a = 00147

00001 0001 001 01 1000001Time (seconds)

0

02

04

06

08

1

Cum

ulat

ive f

requ

ency

Figure 15 Empirical and fitted analytical distributions of Ether-eum transaction interarrival times

Security and Communication Networks 13

temporary denial of blocks (reported in [27] and fixed byrecommending three concurrent download sessions in [55])let attackers successfully partition the node without eclipsingall peer connections [53] A simple countermeasure of in-creasing the number of peer connections on the other handis applied to the reference public blockchain implementa-tions [56 57] to inflate attack complexity

We investigate the degree of a peerrsquos advertisementredundancy on newly generated blocks and transactions toevaluate the efficacy of partitioning attacks and the coun-termeasure of increasing the number of peer connectionsFigure 16 shows how redundantly newly generated blockinformation is offered by peers Bitcoin nodes have main-tained sim43 peer connections that is 8 outbound and ad-ditional 35 inbound connections on average and Ethereumnodes record all 50 peer connections established during theentire observation period

For each newly generated block one-third of peersadvertised the block header to our Bitcoin node and morethan 90 of Ethereum peers signaled availability of theblocks In consequence successfully partitioning a noderequires compromise of peers proportional to the totalnumber of peer connections Increasing the number of peerconnections will burden the attacker linearly as expected

Figure 17 shows how redundantly the newly generatedtransaction information is offered by peers While one out ofthree Bitcoin peers also advertises new transactions viaINVENTORYmessage [58] half of the Ethereum peers havesent new transactions to our node in average Bitcoin andEthereum blocks are advertised with the block header(rather than the direct delivery of all block contents) Bitcointransactions are also advertised with INVENTORY messagebefore the whole contents are transferred HoweverEthereum transaction data that is the entire contents aredirectly sent by peers (Ethereum now has a pooled trans-action delivery model in its newer ETH64 protocol [30])We also find that there are cases with much less advertisedtransactions and have identified that they are indeed mostlystale ones stale transactions are mostly due to conflict (seeSection 42) and the nodes that already queued the conflicttransaction will not relay the stale one

6 Discussion

61 Implication on Mining Attacks Cryptocurrency mininghas been a popular subject in assessing the security ofBitcoin selfish mining [37] block withholding attack [36]and a mixed strategy [38] have been studied Although it isshown that selfish behavior in mining is always moreprofitable than being honest without need for a mutualagreement of not attacking each other [38] we find thatselfish mining is not the preferred strategy All selfish miningstrategies will result in blockchain forks but we observe avery low fork probability (ie 004) for Bitcoin On theother hand selfish mining on Ethereum has been studiedonly recently to unanimously claim that selfish mining isalso profitable for Ethereum miners however it is lessprofitable than Bitcoin due to its uncle reward system [59]Our result in Section 4 shows that a majority of Ethereum

miners choose to add to their own produced blocks over theearliest propagated blocks How does this affect the selfishmining strategy

e selfish mining strategy assumes a parameter c whichdefines the fraction of honest minersrsquo mines on the attackerrsquosfork branch (e parameter comes into play in case (f ) of[27]) If the attacking pool has a network-wise superiorposition in block propagation (ie cgt 05) the selfishmining strategy is profitable for pools with proportionalmining power αgt 25 [37] Absolute network inferiority(ie c 0 due to a defensive mining strategy such as the onepresented in Section 41) increases the required miningpower to 33 the 33 mining power appears to be sig-nificantly harder to achieve in the real world [20]

As for the FAW (Fork-After-Withholding) attackstrategy [38] the network capability parameter C defines theprobability that an attackerrsquos FPoW (Full Proof-of-Work)block (during infiltration mining) is selected as a main chainblock C affects both the attack reward and whether theminerrsquos dilemma holds or not in the mutual attacking gameAs an example case (Section 9 of [38]) of a two-pool gamebetween F2Pool and BitFury the absolute network inferi-ority drops C from 0914 to 03 to make it a dilemmatic gameagain Unfortunately minersrsquo own block preferences cannotbe directly transferred to a single parameter of c or C it callsfor a model change from previous mining studies

62 Conflict Transactions and Double-Spending AttacksDouble-spending attacks have been studied in the context ofBitcoin fast payments where zero or only one confirmation isrequired to complete an offline merchandise transaction[60] real-world cases where two conflict transactions dis-parately arrive at different measurement locations mayimply such attacks Table 10 shows the cases where twotransactions are in conflict (and thus only one of themis included in a block ie inputs(ti)cap inputs(ts)neemptyand existb isin Bmain ti isin transactions(b) (∄b isin Bmain ts isintransactions(b) is indisputable given a consistent transactionledger)) and two different subsets of the monitors havemempooled either one of them We also have identified 27unseen transactions implying possible one-confirmationattack variant requiring the private mining (ie not ad-vertising the double-spending transaction to the network) in

5 10 15 20 25 30 35 40 45 500 of peers

0

005

01

015

02

025

Freq

uenc

y

BitcoinEthereum

Figure 16 Peer redundancy of block advertisement

14 Security and Communication Networks

Section 42 As for the countermeasure of such attacks bydeploying monitors [60] deployment of 8 monitors in thenetwork to detect the attacks would fail at most 27 out of 95times (sim30) assuming that those 27 unseen transactionswe have identified are initially advertised to the network

63 Potential Impact on Blockchain ApplicationsEthereum and EOS are the most widely used smart contractplatforms fostering various decentralized applications Bit-coin which lacks the capability of executing complex smartcontract codes is also recently utilized to execute smartcontracts for decentralized applications [50 61] Eventhough our work focuses on the fundamental blockchainmechanisms in terms of transactionblock production andpropagation the impact of our findings on decentralizedapplications can be foresighted

According to our blockchain fork results (Section 41)the lack of selfish mining in the real world was speculated bya very low stale block rate of Bitcoin network and prevalenceof nonearliest block endorsement by Ethereum miners Asprofitability of selfish mining encourages miners to behavein a way of producing more blockchain forks the perfor-mance degradation is proportionate to the number of minerswho adopt the selfish mining strategy the key performancemetrics affecting the blockchain application performance

such as node response time or block delivery time are shownto be noticeably degraded due to the selfish mining [62] Forexample decentralized identities issued or revoked on suchblockchains [63 64] cannot be responsively finalized due toinflated blockchain forks Our results show that the selfishmining is not prevalent in the real world thus the appli-cation performance impact is overrated even though it istheoretically shown that miners have every reason to beselfish [38] As for EOS we reported cases where a sequenceof (up to 12) blocks being stale are often observed in suc-cessive mining of two BPs however the rate is too low (ie004) to impact the performance of applications (Section32)

Transaction arrival processes being LRD (Section 51)pose a technical challenge in provisioning transactionprocessing scalability especially for Layer-2 blockchain ap-plication solutions [65 66] For example Layer-2 rollupsolutions require transaction relays which aggregate indi-vidual user transactions of a given blockchain applicationdeployed in the network often without a priori knowledge ofnetwork load One way of solving the problem is a properprioritization of transactions based on the applicationcontext

Lastly blockchain network partitioning can be thebiggest concern for blockchain service providers We ob-served that the increased numbers of peer connections inblockchain reference implementations effectively provide ahigher degree of information redundancy (Section 52)However increased number of peer connections can beexploitable for an attacker who has a denial-of-service attackvector or an invalid transaction initiated by a simple ap-plication bug can flood the network [45]

64 Limitation Our measurement study has several limi-tations First of all our results may only capture only a fewmonths of blockchain network operations In the meantimethe permissionless blockchain pieces of software are in activedevelopment for example Ethereum now utilizes the pooledtransaction delivery [67] instead of unsolicited transactiondelivery which was the only mode at the time of our

Table 10 Bitcoin disparately mempooled transactions

monitors mempooledti

monitors mempooledts

Transactioncount

7 1 26 (3824)6 2 14 (2059)5 3 10 (1471)4 4 5 (735)3 5 5 (735)2 6 3 (441)1 7 3 (441)5 1 1 (147)6 1 1 (147)

Sum 68 (10000)

Tincluded

Tstale

5 10 15 20 25 30 35 40 45 500 of peers

0

005

01

015

02

025

03Fr

eque

ncy

(a)

Tincluded

Tstale

0002004006008

01012014016

Freq

uenc

y

4030 500 10 20 of peers

(b)

Figure 17 Peer redundancy of transaction advertisement (a) Bitcoin (b) Ethereum

Security and Communication Networks 15

measurement Both cryptocurrency market values andblockchain network utilizations are rapidly increasing andthus miners are getting more motivated to optimize theirperformance for example Bitcoin fork probability has be-come far smaller than what is reported previously (seeSection 41)

Second the blockchain state information is not collected inour measurement Our analysis is performed based on onlyavailable information stored in block and transaction logs Wehave utilized an Ethereum archive node [44] to query historicalstate information (eg account balance or account nonce) inSection 42 However such proactive state replication is farmore complicated with EOS unless the full node is configuredto operate as a producing node and logging the state infor-mation thus EOS stale transactions could not be fully un-derstood without the missing EOS network state information

7 Related Work

71 Blockchain Data Analysis Historical transaction data ofBitcoin have often been studied for economic aspects such ascryptocurrency abuse [17] anti-money-laundering [18] andmonetary flow of businesses [19] However historicalblockchain data usually available from block explorer ser-vices are not sufficient for our research purpose

72 Blockchain Measurement Researchers have performedblockchain measurement studies to assess the degree ofdecentralization [20] to investigate demographic informa-tion of network nodes [34 68] to study mining pool be-havior [22] and to evaluate security of PoW blockchains [21]against known attacks such as double-spending attack [60]and selfish mining [37] Our work expands the under-standing of previous security evaluations with the keyfindings acquired from our large-scale transaction and blockmeasurement

73 Blockchain Attacks Partitioning attacks usually exploitvulnerable peer management mechanisms of Bitcoin [51]and Ethereum [52] Such attacks are also examined in thecontext of ISPrsquos BGP hijacking [53] and a stealthier variantrelieving the attacker from the risk of getting exposed [54]Cryptocurrency mining has been a popular subject inassessing the security of Bitcoin selfish mining [37] blockwithholding attack [36] and a mixed strategy [38] have beenstudied Double-spending attacks have been studied in thecontext of Bitcoin fast payments [60]

74 Block Explorer Services We have surveyed the popularblock explorer services of Bitcoin [5 10 12] Ethereum[10 13 16] and EOS [11 14 15] to see the availability ofinformation beyond what is recorded in the main chainblock data we have utilized in our study namely

(i) Stale blockstransactions no Bitcoin and EOS blockexplorers provide stale block information (A relatedstudy [36] has utilized a Bitcoin block explorer service[68] to retrieve stale blocks However the service has

been terminated in March 2019) All Ethereum blockexplorers provide only reported stale blocks (ie uncleblocks [23]) (Ethereum provides incentives for unclestale blocks [44] so that miners include them in theirmined blocks for profit)No block explorers provide stale transaction infor-mation unless one is currently pooled

(ii) Blocktransaction arrival times all block explorersprovide block timestamps that are recorded in theblock headers not the actual times of arrival Ourblockchain fork and gap analysis require measuredblock arrival times at multiple locations All blockexplorers show transaction timestamps identical to theblock timestamp to which the transactions belong(Recent Bitcoin transactions have different timestampsthan the block timestamps in [4] while the timestampsare only at a granularity of one minute) [69 70]

8 Conclusion

We have measured transaction and block arrival events ofthe three permissionless blockchains We have devised anoble analysis model and analyzed completeness of ourblock and transaction logs Finally we have studied thediscrepancy in measured events and arrival characteristics toshare our key findings including a false universal assumptionof previous mining-related studies

Data Availability

e measurement data used to support the findings of thisstudy have not been made available because they containprivate information that can be used to identify individualblockchain nodes

Disclosure

is is an extended and revised version of a conference paperpresented in IEEE ICDCS 2021 [41]

Conflicts of Interest

e authors declare that they have no conflicts of interest

Acknowledgments

e authors would like to thank Seungwon Woo DaegeunYoon and Changhyun Lee for helping them with themeasurement instrumentation is work was supported byElectronics and Telecommunications Research Institute(ETRI) grant funded by the Korean Government (21ZR1300Research on Intelligent Cyber Security and Trust Infra)

References

[1] S Nakamoto ldquoBitcoin a peer-to-peer electronic cash systemrdquo2019

[2] V Buterin ldquoEthereum white paperrdquo 2013 httpsethereumorgenwhitepaper

[3] Monero ldquoMonerordquo 2020 httpswebgetmoneroorg

16 Security and Communication Networks

[4] bitcoincashorg httpswwwbitcoincashorg[5] Blockchaincom httpswwwblockchaincom[6] Ripple ldquoXRP e best digital asset for global paymentsrdquo

2020 httpsripplecomxrp[7] I Foundation ldquoIotardquo 2021 httpswwwiotaorg[8] ldquoEosiordquo 2020 httpseosio[9] S Orsquoneal ldquoEos proves yet again that decentralization is not its

priorityrdquo 2018 httpscointelegraphcomnewseos-proves-yet-again-that-decentralization-is-not-its-priority

[10] Blockchair httpsblockchaircom[11] Bloksio httpsbloksio[12] BTCcom ldquoBitcoin block explorerrdquo 2021 httpsbtccom[13] Ethereum block explorer httpsethbtccom[14] eosflareio Eos block explorer httpseosflareio[15] EOSPark ldquoEos block explorerrdquo 2021 httpseosparkcom[16] Etherscan Ethereum explorer httpsetherscanio[17] S Lee C Yoon and H Kang ldquoCybercriminal minds An

investigative study of cryptocurrency abuses in the dark webrdquoin Proceedings of the Network and Distributed System SecuritySymposium pp 1ndash15 Internet Society San Diego CA USAFebruary 2019

[18] MMoser R Bohme and D Breuker ldquoAn inquiry into moneylaundering tools in the bitcoin ecosystemrdquo in Proceedings ofthe 2013 APWG eCrime Researchers summit pp 1ndash14 IEEESan Francisco CA USA September 2013

[19] M Lischke and B Fabian ldquoAnalyzing the bitcoin network thefirst four yearsrdquo Future Internet vol 8 no 1 2016

[20] A E Gencer S Basu I Eyal R V Renesse and E G SirerldquoDecentralization in bitcoin and ethereum networksrdquo inProceedings of the International Conference On FinancialCryptography and Data Security pp 439ndash457 SpringerNieuwport Curaccedilao February 2018

[21] A Gervais G O Karame KWust V Glykantzis H Ritzdorfand S Capkun ldquoOn the security and performance of proof ofwork blockchainsrdquo in Proceedings Of the 2016 ACM SIGSACConference on Computer and Communications Securitypp 3ndash16 Vienna Austria October 2016

[22] C Wang X Chu and Q Yang ldquoMeasurement and analysis ofthe bitcoin networks a view from mining poolsrdquo 2019httpsarxivorgabs190207549

[23] G Wood ldquoEthereum A secure decentralised generalisedtransaction ledgerrdquo Ethereum Project Yellow Paper vol 1512014

[24] ldquoTransactions protocol eosio developer docsrdquo 2018 httpsdeveloperseosiowelcomev20protocoltransactions_protocol

[25] Y Sompolinsky and A Zohar ldquoSecure high-rate transactionprocessing in bitcoinrdquo in Proceedings of the InternationalConference On Financial Cryptography and Data Securitypp 507ndash527 Springer San Juan PR USA January 2015

[26] Blockone ldquoConsensus protocolrdquo 2018 httpsdeveloperseosiowelcomev20protocolconsensus_protocol

[27] A Gervais H Ritzdorf G O Karame and S CapkunldquoTampering with the delivery of blocks and transactions inbitcoinrdquo in Proceedings Of the 22nd ACM SIGSAC ConferenceOn Computer and Communications Security pp 692ndash705Denver CO USA October 2015

[28] ldquoGithub Bit coinrdquo 2020 httpsgithubcombitcoinbitcoin[29] G Ethereum ldquoGo ethereumrdquo 2020 httpsgithubcom

ethereumgo-ethereum[30] Google ldquoGoogle cloudrdquo 2021 httpscloudgooglecom[31] ldquoHow to replay from a snapshotrdquo 2018 httpsdeveloperseos

iomanualseoslatestnodeosreplayshow-to-replay-from-a-snapshot

[32] C Decker and R Wattenhofer ldquoInformation propagation inthe bitcoin networkrdquo in Proceedings of the IEEE P2P 2013Proceedings pp 1ndash10 IEEE Trento Italy September 2013

[33] ldquoEthereum uncle raterdquo 2020 httpsychartscomindicatorsethereum_uncle_rate

[34] J A Donet C P Sola and J H Joancomartı ldquoe bitcoin p2pnetworkrdquo in Proceedings of the International Conference OnFinancial Cryptography and Data Security pp 87ndash102Springer Christ Church Barbados March 2014

[35] G S Davies ldquoBit-booster - offline commit graph drawingtoolrdquo 2016 httpbit-boostercomgraphhtml

[36] N T Courtois and L Bahack ldquoOn subversive miner strategiesand block withholding attack in bitcoin digital currencyrdquo2014 httpsarxivorgabs14021718

[37] I Eyal and E G Sirer ldquoMajority is not enough bitcoin miningis vulnerablerdquo in Proceedings of the International Conferenceon Financial Cryptography and Data Security pp 436ndash454Springer Christ Church Barbados March 2014

[38] Y Kwon D Kim Y Son E Vasserman and Y Kim ldquoBeselfish and avoid dilemmas fork after withholding (faw) at-tacks on bitcoinrdquo in Proceedings Of the 2017 ACM SIGSACConference On Computer and Communications Securitypp 195ndash209 Abu Dhabi UAE April 2017

[39] B Research ldquoDecentralisation governance and eos - a lostcaserdquo 2020 httpsresearchbinancecomenanalysiseos-governance

[40] B Wiki ldquoIrreversible transactions - finney attackrdquo 2012httpsenbitcoinitwikiIrreversible_Transactions∖Finney_attack

[41] J Poon and T Dryja ldquoe bitcoin lightning network scalableoff-chain instant paymentsrdquo 2016

[42] M Bartoletti and L Pompianu ldquoAn analysis of bitcoin op_return metadatardquo in Proceedings of the International Con-ference On Financial Cryptography and Data Securitypp 218ndash230 Springer Sliema Malta April 2017

[43] ldquoReplace by feerdquo 2018 httpsenbitcoinitwikiReplace_by_fee

[44] E Foundation ldquoNode and clientsrdquo 2020 httpsethereumorgendevelopersdocsnodes-and-clients

[45] H Heo and S Shin ldquoBehind block explorers public block-chain measurement and security implicationrdquo in Proceedingsof the 41th IEEE International Conference On DistributedComputing Systems IEEE Washington DC USA In pressWashington DC USA July 2021

[46] R Bowden H P Keeler A E Krzesinski and P G TaylorldquoBlock arrivals in the bitcoin blockchainrdquo 2018 httpsarxivorgabs180107447

[47] M E Crovella and A Bestavros ldquoExplaining world wide webtraffic self-similarityrdquo Technical Report Citeseer PrincetonNJ USA 1995

[48] H Zhang Y Shu and O Yang ldquoEstimation of hurst pa-rameter by variance-time plotsrdquo in Proceedings of the 1997IEEE Pacific Rim Conference on Communications Computersand Signal Processing PACRIM 10 Years Networkingthe Pacific Rim 1987-1997 IEEE Victoria BC CanadaAugust 1997

[49] A Feldmann ldquoCharacteristics of TCP connection arrivalsrdquo inSelf-Similar Network Traffic and Performance EvaluationK Park andWWillinger Eds pp 367ndash399Wiley HobokenNJ USA 2000

[50] RSK ldquoRSKrdquo 2021 httpswwwrskco[51] E Heilman A Kendler A Zohar and S Goldberg ldquoEclipse

attacks on bitcoinrsquos peer-to-peer networkrdquo in Proceedings of

Security and Communication Networks 17

the 24th USENIX Security Symposium pp 129ndash144 Wash-ington DC USA April 2015

[52] Y Marcus E Heilman and S Goldberg ldquoLow-resourceeclipse attacks on ethereumrsquos peer-to-peer networkrdquo IACRCryptology vol 2018 p 236 2018

[53] M Apostolaki A Zohar and L Vanbever ldquoHijacking bitcoinRouting attacks on cryptocurrenciesrdquo in Proceedings of the2017 IEEE Symposium On Security and Privacy (SP)pp 375ndash392 IEEE San Jose CA USA May 2017

[54] M Tran I Choi G J Moon A V Vu and M S Kang ldquoAstealthier partitioning attack against bitcoin peer-to-peernetworkrdquo in Proceedings of the IEEE Symposium On Securityand Privacy (SampP) San Francisco CA USA May 2020

[55] B I Proposal ldquoBip 0152rdquo 2016 httpsenbitcoinitwikiBIP_0152

[56] B Core ldquoBitcoin Core Version 01901 Release Noterdquo 2016httpsbitcoinorgenreleasev01901

[57] ldquoGeth v190rdquo 2019 httpsblogethereumorg20190710geth-v1-9-0

[58] ldquoProtocol documentationrdquo 2016 httpsenbitcoinitwikiProtocoltext_documentation

[59] C Feng and J Niu ldquoSelfish mining in ethereumrdquo in Pro-ceedings of the 2019 IEEE 39th International Conference OnDistributed Computing Systems (ICDCS) pp 1306ndash1316IEEE Dallas TX USA July 2019

[60] G O Karame E Androulaki and S Capkun ldquoDouble-spending fast payments in bitcoinrdquo in Proceedings of the 2012ACM Conference on Computer and Communications Securitypp 906ndash917 Raleigh NC USA October 2012

[61] P Das L Eckey T Frassetto et al ldquoFastkitten practical smartcontracts on bitcoinrdquo in Proceedimgs of the 28th USENIXSecurity Symposium (USENIX Security 19) pp 801ndash818Santa Clara CA USA August 2019

[62] S G Motlagh J Misic and V B Misic ldquoe impact of selfishmining on bitcoin network performancerdquo IEEE Transactionson Network Science and Engineering vol 8 no 1 pp 724ndash7352021

[63] A Muhle A Gruner T Gayvoronskaya and C Meinel ldquoAsurvey on essential components of a self-sovereign identityrdquoComputer Science Review vol 30 pp 80ndash86 2018

[64] M Toorani and C Gehrmann ldquoA decentralized dynamic pkibased on blockchainrdquo in Proceedings Of the 36th Annual ACMSymposium On Applied Computing pp 1646ndash1655 GwangjuKorea March 2021

[65] E foundation ldquoOptimistic-rollupsrdquo 2021 httpsdocsethhubioethereum-roadmaplayer-2-scalingoptimistictext_rollups

[66] ldquoZk-rollupsrdquo 2021 httpsdocsethhubioethereum-roadmaplayer-2-scalingzk-rollups

[67] E foundation ldquoEthereumwire protocolrdquo 2019 httpsgithubcomethereumdevp2pblobmastercapseth

[68] S K Kim Z Ma S Murali J Mason A Miller andM BaileyldquoMeasuring ethereum network peersrdquo in Proceedings of theInternet Measurement Conference 2018 pp 91ndash104 BostonMA USA October 2018

[69] Symmetricom ldquoDelivering sub-microsecond accurate time tolinux applications around the worldrdquo 2012 httpwwwchronoscoukfilespdfswpsWP_AccurateTimeForLinuxApplicationspdf

[70] Ycharts ldquoBlocktrail blockchain data query service (termi-nated)rdquo 2019 httpsblocktrailcom

18 Security and Communication Networks

of nonce (e transaction nonce should be equal to thenumber of transactions sent from the address) nonce is toohigh (983) or too low (002) Last but not least 727 ofstale transactions are not included in blocks because theaccount is not sufficiently funded (An Ethereum accountshould have balance ge value+ gastimes gas price to execute thetransaction [44]) An Ethereum account can be

insufficiently funded when executing a transaction for anumber of reasons [45]

423 EOS Transaction Discrepancy EOS exhibits unseenand stale transactions far different from those of Bitcoin orEthereum that is the PoW blockchains with transaction feeEOS software is not bundled with peer discovery rather thenode operator is required to look up for candidate BPrsquospeering services timely delivery of blockchain data andreliability of the node is dependent on the peering nodes ofchoice (Indeed we have experienced service disruption bydisconnecting from peers for unknown reasons)e notionof being conflict in two or more transactions that is themost frequent reason for transactions being stale for Bitcoinand Ethereum is not applicable to EOS (EOS adopts theaccount model without transaction ordering per accountthus there should be no conflict transaction outputs or thesame account nonce) On the other hand EOS requires

eosh

uobi

pool

-eos

infst

ones

eosfl

ytom

ars-

eosh

uobi

pool

zbeo

sbp1

1111

-atti

clab

eosb

attic

labe

osb-

big

one

hoo

com

-new

dex

bpw

hale

exco

m-z

beos

bp11

111

start

eosio

bp-w

hale

exco

meo

sdot

wik

ibp-

eosfl

ytom

ars

eosc

anno

nchn

-eos

dotw

ikib

pbi

gon

e-bi

tfine

xeos

1eo

sinfst

ones

-eos

iom

eeto

nehe

lloeo

scnb

p-ho

oco

meo

slaom

aoco

m-e

ossv

12eo

ssv

slow

mist

iobp

-sta

rteo

siobp

eoss

v12e

ossv

-hel

loeo

scnb

peo

sbei

jingb

p-eo

scan

nonc

hneo

siosg

1111

1-eo

slaom

aoco

meo

siom

eeto

ne-e

osio

sg11

111

bitfi

nexe

os1-

cert

ikeo

sorg

new

dex

bp-s

low

mist

iobp

coch

ainw

orld

-eos

asia

1111

1bi

tfine

xeos

1-co

chai

nwor

ldce

rtik

eoso

rg-c

ocha

inw

orld

eosa

sia11

111-

eosb

eijin

gbp

new

dex

bp-o

kcap

italb

p1eo

siom

eeto

ne-e

osla

omao

com

okca

pita

lbp1

-slo

wm

istio

bpco

chai

nwor

ld-e

osbe

ijing

bpne

wde

xbp

-sta

rteo

siobp

eosa

sia11

111-

eosc

anno

nchn

eosla

omao

com

-hel

loeo

scnb

pco

chai

nwor

ld-e

osca

nnon

chn

cert

ikeo

sorg

-eos

beiji

ngbp

eoss

v12e

ossv

-hoo

com

bitfi

nexe

os1-

eosa

sia11

111

eosin

fston

es-e

osla

omao

com

okca

pita

lbp1

-sta

rteo

siobp

BP switching (left)Cut-tail (right)

0

5000

10000

15000

20000

25000

BP sw

itchi

ng ev

ents

0

100

200

300

400

500

cu

t-tai

l eve

nts

Figure 10 EOS BP switching and cut-tail events

Table 6 Ethereum unseen transactions

From address Public name Transaction count Miner0xea67⋆ Ethermine 128145 (7242) Ethermine0x2a65⋆ DwarfPool 22955 (1297) DwarfPool0x8fd0⋆ Unknown 11346 (641) SparkPool0x829b⋆ F2Pool 4453 (251) F2Pool0x4c54⋆ HiveonPool 1135 (064) SparkPool0x99c8⋆ BeePool 468 (026) BeePool0xdba7⋆ Unknown 348 (020) UUPool0x464b⋆ FKPool 340 (019) FKPool0xf687⋆ Unknown 217 (012) AntPool0xa801⋆ Unknown 151 (009) AntPool0xbe7c⋆ Unknown 126 (007) AntPool0xb96f⋆ Unknown 101 (006) AntPool

Sum 169785 (9587)

Table 7 Bitcoin unseen transactions

Category Transactioncount

Zero-fee transaction 148 (5068)Zero-fee-transaction-dependent transaction 48 (1644)Multisig transaction input 43 (1473)Conflict with stale transaction 27 (925)OP_RETURN transaction output 26 (890)Sum 292 (10000)

10 Security and Communication Networks

contract users to stake tokens for CPU time that can bededucted by transaction executions A requested transactioncan be rejected thus being stale due to the lack of CPU timeor other resources similarly Replaying the entire statechanges of EOS to find out stale transactions due to lack ofresources is not possible unless all transaction and state logsof the entire BPs are available

On the other hand EOS transactions have two additionalattributes which are not available in the Bitcoin or Ethereumtransaction structures

(i) Reference block every EOS transaction refers to ablock by specifying the block number and hash notonly to prevent replay attacks but also to signal thenetwork that the userrsquos stake is on a specific fork

(ii) Expiration time EOS transactions have explicitexpiration times

If a transactionrsquos reference block is not part of the mainchain at the time of execution the transaction cannot beexecuted (and thus cannot be included in a block) We haveidentified that 18 of stale transactions apply to this case Tofurther identify unknown reasons we consider four timedevents that are relevant to transaction execution

(i) Last irreversible block arrival time arrival(blib) thearrival time of transactionrsquos reference block EOStransactions by default refer to the last irreversibleblock (LIB) [26]

(ii) Head block arrival time arrival(bhead) the scheduledtime of the head block when transaction is arrived

(iii) Transaction arrival time arrival(t) the arrival timeof transaction t

(iv) Expiration time exp(t) the expiration time oftransaction t

e three time differences that is Δexp Δincl and Δtrxare investigated to find characteristics of unseen (Tunseen)and stale (Tstale) transactions over the normal transactions(Tincluded) Figure 11 illustrates the relevant events and timedifferences of them Δexp measures the time difference be-tween the two scheduled (ie virtually timed) events Δincland Δtrx are defined by the arrival events to our monitornode Figure 12 shows the distributions of Δexp Δincl andΔtrx We find that unseen transactions have prolonged Δinclimplying that the delay of newly produced blocks can causenewly generated transactions not promptly delivered be-cause the sync manager is in the Head Catch-Up mode astransactions are only transferred in In-Sync mode by itsdesign [24] Stale transactions with relatively small Δtrx canbe attributable to problematic dApp implementations re-ferring to non-LIB blocks the chain instability caused byblockchain fork mostly due to the cut-tail behavior shown inSection 41 can cause transactions being rejected for im-mature block reference

However we do not find any reason attributable to thetransaction expiration Although the unseen transactionstend to have smallΔexp the expiration times are only as smallas 30 seconds (ie the default expiration time) Particularlyone or more EOS applications set the expiration time to180 seconds (other than the default 30 seconds) and morethan half of the stale transactions are invoked by thoseapplications

While transaction is the smallest unit of execution inBitcoin and Ethereum the unit of contract execution in EOSis action [24] A transaction consists of one or more actionsHowever the constituent actions in a single transactioncannot be separately advertised or executed accordingly weapply the identical transaction model to EOS without loss ofgenerality

5 Block and TransactionArrival Characteristics

51 Arrival Processes All three blockchains we study in thispaper are designed to publish capacity constrained blocks intargeted regular time intervals An incarnation of suchdesign is expected to exhibit a Poisson block arrival processWhile it is claimed that Bitcoin block arrivals do not entirelyexhibit a homogeneous Poisson process due to its difficultadjustment mechanism [46] transaction arrival processes ofblockchains are not studied in the literature to the best of ourknowledge A particularly meaningful step toward under-standing the arrival process of events generated by a complexsystem is examining if the arrival events are independent orexhibiting a correlated structure [47]

e variance-time log-log plots [48] of the block andtransaction arrival event time series are depicted in

Table 8 Stale transactions

Region Bitcoin Ethereum EOSAsia-East 41720 1170706 mdashAsia-South 41653 1194018 504277Europe-North 41693 1192435 470480Europe-West 41668 1123680 450140North America-Northeast 41703 1212210 588711US-Central 41683 1212389 505160US-East 41692 1186488 mdashUS-West 41672 1167627 480207Combined 42023 1351847 672999

Table 9 Identified reasons of stale transactions

Category Transaction count(a) Bitcoin

Conflict 39408 (9378)Stale transaction input 2307 (549)Conflict and stale transaction input 308 (073)Sum 42023 (10000)

(b) EthereumConflict 1208588 (8924)Nonce (skipped) 133161 (983)Nonce (used) 251 (002)Insufficient fund 9847 (727)Sum 1351847 (9982)

(c) EOSFork 12106 (180)Others 660893 (9820)Sum 672999 (10000)

Security and Communication Networks 11

Figure 13(a) As regards the block arrival processes Bitcoinblock arrivals exhibit a linear slope β minus23 e estimatedHurst parameter H 1 + β2 43 implies that the processis not a homogeneous Poisson process but LRD (Long-Range Dependent) contrary to what is expected for a regularinterval event generation [46] Ethereum block arrivalsapproximate the Bitcoinrsquos except for the high aggregationlevel due to high stale block rate EOS block arrivals incontrast follow the slope β minus1 in the low aggregation levelas the block generation is indeed regularly scheduled

Figure 14 shows the variance-time plot of Ethereum andEOS block arrival time series by taking all block arrivalevents (Bobs) and main chain block arrivals only (Bmain) Weconfirm that Ethereum block arrivals indeed exhibit astraight line (close to Bitcoin) if excluding stale blocksHowever EOS block arrivals do not exhibit a straight line

even if we exclude stale blocks due to delayed burst blockarrivals possibly due to cut-tail fork patterns (see Section41)

e transaction arrival processes of all three blockchainsappear to exhibit LRD with Hurst parameter Hgt 56 asβltminus13 To further identify analytical distributions that fitbest the empirical ones the coefficient of variation (σμ) andskewness (ie the standardized third moment) of transac-tion interarrival times are computed for every measurementdataset and compared to the relationships expected for theexponential lognormal Weibull and Gamma distributionsin Figure 13(b) We find that Bitcoin Ethereum and EOStransaction interarrival times are fit best Gamma Weibulland lognormal distribution respectively Individual datasetsare also examined for the fitness of the distribution to findthat the empirical distribution fits the analytical distribution

Virtualclock

Time

Transaction initiator

Time

Blockproducer

Time

Monitornode

Time

Scheduled block time of blib

Scheduled block time of bhead

Scheduled block time of bincl

1 Produce and propagate blib

2 Produce and propagate bhead

Expiration time of t

4 Produce and propagate bincl

Δexp

Δtrx

Δincl

3 Create and propagate t

Figure 11 EOS transaction analysis model

Tincluded

Tstale

Tunseen

0010203040506070809

1

Cum

ulat

ive f

requ

ency

100 200 300 400 5000Time difference (seconds)

(a)

Tincluded

Tunseen

01 1 10 100 1000001Time difference (seconds)

0010203040506070809

1

Cum

ulat

ive f

requ

ency

(b)

Tincluded

Tstale

0010203040506070809

1

Cum

ulat

ive f

requ

ency

01 1 10 100 1000001Time difference (seconds)

(c)

Figure 12 EOS transaction timing analysis (a) Δexp (b) Δincl (c) Δtrx

12 Security and Communication Networks

well except for the small interarrival time ranges For ex-ample Figure 15 depicts the CDF of Ethereum transactioninterarrival times observed in US-West Although the em-pirical distribution fits Weibull with parameters computedwith the maximum likelihood estimator [49] sample pointsunder several milliseconds appear to be unreliable (We areyet unaware of the reason However it is known that thetime source of commodity operating systems is not accurateand we need an external time source for accurate sub-millisecond timing measurement [50])

52AdvertisementRedundancy Bitcoin and Ethereum nodepieces of software are implemented to maintain a large

number of peer connections with multiple random remotenodes Bitcoin Core can connect up to 125 peers where 8 ofthem are outbound connections Go Ethereum maintains 50peer connections where 16 of them are outbound by default(see Table 1) On the other hand partitioning attacks aredeveloped to isolate a blockchain node from the others bytampering with all such peer connections Partitioning at-tacks usually exploit vulnerable peer management mecha-nisms of Bitcoin [51] and Ethereum [52] Such attacks arealso examined in the context of ISPrsquos BGP hijacking [53] anda stealthier variant relieving the attacker from the risk ofgetting exposed [54] e attacks often rely on imple-mentation vulnerabilities for efficient eclipsing of peerswhile known vulnerabilities are getting addressed for ex-ample the lack of parallel block download sessions causing

Slope = ndash1

Trx BitcoinTrx EthereumTrx EOS

Blk BitcoinBlk EthereumBlk EOS

ndash12

ndash10

ndash8

ndash6

ndash4

ndash2

0Lo

g no

rmal

ized

var

ianc

e

124 6 10 140 2 8Aggregation level

(a)

Lognormal

Weibull

Gamma

Exponential

BitcoinEthereumEOS

0

5

10

15

20

Stan

dard

ized

third

mom

ent

1 2 3 40Coefficient of variation

(b)

Figure 13 Transaction arrival characteristics (a) Variance-time plot of block and transaction arrivals (b) Cov versus skewness oftransaction interarrival times

Ethereum - Bobs

Ethereum - Bmain

EOS - Bobs

EOS - Bmain

ndash12

ndash10

ndash8

ndash6

ndash4

ndash2

0

Log

norm

aliz

ed v

aria

nce

2 4 6 8 10 12 140Aggregation level

Figure 14 Variance-time plot of block arrivals including staleblocks (Bobs) and excluding stale blocks (Bmain)

EmpiricalExponential μ = 0024

Lognormal μ = 00354 σ2 = 00486Pareto k = 0000212 a = 0231Weibull c = 0589 a = 00147

00001 0001 001 01 1000001Time (seconds)

0

02

04

06

08

1

Cum

ulat

ive f

requ

ency

Figure 15 Empirical and fitted analytical distributions of Ether-eum transaction interarrival times

Security and Communication Networks 13

temporary denial of blocks (reported in [27] and fixed byrecommending three concurrent download sessions in [55])let attackers successfully partition the node without eclipsingall peer connections [53] A simple countermeasure of in-creasing the number of peer connections on the other handis applied to the reference public blockchain implementa-tions [56 57] to inflate attack complexity

We investigate the degree of a peerrsquos advertisementredundancy on newly generated blocks and transactions toevaluate the efficacy of partitioning attacks and the coun-termeasure of increasing the number of peer connectionsFigure 16 shows how redundantly newly generated blockinformation is offered by peers Bitcoin nodes have main-tained sim43 peer connections that is 8 outbound and ad-ditional 35 inbound connections on average and Ethereumnodes record all 50 peer connections established during theentire observation period

For each newly generated block one-third of peersadvertised the block header to our Bitcoin node and morethan 90 of Ethereum peers signaled availability of theblocks In consequence successfully partitioning a noderequires compromise of peers proportional to the totalnumber of peer connections Increasing the number of peerconnections will burden the attacker linearly as expected

Figure 17 shows how redundantly the newly generatedtransaction information is offered by peers While one out ofthree Bitcoin peers also advertises new transactions viaINVENTORYmessage [58] half of the Ethereum peers havesent new transactions to our node in average Bitcoin andEthereum blocks are advertised with the block header(rather than the direct delivery of all block contents) Bitcointransactions are also advertised with INVENTORY messagebefore the whole contents are transferred HoweverEthereum transaction data that is the entire contents aredirectly sent by peers (Ethereum now has a pooled trans-action delivery model in its newer ETH64 protocol [30])We also find that there are cases with much less advertisedtransactions and have identified that they are indeed mostlystale ones stale transactions are mostly due to conflict (seeSection 42) and the nodes that already queued the conflicttransaction will not relay the stale one

6 Discussion

61 Implication on Mining Attacks Cryptocurrency mininghas been a popular subject in assessing the security ofBitcoin selfish mining [37] block withholding attack [36]and a mixed strategy [38] have been studied Although it isshown that selfish behavior in mining is always moreprofitable than being honest without need for a mutualagreement of not attacking each other [38] we find thatselfish mining is not the preferred strategy All selfish miningstrategies will result in blockchain forks but we observe avery low fork probability (ie 004) for Bitcoin On theother hand selfish mining on Ethereum has been studiedonly recently to unanimously claim that selfish mining isalso profitable for Ethereum miners however it is lessprofitable than Bitcoin due to its uncle reward system [59]Our result in Section 4 shows that a majority of Ethereum

miners choose to add to their own produced blocks over theearliest propagated blocks How does this affect the selfishmining strategy

e selfish mining strategy assumes a parameter c whichdefines the fraction of honest minersrsquo mines on the attackerrsquosfork branch (e parameter comes into play in case (f ) of[27]) If the attacking pool has a network-wise superiorposition in block propagation (ie cgt 05) the selfishmining strategy is profitable for pools with proportionalmining power αgt 25 [37] Absolute network inferiority(ie c 0 due to a defensive mining strategy such as the onepresented in Section 41) increases the required miningpower to 33 the 33 mining power appears to be sig-nificantly harder to achieve in the real world [20]

As for the FAW (Fork-After-Withholding) attackstrategy [38] the network capability parameter C defines theprobability that an attackerrsquos FPoW (Full Proof-of-Work)block (during infiltration mining) is selected as a main chainblock C affects both the attack reward and whether theminerrsquos dilemma holds or not in the mutual attacking gameAs an example case (Section 9 of [38]) of a two-pool gamebetween F2Pool and BitFury the absolute network inferi-ority drops C from 0914 to 03 to make it a dilemmatic gameagain Unfortunately minersrsquo own block preferences cannotbe directly transferred to a single parameter of c or C it callsfor a model change from previous mining studies

62 Conflict Transactions and Double-Spending AttacksDouble-spending attacks have been studied in the context ofBitcoin fast payments where zero or only one confirmation isrequired to complete an offline merchandise transaction[60] real-world cases where two conflict transactions dis-parately arrive at different measurement locations mayimply such attacks Table 10 shows the cases where twotransactions are in conflict (and thus only one of themis included in a block ie inputs(ti)cap inputs(ts)neemptyand existb isin Bmain ti isin transactions(b) (∄b isin Bmain ts isintransactions(b) is indisputable given a consistent transactionledger)) and two different subsets of the monitors havemempooled either one of them We also have identified 27unseen transactions implying possible one-confirmationattack variant requiring the private mining (ie not ad-vertising the double-spending transaction to the network) in

5 10 15 20 25 30 35 40 45 500 of peers

0

005

01

015

02

025

Freq

uenc

y

BitcoinEthereum

Figure 16 Peer redundancy of block advertisement

14 Security and Communication Networks

Section 42 As for the countermeasure of such attacks bydeploying monitors [60] deployment of 8 monitors in thenetwork to detect the attacks would fail at most 27 out of 95times (sim30) assuming that those 27 unseen transactionswe have identified are initially advertised to the network

63 Potential Impact on Blockchain ApplicationsEthereum and EOS are the most widely used smart contractplatforms fostering various decentralized applications Bit-coin which lacks the capability of executing complex smartcontract codes is also recently utilized to execute smartcontracts for decentralized applications [50 61] Eventhough our work focuses on the fundamental blockchainmechanisms in terms of transactionblock production andpropagation the impact of our findings on decentralizedapplications can be foresighted

According to our blockchain fork results (Section 41)the lack of selfish mining in the real world was speculated bya very low stale block rate of Bitcoin network and prevalenceof nonearliest block endorsement by Ethereum miners Asprofitability of selfish mining encourages miners to behavein a way of producing more blockchain forks the perfor-mance degradation is proportionate to the number of minerswho adopt the selfish mining strategy the key performancemetrics affecting the blockchain application performance

such as node response time or block delivery time are shownto be noticeably degraded due to the selfish mining [62] Forexample decentralized identities issued or revoked on suchblockchains [63 64] cannot be responsively finalized due toinflated blockchain forks Our results show that the selfishmining is not prevalent in the real world thus the appli-cation performance impact is overrated even though it istheoretically shown that miners have every reason to beselfish [38] As for EOS we reported cases where a sequenceof (up to 12) blocks being stale are often observed in suc-cessive mining of two BPs however the rate is too low (ie004) to impact the performance of applications (Section32)

Transaction arrival processes being LRD (Section 51)pose a technical challenge in provisioning transactionprocessing scalability especially for Layer-2 blockchain ap-plication solutions [65 66] For example Layer-2 rollupsolutions require transaction relays which aggregate indi-vidual user transactions of a given blockchain applicationdeployed in the network often without a priori knowledge ofnetwork load One way of solving the problem is a properprioritization of transactions based on the applicationcontext

Lastly blockchain network partitioning can be thebiggest concern for blockchain service providers We ob-served that the increased numbers of peer connections inblockchain reference implementations effectively provide ahigher degree of information redundancy (Section 52)However increased number of peer connections can beexploitable for an attacker who has a denial-of-service attackvector or an invalid transaction initiated by a simple ap-plication bug can flood the network [45]

64 Limitation Our measurement study has several limi-tations First of all our results may only capture only a fewmonths of blockchain network operations In the meantimethe permissionless blockchain pieces of software are in activedevelopment for example Ethereum now utilizes the pooledtransaction delivery [67] instead of unsolicited transactiondelivery which was the only mode at the time of our

Table 10 Bitcoin disparately mempooled transactions

monitors mempooledti

monitors mempooledts

Transactioncount

7 1 26 (3824)6 2 14 (2059)5 3 10 (1471)4 4 5 (735)3 5 5 (735)2 6 3 (441)1 7 3 (441)5 1 1 (147)6 1 1 (147)

Sum 68 (10000)

Tincluded

Tstale

5 10 15 20 25 30 35 40 45 500 of peers

0

005

01

015

02

025

03Fr

eque

ncy

(a)

Tincluded

Tstale

0002004006008

01012014016

Freq

uenc

y

4030 500 10 20 of peers

(b)

Figure 17 Peer redundancy of transaction advertisement (a) Bitcoin (b) Ethereum

Security and Communication Networks 15

measurement Both cryptocurrency market values andblockchain network utilizations are rapidly increasing andthus miners are getting more motivated to optimize theirperformance for example Bitcoin fork probability has be-come far smaller than what is reported previously (seeSection 41)

Second the blockchain state information is not collected inour measurement Our analysis is performed based on onlyavailable information stored in block and transaction logs Wehave utilized an Ethereum archive node [44] to query historicalstate information (eg account balance or account nonce) inSection 42 However such proactive state replication is farmore complicated with EOS unless the full node is configuredto operate as a producing node and logging the state infor-mation thus EOS stale transactions could not be fully un-derstood without the missing EOS network state information

7 Related Work

71 Blockchain Data Analysis Historical transaction data ofBitcoin have often been studied for economic aspects such ascryptocurrency abuse [17] anti-money-laundering [18] andmonetary flow of businesses [19] However historicalblockchain data usually available from block explorer ser-vices are not sufficient for our research purpose

72 Blockchain Measurement Researchers have performedblockchain measurement studies to assess the degree ofdecentralization [20] to investigate demographic informa-tion of network nodes [34 68] to study mining pool be-havior [22] and to evaluate security of PoW blockchains [21]against known attacks such as double-spending attack [60]and selfish mining [37] Our work expands the under-standing of previous security evaluations with the keyfindings acquired from our large-scale transaction and blockmeasurement

73 Blockchain Attacks Partitioning attacks usually exploitvulnerable peer management mechanisms of Bitcoin [51]and Ethereum [52] Such attacks are also examined in thecontext of ISPrsquos BGP hijacking [53] and a stealthier variantrelieving the attacker from the risk of getting exposed [54]Cryptocurrency mining has been a popular subject inassessing the security of Bitcoin selfish mining [37] blockwithholding attack [36] and a mixed strategy [38] have beenstudied Double-spending attacks have been studied in thecontext of Bitcoin fast payments [60]

74 Block Explorer Services We have surveyed the popularblock explorer services of Bitcoin [5 10 12] Ethereum[10 13 16] and EOS [11 14 15] to see the availability ofinformation beyond what is recorded in the main chainblock data we have utilized in our study namely

(i) Stale blockstransactions no Bitcoin and EOS blockexplorers provide stale block information (A relatedstudy [36] has utilized a Bitcoin block explorer service[68] to retrieve stale blocks However the service has

been terminated in March 2019) All Ethereum blockexplorers provide only reported stale blocks (ie uncleblocks [23]) (Ethereum provides incentives for unclestale blocks [44] so that miners include them in theirmined blocks for profit)No block explorers provide stale transaction infor-mation unless one is currently pooled

(ii) Blocktransaction arrival times all block explorersprovide block timestamps that are recorded in theblock headers not the actual times of arrival Ourblockchain fork and gap analysis require measuredblock arrival times at multiple locations All blockexplorers show transaction timestamps identical to theblock timestamp to which the transactions belong(Recent Bitcoin transactions have different timestampsthan the block timestamps in [4] while the timestampsare only at a granularity of one minute) [69 70]

8 Conclusion

We have measured transaction and block arrival events ofthe three permissionless blockchains We have devised anoble analysis model and analyzed completeness of ourblock and transaction logs Finally we have studied thediscrepancy in measured events and arrival characteristics toshare our key findings including a false universal assumptionof previous mining-related studies

Data Availability

e measurement data used to support the findings of thisstudy have not been made available because they containprivate information that can be used to identify individualblockchain nodes

Disclosure

is is an extended and revised version of a conference paperpresented in IEEE ICDCS 2021 [41]

Conflicts of Interest

e authors declare that they have no conflicts of interest

Acknowledgments

e authors would like to thank Seungwon Woo DaegeunYoon and Changhyun Lee for helping them with themeasurement instrumentation is work was supported byElectronics and Telecommunications Research Institute(ETRI) grant funded by the Korean Government (21ZR1300Research on Intelligent Cyber Security and Trust Infra)

References

[1] S Nakamoto ldquoBitcoin a peer-to-peer electronic cash systemrdquo2019

[2] V Buterin ldquoEthereum white paperrdquo 2013 httpsethereumorgenwhitepaper

[3] Monero ldquoMonerordquo 2020 httpswebgetmoneroorg

16 Security and Communication Networks

[4] bitcoincashorg httpswwwbitcoincashorg[5] Blockchaincom httpswwwblockchaincom[6] Ripple ldquoXRP e best digital asset for global paymentsrdquo

2020 httpsripplecomxrp[7] I Foundation ldquoIotardquo 2021 httpswwwiotaorg[8] ldquoEosiordquo 2020 httpseosio[9] S Orsquoneal ldquoEos proves yet again that decentralization is not its

priorityrdquo 2018 httpscointelegraphcomnewseos-proves-yet-again-that-decentralization-is-not-its-priority

[10] Blockchair httpsblockchaircom[11] Bloksio httpsbloksio[12] BTCcom ldquoBitcoin block explorerrdquo 2021 httpsbtccom[13] Ethereum block explorer httpsethbtccom[14] eosflareio Eos block explorer httpseosflareio[15] EOSPark ldquoEos block explorerrdquo 2021 httpseosparkcom[16] Etherscan Ethereum explorer httpsetherscanio[17] S Lee C Yoon and H Kang ldquoCybercriminal minds An

investigative study of cryptocurrency abuses in the dark webrdquoin Proceedings of the Network and Distributed System SecuritySymposium pp 1ndash15 Internet Society San Diego CA USAFebruary 2019

[18] MMoser R Bohme and D Breuker ldquoAn inquiry into moneylaundering tools in the bitcoin ecosystemrdquo in Proceedings ofthe 2013 APWG eCrime Researchers summit pp 1ndash14 IEEESan Francisco CA USA September 2013

[19] M Lischke and B Fabian ldquoAnalyzing the bitcoin network thefirst four yearsrdquo Future Internet vol 8 no 1 2016

[20] A E Gencer S Basu I Eyal R V Renesse and E G SirerldquoDecentralization in bitcoin and ethereum networksrdquo inProceedings of the International Conference On FinancialCryptography and Data Security pp 439ndash457 SpringerNieuwport Curaccedilao February 2018

[21] A Gervais G O Karame KWust V Glykantzis H Ritzdorfand S Capkun ldquoOn the security and performance of proof ofwork blockchainsrdquo in Proceedings Of the 2016 ACM SIGSACConference on Computer and Communications Securitypp 3ndash16 Vienna Austria October 2016

[22] C Wang X Chu and Q Yang ldquoMeasurement and analysis ofthe bitcoin networks a view from mining poolsrdquo 2019httpsarxivorgabs190207549

[23] G Wood ldquoEthereum A secure decentralised generalisedtransaction ledgerrdquo Ethereum Project Yellow Paper vol 1512014

[24] ldquoTransactions protocol eosio developer docsrdquo 2018 httpsdeveloperseosiowelcomev20protocoltransactions_protocol

[25] Y Sompolinsky and A Zohar ldquoSecure high-rate transactionprocessing in bitcoinrdquo in Proceedings of the InternationalConference On Financial Cryptography and Data Securitypp 507ndash527 Springer San Juan PR USA January 2015

[26] Blockone ldquoConsensus protocolrdquo 2018 httpsdeveloperseosiowelcomev20protocolconsensus_protocol

[27] A Gervais H Ritzdorf G O Karame and S CapkunldquoTampering with the delivery of blocks and transactions inbitcoinrdquo in Proceedings Of the 22nd ACM SIGSAC ConferenceOn Computer and Communications Security pp 692ndash705Denver CO USA October 2015

[28] ldquoGithub Bit coinrdquo 2020 httpsgithubcombitcoinbitcoin[29] G Ethereum ldquoGo ethereumrdquo 2020 httpsgithubcom

ethereumgo-ethereum[30] Google ldquoGoogle cloudrdquo 2021 httpscloudgooglecom[31] ldquoHow to replay from a snapshotrdquo 2018 httpsdeveloperseos

iomanualseoslatestnodeosreplayshow-to-replay-from-a-snapshot

[32] C Decker and R Wattenhofer ldquoInformation propagation inthe bitcoin networkrdquo in Proceedings of the IEEE P2P 2013Proceedings pp 1ndash10 IEEE Trento Italy September 2013

[33] ldquoEthereum uncle raterdquo 2020 httpsychartscomindicatorsethereum_uncle_rate

[34] J A Donet C P Sola and J H Joancomartı ldquoe bitcoin p2pnetworkrdquo in Proceedings of the International Conference OnFinancial Cryptography and Data Security pp 87ndash102Springer Christ Church Barbados March 2014

[35] G S Davies ldquoBit-booster - offline commit graph drawingtoolrdquo 2016 httpbit-boostercomgraphhtml

[36] N T Courtois and L Bahack ldquoOn subversive miner strategiesand block withholding attack in bitcoin digital currencyrdquo2014 httpsarxivorgabs14021718

[37] I Eyal and E G Sirer ldquoMajority is not enough bitcoin miningis vulnerablerdquo in Proceedings of the International Conferenceon Financial Cryptography and Data Security pp 436ndash454Springer Christ Church Barbados March 2014

[38] Y Kwon D Kim Y Son E Vasserman and Y Kim ldquoBeselfish and avoid dilemmas fork after withholding (faw) at-tacks on bitcoinrdquo in Proceedings Of the 2017 ACM SIGSACConference On Computer and Communications Securitypp 195ndash209 Abu Dhabi UAE April 2017

[39] B Research ldquoDecentralisation governance and eos - a lostcaserdquo 2020 httpsresearchbinancecomenanalysiseos-governance

[40] B Wiki ldquoIrreversible transactions - finney attackrdquo 2012httpsenbitcoinitwikiIrreversible_Transactions∖Finney_attack

[41] J Poon and T Dryja ldquoe bitcoin lightning network scalableoff-chain instant paymentsrdquo 2016

[42] M Bartoletti and L Pompianu ldquoAn analysis of bitcoin op_return metadatardquo in Proceedings of the International Con-ference On Financial Cryptography and Data Securitypp 218ndash230 Springer Sliema Malta April 2017

[43] ldquoReplace by feerdquo 2018 httpsenbitcoinitwikiReplace_by_fee

[44] E Foundation ldquoNode and clientsrdquo 2020 httpsethereumorgendevelopersdocsnodes-and-clients

[45] H Heo and S Shin ldquoBehind block explorers public block-chain measurement and security implicationrdquo in Proceedingsof the 41th IEEE International Conference On DistributedComputing Systems IEEE Washington DC USA In pressWashington DC USA July 2021

[46] R Bowden H P Keeler A E Krzesinski and P G TaylorldquoBlock arrivals in the bitcoin blockchainrdquo 2018 httpsarxivorgabs180107447

[47] M E Crovella and A Bestavros ldquoExplaining world wide webtraffic self-similarityrdquo Technical Report Citeseer PrincetonNJ USA 1995

[48] H Zhang Y Shu and O Yang ldquoEstimation of hurst pa-rameter by variance-time plotsrdquo in Proceedings of the 1997IEEE Pacific Rim Conference on Communications Computersand Signal Processing PACRIM 10 Years Networkingthe Pacific Rim 1987-1997 IEEE Victoria BC CanadaAugust 1997

[49] A Feldmann ldquoCharacteristics of TCP connection arrivalsrdquo inSelf-Similar Network Traffic and Performance EvaluationK Park andWWillinger Eds pp 367ndash399Wiley HobokenNJ USA 2000

[50] RSK ldquoRSKrdquo 2021 httpswwwrskco[51] E Heilman A Kendler A Zohar and S Goldberg ldquoEclipse

attacks on bitcoinrsquos peer-to-peer networkrdquo in Proceedings of

Security and Communication Networks 17

the 24th USENIX Security Symposium pp 129ndash144 Wash-ington DC USA April 2015

[52] Y Marcus E Heilman and S Goldberg ldquoLow-resourceeclipse attacks on ethereumrsquos peer-to-peer networkrdquo IACRCryptology vol 2018 p 236 2018

[53] M Apostolaki A Zohar and L Vanbever ldquoHijacking bitcoinRouting attacks on cryptocurrenciesrdquo in Proceedings of the2017 IEEE Symposium On Security and Privacy (SP)pp 375ndash392 IEEE San Jose CA USA May 2017

[54] M Tran I Choi G J Moon A V Vu and M S Kang ldquoAstealthier partitioning attack against bitcoin peer-to-peernetworkrdquo in Proceedings of the IEEE Symposium On Securityand Privacy (SampP) San Francisco CA USA May 2020

[55] B I Proposal ldquoBip 0152rdquo 2016 httpsenbitcoinitwikiBIP_0152

[56] B Core ldquoBitcoin Core Version 01901 Release Noterdquo 2016httpsbitcoinorgenreleasev01901

[57] ldquoGeth v190rdquo 2019 httpsblogethereumorg20190710geth-v1-9-0

[58] ldquoProtocol documentationrdquo 2016 httpsenbitcoinitwikiProtocoltext_documentation

[59] C Feng and J Niu ldquoSelfish mining in ethereumrdquo in Pro-ceedings of the 2019 IEEE 39th International Conference OnDistributed Computing Systems (ICDCS) pp 1306ndash1316IEEE Dallas TX USA July 2019

[60] G O Karame E Androulaki and S Capkun ldquoDouble-spending fast payments in bitcoinrdquo in Proceedings of the 2012ACM Conference on Computer and Communications Securitypp 906ndash917 Raleigh NC USA October 2012

[61] P Das L Eckey T Frassetto et al ldquoFastkitten practical smartcontracts on bitcoinrdquo in Proceedimgs of the 28th USENIXSecurity Symposium (USENIX Security 19) pp 801ndash818Santa Clara CA USA August 2019

[62] S G Motlagh J Misic and V B Misic ldquoe impact of selfishmining on bitcoin network performancerdquo IEEE Transactionson Network Science and Engineering vol 8 no 1 pp 724ndash7352021

[63] A Muhle A Gruner T Gayvoronskaya and C Meinel ldquoAsurvey on essential components of a self-sovereign identityrdquoComputer Science Review vol 30 pp 80ndash86 2018

[64] M Toorani and C Gehrmann ldquoA decentralized dynamic pkibased on blockchainrdquo in Proceedings Of the 36th Annual ACMSymposium On Applied Computing pp 1646ndash1655 GwangjuKorea March 2021

[65] E foundation ldquoOptimistic-rollupsrdquo 2021 httpsdocsethhubioethereum-roadmaplayer-2-scalingoptimistictext_rollups

[66] ldquoZk-rollupsrdquo 2021 httpsdocsethhubioethereum-roadmaplayer-2-scalingzk-rollups

[67] E foundation ldquoEthereumwire protocolrdquo 2019 httpsgithubcomethereumdevp2pblobmastercapseth

[68] S K Kim Z Ma S Murali J Mason A Miller andM BaileyldquoMeasuring ethereum network peersrdquo in Proceedings of theInternet Measurement Conference 2018 pp 91ndash104 BostonMA USA October 2018

[69] Symmetricom ldquoDelivering sub-microsecond accurate time tolinux applications around the worldrdquo 2012 httpwwwchronoscoukfilespdfswpsWP_AccurateTimeForLinuxApplicationspdf

[70] Ycharts ldquoBlocktrail blockchain data query service (termi-nated)rdquo 2019 httpsblocktrailcom

18 Security and Communication Networks

contract users to stake tokens for CPU time that can bededucted by transaction executions A requested transactioncan be rejected thus being stale due to the lack of CPU timeor other resources similarly Replaying the entire statechanges of EOS to find out stale transactions due to lack ofresources is not possible unless all transaction and state logsof the entire BPs are available

On the other hand EOS transactions have two additionalattributes which are not available in the Bitcoin or Ethereumtransaction structures

(i) Reference block every EOS transaction refers to ablock by specifying the block number and hash notonly to prevent replay attacks but also to signal thenetwork that the userrsquos stake is on a specific fork

(ii) Expiration time EOS transactions have explicitexpiration times

If a transactionrsquos reference block is not part of the mainchain at the time of execution the transaction cannot beexecuted (and thus cannot be included in a block) We haveidentified that 18 of stale transactions apply to this case Tofurther identify unknown reasons we consider four timedevents that are relevant to transaction execution

(i) Last irreversible block arrival time arrival(blib) thearrival time of transactionrsquos reference block EOStransactions by default refer to the last irreversibleblock (LIB) [26]

(ii) Head block arrival time arrival(bhead) the scheduledtime of the head block when transaction is arrived

(iii) Transaction arrival time arrival(t) the arrival timeof transaction t

(iv) Expiration time exp(t) the expiration time oftransaction t

e three time differences that is Δexp Δincl and Δtrxare investigated to find characteristics of unseen (Tunseen)and stale (Tstale) transactions over the normal transactions(Tincluded) Figure 11 illustrates the relevant events and timedifferences of them Δexp measures the time difference be-tween the two scheduled (ie virtually timed) events Δincland Δtrx are defined by the arrival events to our monitornode Figure 12 shows the distributions of Δexp Δincl andΔtrx We find that unseen transactions have prolonged Δinclimplying that the delay of newly produced blocks can causenewly generated transactions not promptly delivered be-cause the sync manager is in the Head Catch-Up mode astransactions are only transferred in In-Sync mode by itsdesign [24] Stale transactions with relatively small Δtrx canbe attributable to problematic dApp implementations re-ferring to non-LIB blocks the chain instability caused byblockchain fork mostly due to the cut-tail behavior shown inSection 41 can cause transactions being rejected for im-mature block reference

However we do not find any reason attributable to thetransaction expiration Although the unseen transactionstend to have smallΔexp the expiration times are only as smallas 30 seconds (ie the default expiration time) Particularlyone or more EOS applications set the expiration time to180 seconds (other than the default 30 seconds) and morethan half of the stale transactions are invoked by thoseapplications

While transaction is the smallest unit of execution inBitcoin and Ethereum the unit of contract execution in EOSis action [24] A transaction consists of one or more actionsHowever the constituent actions in a single transactioncannot be separately advertised or executed accordingly weapply the identical transaction model to EOS without loss ofgenerality

5 Block and TransactionArrival Characteristics

51 Arrival Processes All three blockchains we study in thispaper are designed to publish capacity constrained blocks intargeted regular time intervals An incarnation of suchdesign is expected to exhibit a Poisson block arrival processWhile it is claimed that Bitcoin block arrivals do not entirelyexhibit a homogeneous Poisson process due to its difficultadjustment mechanism [46] transaction arrival processes ofblockchains are not studied in the literature to the best of ourknowledge A particularly meaningful step toward under-standing the arrival process of events generated by a complexsystem is examining if the arrival events are independent orexhibiting a correlated structure [47]

e variance-time log-log plots [48] of the block andtransaction arrival event time series are depicted in

Table 8 Stale transactions

Region Bitcoin Ethereum EOSAsia-East 41720 1170706 mdashAsia-South 41653 1194018 504277Europe-North 41693 1192435 470480Europe-West 41668 1123680 450140North America-Northeast 41703 1212210 588711US-Central 41683 1212389 505160US-East 41692 1186488 mdashUS-West 41672 1167627 480207Combined 42023 1351847 672999

Table 9 Identified reasons of stale transactions

Category Transaction count(a) Bitcoin

Conflict 39408 (9378)Stale transaction input 2307 (549)Conflict and stale transaction input 308 (073)Sum 42023 (10000)

(b) EthereumConflict 1208588 (8924)Nonce (skipped) 133161 (983)Nonce (used) 251 (002)Insufficient fund 9847 (727)Sum 1351847 (9982)

(c) EOSFork 12106 (180)Others 660893 (9820)Sum 672999 (10000)

Security and Communication Networks 11

Figure 13(a) As regards the block arrival processes Bitcoinblock arrivals exhibit a linear slope β minus23 e estimatedHurst parameter H 1 + β2 43 implies that the processis not a homogeneous Poisson process but LRD (Long-Range Dependent) contrary to what is expected for a regularinterval event generation [46] Ethereum block arrivalsapproximate the Bitcoinrsquos except for the high aggregationlevel due to high stale block rate EOS block arrivals incontrast follow the slope β minus1 in the low aggregation levelas the block generation is indeed regularly scheduled

Figure 14 shows the variance-time plot of Ethereum andEOS block arrival time series by taking all block arrivalevents (Bobs) and main chain block arrivals only (Bmain) Weconfirm that Ethereum block arrivals indeed exhibit astraight line (close to Bitcoin) if excluding stale blocksHowever EOS block arrivals do not exhibit a straight line

even if we exclude stale blocks due to delayed burst blockarrivals possibly due to cut-tail fork patterns (see Section41)

e transaction arrival processes of all three blockchainsappear to exhibit LRD with Hurst parameter Hgt 56 asβltminus13 To further identify analytical distributions that fitbest the empirical ones the coefficient of variation (σμ) andskewness (ie the standardized third moment) of transac-tion interarrival times are computed for every measurementdataset and compared to the relationships expected for theexponential lognormal Weibull and Gamma distributionsin Figure 13(b) We find that Bitcoin Ethereum and EOStransaction interarrival times are fit best Gamma Weibulland lognormal distribution respectively Individual datasetsare also examined for the fitness of the distribution to findthat the empirical distribution fits the analytical distribution

Virtualclock

Time

Transaction initiator

Time

Blockproducer

Time

Monitornode

Time

Scheduled block time of blib

Scheduled block time of bhead

Scheduled block time of bincl

1 Produce and propagate blib

2 Produce and propagate bhead

Expiration time of t

4 Produce and propagate bincl

Δexp

Δtrx

Δincl

3 Create and propagate t

Figure 11 EOS transaction analysis model

Tincluded

Tstale

Tunseen

0010203040506070809

1

Cum

ulat

ive f

requ

ency

100 200 300 400 5000Time difference (seconds)

(a)

Tincluded

Tunseen

01 1 10 100 1000001Time difference (seconds)

0010203040506070809

1

Cum

ulat

ive f

requ

ency

(b)

Tincluded

Tstale

0010203040506070809

1

Cum

ulat

ive f

requ

ency

01 1 10 100 1000001Time difference (seconds)

(c)

Figure 12 EOS transaction timing analysis (a) Δexp (b) Δincl (c) Δtrx

12 Security and Communication Networks

well except for the small interarrival time ranges For ex-ample Figure 15 depicts the CDF of Ethereum transactioninterarrival times observed in US-West Although the em-pirical distribution fits Weibull with parameters computedwith the maximum likelihood estimator [49] sample pointsunder several milliseconds appear to be unreliable (We areyet unaware of the reason However it is known that thetime source of commodity operating systems is not accurateand we need an external time source for accurate sub-millisecond timing measurement [50])

52AdvertisementRedundancy Bitcoin and Ethereum nodepieces of software are implemented to maintain a large

number of peer connections with multiple random remotenodes Bitcoin Core can connect up to 125 peers where 8 ofthem are outbound connections Go Ethereum maintains 50peer connections where 16 of them are outbound by default(see Table 1) On the other hand partitioning attacks aredeveloped to isolate a blockchain node from the others bytampering with all such peer connections Partitioning at-tacks usually exploit vulnerable peer management mecha-nisms of Bitcoin [51] and Ethereum [52] Such attacks arealso examined in the context of ISPrsquos BGP hijacking [53] anda stealthier variant relieving the attacker from the risk ofgetting exposed [54] e attacks often rely on imple-mentation vulnerabilities for efficient eclipsing of peerswhile known vulnerabilities are getting addressed for ex-ample the lack of parallel block download sessions causing

Slope = ndash1

Trx BitcoinTrx EthereumTrx EOS

Blk BitcoinBlk EthereumBlk EOS

ndash12

ndash10

ndash8

ndash6

ndash4

ndash2

0Lo

g no

rmal

ized

var

ianc

e

124 6 10 140 2 8Aggregation level

(a)

Lognormal

Weibull

Gamma

Exponential

BitcoinEthereumEOS

0

5

10

15

20

Stan

dard

ized

third

mom

ent

1 2 3 40Coefficient of variation

(b)

Figure 13 Transaction arrival characteristics (a) Variance-time plot of block and transaction arrivals (b) Cov versus skewness oftransaction interarrival times

Ethereum - Bobs

Ethereum - Bmain

EOS - Bobs

EOS - Bmain

ndash12

ndash10

ndash8

ndash6

ndash4

ndash2

0

Log

norm

aliz

ed v

aria

nce

2 4 6 8 10 12 140Aggregation level

Figure 14 Variance-time plot of block arrivals including staleblocks (Bobs) and excluding stale blocks (Bmain)

EmpiricalExponential μ = 0024

Lognormal μ = 00354 σ2 = 00486Pareto k = 0000212 a = 0231Weibull c = 0589 a = 00147

00001 0001 001 01 1000001Time (seconds)

0

02

04

06

08

1

Cum

ulat

ive f

requ

ency

Figure 15 Empirical and fitted analytical distributions of Ether-eum transaction interarrival times

Security and Communication Networks 13

temporary denial of blocks (reported in [27] and fixed byrecommending three concurrent download sessions in [55])let attackers successfully partition the node without eclipsingall peer connections [53] A simple countermeasure of in-creasing the number of peer connections on the other handis applied to the reference public blockchain implementa-tions [56 57] to inflate attack complexity

We investigate the degree of a peerrsquos advertisementredundancy on newly generated blocks and transactions toevaluate the efficacy of partitioning attacks and the coun-termeasure of increasing the number of peer connectionsFigure 16 shows how redundantly newly generated blockinformation is offered by peers Bitcoin nodes have main-tained sim43 peer connections that is 8 outbound and ad-ditional 35 inbound connections on average and Ethereumnodes record all 50 peer connections established during theentire observation period

For each newly generated block one-third of peersadvertised the block header to our Bitcoin node and morethan 90 of Ethereum peers signaled availability of theblocks In consequence successfully partitioning a noderequires compromise of peers proportional to the totalnumber of peer connections Increasing the number of peerconnections will burden the attacker linearly as expected

Figure 17 shows how redundantly the newly generatedtransaction information is offered by peers While one out ofthree Bitcoin peers also advertises new transactions viaINVENTORYmessage [58] half of the Ethereum peers havesent new transactions to our node in average Bitcoin andEthereum blocks are advertised with the block header(rather than the direct delivery of all block contents) Bitcointransactions are also advertised with INVENTORY messagebefore the whole contents are transferred HoweverEthereum transaction data that is the entire contents aredirectly sent by peers (Ethereum now has a pooled trans-action delivery model in its newer ETH64 protocol [30])We also find that there are cases with much less advertisedtransactions and have identified that they are indeed mostlystale ones stale transactions are mostly due to conflict (seeSection 42) and the nodes that already queued the conflicttransaction will not relay the stale one

6 Discussion

61 Implication on Mining Attacks Cryptocurrency mininghas been a popular subject in assessing the security ofBitcoin selfish mining [37] block withholding attack [36]and a mixed strategy [38] have been studied Although it isshown that selfish behavior in mining is always moreprofitable than being honest without need for a mutualagreement of not attacking each other [38] we find thatselfish mining is not the preferred strategy All selfish miningstrategies will result in blockchain forks but we observe avery low fork probability (ie 004) for Bitcoin On theother hand selfish mining on Ethereum has been studiedonly recently to unanimously claim that selfish mining isalso profitable for Ethereum miners however it is lessprofitable than Bitcoin due to its uncle reward system [59]Our result in Section 4 shows that a majority of Ethereum

miners choose to add to their own produced blocks over theearliest propagated blocks How does this affect the selfishmining strategy

e selfish mining strategy assumes a parameter c whichdefines the fraction of honest minersrsquo mines on the attackerrsquosfork branch (e parameter comes into play in case (f ) of[27]) If the attacking pool has a network-wise superiorposition in block propagation (ie cgt 05) the selfishmining strategy is profitable for pools with proportionalmining power αgt 25 [37] Absolute network inferiority(ie c 0 due to a defensive mining strategy such as the onepresented in Section 41) increases the required miningpower to 33 the 33 mining power appears to be sig-nificantly harder to achieve in the real world [20]

As for the FAW (Fork-After-Withholding) attackstrategy [38] the network capability parameter C defines theprobability that an attackerrsquos FPoW (Full Proof-of-Work)block (during infiltration mining) is selected as a main chainblock C affects both the attack reward and whether theminerrsquos dilemma holds or not in the mutual attacking gameAs an example case (Section 9 of [38]) of a two-pool gamebetween F2Pool and BitFury the absolute network inferi-ority drops C from 0914 to 03 to make it a dilemmatic gameagain Unfortunately minersrsquo own block preferences cannotbe directly transferred to a single parameter of c or C it callsfor a model change from previous mining studies

62 Conflict Transactions and Double-Spending AttacksDouble-spending attacks have been studied in the context ofBitcoin fast payments where zero or only one confirmation isrequired to complete an offline merchandise transaction[60] real-world cases where two conflict transactions dis-parately arrive at different measurement locations mayimply such attacks Table 10 shows the cases where twotransactions are in conflict (and thus only one of themis included in a block ie inputs(ti)cap inputs(ts)neemptyand existb isin Bmain ti isin transactions(b) (∄b isin Bmain ts isintransactions(b) is indisputable given a consistent transactionledger)) and two different subsets of the monitors havemempooled either one of them We also have identified 27unseen transactions implying possible one-confirmationattack variant requiring the private mining (ie not ad-vertising the double-spending transaction to the network) in

5 10 15 20 25 30 35 40 45 500 of peers

0

005

01

015

02

025

Freq

uenc

y

BitcoinEthereum

Figure 16 Peer redundancy of block advertisement

14 Security and Communication Networks

Section 42 As for the countermeasure of such attacks bydeploying monitors [60] deployment of 8 monitors in thenetwork to detect the attacks would fail at most 27 out of 95times (sim30) assuming that those 27 unseen transactionswe have identified are initially advertised to the network

63 Potential Impact on Blockchain ApplicationsEthereum and EOS are the most widely used smart contractplatforms fostering various decentralized applications Bit-coin which lacks the capability of executing complex smartcontract codes is also recently utilized to execute smartcontracts for decentralized applications [50 61] Eventhough our work focuses on the fundamental blockchainmechanisms in terms of transactionblock production andpropagation the impact of our findings on decentralizedapplications can be foresighted

According to our blockchain fork results (Section 41)the lack of selfish mining in the real world was speculated bya very low stale block rate of Bitcoin network and prevalenceof nonearliest block endorsement by Ethereum miners Asprofitability of selfish mining encourages miners to behavein a way of producing more blockchain forks the perfor-mance degradation is proportionate to the number of minerswho adopt the selfish mining strategy the key performancemetrics affecting the blockchain application performance

such as node response time or block delivery time are shownto be noticeably degraded due to the selfish mining [62] Forexample decentralized identities issued or revoked on suchblockchains [63 64] cannot be responsively finalized due toinflated blockchain forks Our results show that the selfishmining is not prevalent in the real world thus the appli-cation performance impact is overrated even though it istheoretically shown that miners have every reason to beselfish [38] As for EOS we reported cases where a sequenceof (up to 12) blocks being stale are often observed in suc-cessive mining of two BPs however the rate is too low (ie004) to impact the performance of applications (Section32)

Transaction arrival processes being LRD (Section 51)pose a technical challenge in provisioning transactionprocessing scalability especially for Layer-2 blockchain ap-plication solutions [65 66] For example Layer-2 rollupsolutions require transaction relays which aggregate indi-vidual user transactions of a given blockchain applicationdeployed in the network often without a priori knowledge ofnetwork load One way of solving the problem is a properprioritization of transactions based on the applicationcontext

Lastly blockchain network partitioning can be thebiggest concern for blockchain service providers We ob-served that the increased numbers of peer connections inblockchain reference implementations effectively provide ahigher degree of information redundancy (Section 52)However increased number of peer connections can beexploitable for an attacker who has a denial-of-service attackvector or an invalid transaction initiated by a simple ap-plication bug can flood the network [45]

64 Limitation Our measurement study has several limi-tations First of all our results may only capture only a fewmonths of blockchain network operations In the meantimethe permissionless blockchain pieces of software are in activedevelopment for example Ethereum now utilizes the pooledtransaction delivery [67] instead of unsolicited transactiondelivery which was the only mode at the time of our

Table 10 Bitcoin disparately mempooled transactions

monitors mempooledti

monitors mempooledts

Transactioncount

7 1 26 (3824)6 2 14 (2059)5 3 10 (1471)4 4 5 (735)3 5 5 (735)2 6 3 (441)1 7 3 (441)5 1 1 (147)6 1 1 (147)

Sum 68 (10000)

Tincluded

Tstale

5 10 15 20 25 30 35 40 45 500 of peers

0

005

01

015

02

025

03Fr

eque

ncy

(a)

Tincluded

Tstale

0002004006008

01012014016

Freq

uenc

y

4030 500 10 20 of peers

(b)

Figure 17 Peer redundancy of transaction advertisement (a) Bitcoin (b) Ethereum

Security and Communication Networks 15

measurement Both cryptocurrency market values andblockchain network utilizations are rapidly increasing andthus miners are getting more motivated to optimize theirperformance for example Bitcoin fork probability has be-come far smaller than what is reported previously (seeSection 41)

Second the blockchain state information is not collected inour measurement Our analysis is performed based on onlyavailable information stored in block and transaction logs Wehave utilized an Ethereum archive node [44] to query historicalstate information (eg account balance or account nonce) inSection 42 However such proactive state replication is farmore complicated with EOS unless the full node is configuredto operate as a producing node and logging the state infor-mation thus EOS stale transactions could not be fully un-derstood without the missing EOS network state information

7 Related Work

71 Blockchain Data Analysis Historical transaction data ofBitcoin have often been studied for economic aspects such ascryptocurrency abuse [17] anti-money-laundering [18] andmonetary flow of businesses [19] However historicalblockchain data usually available from block explorer ser-vices are not sufficient for our research purpose

72 Blockchain Measurement Researchers have performedblockchain measurement studies to assess the degree ofdecentralization [20] to investigate demographic informa-tion of network nodes [34 68] to study mining pool be-havior [22] and to evaluate security of PoW blockchains [21]against known attacks such as double-spending attack [60]and selfish mining [37] Our work expands the under-standing of previous security evaluations with the keyfindings acquired from our large-scale transaction and blockmeasurement

73 Blockchain Attacks Partitioning attacks usually exploitvulnerable peer management mechanisms of Bitcoin [51]and Ethereum [52] Such attacks are also examined in thecontext of ISPrsquos BGP hijacking [53] and a stealthier variantrelieving the attacker from the risk of getting exposed [54]Cryptocurrency mining has been a popular subject inassessing the security of Bitcoin selfish mining [37] blockwithholding attack [36] and a mixed strategy [38] have beenstudied Double-spending attacks have been studied in thecontext of Bitcoin fast payments [60]

74 Block Explorer Services We have surveyed the popularblock explorer services of Bitcoin [5 10 12] Ethereum[10 13 16] and EOS [11 14 15] to see the availability ofinformation beyond what is recorded in the main chainblock data we have utilized in our study namely

(i) Stale blockstransactions no Bitcoin and EOS blockexplorers provide stale block information (A relatedstudy [36] has utilized a Bitcoin block explorer service[68] to retrieve stale blocks However the service has

been terminated in March 2019) All Ethereum blockexplorers provide only reported stale blocks (ie uncleblocks [23]) (Ethereum provides incentives for unclestale blocks [44] so that miners include them in theirmined blocks for profit)No block explorers provide stale transaction infor-mation unless one is currently pooled

(ii) Blocktransaction arrival times all block explorersprovide block timestamps that are recorded in theblock headers not the actual times of arrival Ourblockchain fork and gap analysis require measuredblock arrival times at multiple locations All blockexplorers show transaction timestamps identical to theblock timestamp to which the transactions belong(Recent Bitcoin transactions have different timestampsthan the block timestamps in [4] while the timestampsare only at a granularity of one minute) [69 70]

8 Conclusion

We have measured transaction and block arrival events ofthe three permissionless blockchains We have devised anoble analysis model and analyzed completeness of ourblock and transaction logs Finally we have studied thediscrepancy in measured events and arrival characteristics toshare our key findings including a false universal assumptionof previous mining-related studies

Data Availability

e measurement data used to support the findings of thisstudy have not been made available because they containprivate information that can be used to identify individualblockchain nodes

Disclosure

is is an extended and revised version of a conference paperpresented in IEEE ICDCS 2021 [41]

Conflicts of Interest

e authors declare that they have no conflicts of interest

Acknowledgments

e authors would like to thank Seungwon Woo DaegeunYoon and Changhyun Lee for helping them with themeasurement instrumentation is work was supported byElectronics and Telecommunications Research Institute(ETRI) grant funded by the Korean Government (21ZR1300Research on Intelligent Cyber Security and Trust Infra)

References

[1] S Nakamoto ldquoBitcoin a peer-to-peer electronic cash systemrdquo2019

[2] V Buterin ldquoEthereum white paperrdquo 2013 httpsethereumorgenwhitepaper

[3] Monero ldquoMonerordquo 2020 httpswebgetmoneroorg

16 Security and Communication Networks

[4] bitcoincashorg httpswwwbitcoincashorg[5] Blockchaincom httpswwwblockchaincom[6] Ripple ldquoXRP e best digital asset for global paymentsrdquo

2020 httpsripplecomxrp[7] I Foundation ldquoIotardquo 2021 httpswwwiotaorg[8] ldquoEosiordquo 2020 httpseosio[9] S Orsquoneal ldquoEos proves yet again that decentralization is not its

priorityrdquo 2018 httpscointelegraphcomnewseos-proves-yet-again-that-decentralization-is-not-its-priority

[10] Blockchair httpsblockchaircom[11] Bloksio httpsbloksio[12] BTCcom ldquoBitcoin block explorerrdquo 2021 httpsbtccom[13] Ethereum block explorer httpsethbtccom[14] eosflareio Eos block explorer httpseosflareio[15] EOSPark ldquoEos block explorerrdquo 2021 httpseosparkcom[16] Etherscan Ethereum explorer httpsetherscanio[17] S Lee C Yoon and H Kang ldquoCybercriminal minds An

investigative study of cryptocurrency abuses in the dark webrdquoin Proceedings of the Network and Distributed System SecuritySymposium pp 1ndash15 Internet Society San Diego CA USAFebruary 2019

[18] MMoser R Bohme and D Breuker ldquoAn inquiry into moneylaundering tools in the bitcoin ecosystemrdquo in Proceedings ofthe 2013 APWG eCrime Researchers summit pp 1ndash14 IEEESan Francisco CA USA September 2013

[19] M Lischke and B Fabian ldquoAnalyzing the bitcoin network thefirst four yearsrdquo Future Internet vol 8 no 1 2016

[20] A E Gencer S Basu I Eyal R V Renesse and E G SirerldquoDecentralization in bitcoin and ethereum networksrdquo inProceedings of the International Conference On FinancialCryptography and Data Security pp 439ndash457 SpringerNieuwport Curaccedilao February 2018

[21] A Gervais G O Karame KWust V Glykantzis H Ritzdorfand S Capkun ldquoOn the security and performance of proof ofwork blockchainsrdquo in Proceedings Of the 2016 ACM SIGSACConference on Computer and Communications Securitypp 3ndash16 Vienna Austria October 2016

[22] C Wang X Chu and Q Yang ldquoMeasurement and analysis ofthe bitcoin networks a view from mining poolsrdquo 2019httpsarxivorgabs190207549

[23] G Wood ldquoEthereum A secure decentralised generalisedtransaction ledgerrdquo Ethereum Project Yellow Paper vol 1512014

[24] ldquoTransactions protocol eosio developer docsrdquo 2018 httpsdeveloperseosiowelcomev20protocoltransactions_protocol

[25] Y Sompolinsky and A Zohar ldquoSecure high-rate transactionprocessing in bitcoinrdquo in Proceedings of the InternationalConference On Financial Cryptography and Data Securitypp 507ndash527 Springer San Juan PR USA January 2015

[26] Blockone ldquoConsensus protocolrdquo 2018 httpsdeveloperseosiowelcomev20protocolconsensus_protocol

[27] A Gervais H Ritzdorf G O Karame and S CapkunldquoTampering with the delivery of blocks and transactions inbitcoinrdquo in Proceedings Of the 22nd ACM SIGSAC ConferenceOn Computer and Communications Security pp 692ndash705Denver CO USA October 2015

[28] ldquoGithub Bit coinrdquo 2020 httpsgithubcombitcoinbitcoin[29] G Ethereum ldquoGo ethereumrdquo 2020 httpsgithubcom

ethereumgo-ethereum[30] Google ldquoGoogle cloudrdquo 2021 httpscloudgooglecom[31] ldquoHow to replay from a snapshotrdquo 2018 httpsdeveloperseos

iomanualseoslatestnodeosreplayshow-to-replay-from-a-snapshot

[32] C Decker and R Wattenhofer ldquoInformation propagation inthe bitcoin networkrdquo in Proceedings of the IEEE P2P 2013Proceedings pp 1ndash10 IEEE Trento Italy September 2013

[33] ldquoEthereum uncle raterdquo 2020 httpsychartscomindicatorsethereum_uncle_rate

[34] J A Donet C P Sola and J H Joancomartı ldquoe bitcoin p2pnetworkrdquo in Proceedings of the International Conference OnFinancial Cryptography and Data Security pp 87ndash102Springer Christ Church Barbados March 2014

[35] G S Davies ldquoBit-booster - offline commit graph drawingtoolrdquo 2016 httpbit-boostercomgraphhtml

[36] N T Courtois and L Bahack ldquoOn subversive miner strategiesand block withholding attack in bitcoin digital currencyrdquo2014 httpsarxivorgabs14021718

[37] I Eyal and E G Sirer ldquoMajority is not enough bitcoin miningis vulnerablerdquo in Proceedings of the International Conferenceon Financial Cryptography and Data Security pp 436ndash454Springer Christ Church Barbados March 2014

[38] Y Kwon D Kim Y Son E Vasserman and Y Kim ldquoBeselfish and avoid dilemmas fork after withholding (faw) at-tacks on bitcoinrdquo in Proceedings Of the 2017 ACM SIGSACConference On Computer and Communications Securitypp 195ndash209 Abu Dhabi UAE April 2017

[39] B Research ldquoDecentralisation governance and eos - a lostcaserdquo 2020 httpsresearchbinancecomenanalysiseos-governance

[40] B Wiki ldquoIrreversible transactions - finney attackrdquo 2012httpsenbitcoinitwikiIrreversible_Transactions∖Finney_attack

[41] J Poon and T Dryja ldquoe bitcoin lightning network scalableoff-chain instant paymentsrdquo 2016

[42] M Bartoletti and L Pompianu ldquoAn analysis of bitcoin op_return metadatardquo in Proceedings of the International Con-ference On Financial Cryptography and Data Securitypp 218ndash230 Springer Sliema Malta April 2017

[43] ldquoReplace by feerdquo 2018 httpsenbitcoinitwikiReplace_by_fee

[44] E Foundation ldquoNode and clientsrdquo 2020 httpsethereumorgendevelopersdocsnodes-and-clients

[45] H Heo and S Shin ldquoBehind block explorers public block-chain measurement and security implicationrdquo in Proceedingsof the 41th IEEE International Conference On DistributedComputing Systems IEEE Washington DC USA In pressWashington DC USA July 2021

[46] R Bowden H P Keeler A E Krzesinski and P G TaylorldquoBlock arrivals in the bitcoin blockchainrdquo 2018 httpsarxivorgabs180107447

[47] M E Crovella and A Bestavros ldquoExplaining world wide webtraffic self-similarityrdquo Technical Report Citeseer PrincetonNJ USA 1995

[48] H Zhang Y Shu and O Yang ldquoEstimation of hurst pa-rameter by variance-time plotsrdquo in Proceedings of the 1997IEEE Pacific Rim Conference on Communications Computersand Signal Processing PACRIM 10 Years Networkingthe Pacific Rim 1987-1997 IEEE Victoria BC CanadaAugust 1997

[49] A Feldmann ldquoCharacteristics of TCP connection arrivalsrdquo inSelf-Similar Network Traffic and Performance EvaluationK Park andWWillinger Eds pp 367ndash399Wiley HobokenNJ USA 2000

[50] RSK ldquoRSKrdquo 2021 httpswwwrskco[51] E Heilman A Kendler A Zohar and S Goldberg ldquoEclipse

attacks on bitcoinrsquos peer-to-peer networkrdquo in Proceedings of

Security and Communication Networks 17

the 24th USENIX Security Symposium pp 129ndash144 Wash-ington DC USA April 2015

[52] Y Marcus E Heilman and S Goldberg ldquoLow-resourceeclipse attacks on ethereumrsquos peer-to-peer networkrdquo IACRCryptology vol 2018 p 236 2018

[53] M Apostolaki A Zohar and L Vanbever ldquoHijacking bitcoinRouting attacks on cryptocurrenciesrdquo in Proceedings of the2017 IEEE Symposium On Security and Privacy (SP)pp 375ndash392 IEEE San Jose CA USA May 2017

[54] M Tran I Choi G J Moon A V Vu and M S Kang ldquoAstealthier partitioning attack against bitcoin peer-to-peernetworkrdquo in Proceedings of the IEEE Symposium On Securityand Privacy (SampP) San Francisco CA USA May 2020

[55] B I Proposal ldquoBip 0152rdquo 2016 httpsenbitcoinitwikiBIP_0152

[56] B Core ldquoBitcoin Core Version 01901 Release Noterdquo 2016httpsbitcoinorgenreleasev01901

[57] ldquoGeth v190rdquo 2019 httpsblogethereumorg20190710geth-v1-9-0

[58] ldquoProtocol documentationrdquo 2016 httpsenbitcoinitwikiProtocoltext_documentation

[59] C Feng and J Niu ldquoSelfish mining in ethereumrdquo in Pro-ceedings of the 2019 IEEE 39th International Conference OnDistributed Computing Systems (ICDCS) pp 1306ndash1316IEEE Dallas TX USA July 2019

[60] G O Karame E Androulaki and S Capkun ldquoDouble-spending fast payments in bitcoinrdquo in Proceedings of the 2012ACM Conference on Computer and Communications Securitypp 906ndash917 Raleigh NC USA October 2012

[61] P Das L Eckey T Frassetto et al ldquoFastkitten practical smartcontracts on bitcoinrdquo in Proceedimgs of the 28th USENIXSecurity Symposium (USENIX Security 19) pp 801ndash818Santa Clara CA USA August 2019

[62] S G Motlagh J Misic and V B Misic ldquoe impact of selfishmining on bitcoin network performancerdquo IEEE Transactionson Network Science and Engineering vol 8 no 1 pp 724ndash7352021

[63] A Muhle A Gruner T Gayvoronskaya and C Meinel ldquoAsurvey on essential components of a self-sovereign identityrdquoComputer Science Review vol 30 pp 80ndash86 2018

[64] M Toorani and C Gehrmann ldquoA decentralized dynamic pkibased on blockchainrdquo in Proceedings Of the 36th Annual ACMSymposium On Applied Computing pp 1646ndash1655 GwangjuKorea March 2021

[65] E foundation ldquoOptimistic-rollupsrdquo 2021 httpsdocsethhubioethereum-roadmaplayer-2-scalingoptimistictext_rollups

[66] ldquoZk-rollupsrdquo 2021 httpsdocsethhubioethereum-roadmaplayer-2-scalingzk-rollups

[67] E foundation ldquoEthereumwire protocolrdquo 2019 httpsgithubcomethereumdevp2pblobmastercapseth

[68] S K Kim Z Ma S Murali J Mason A Miller andM BaileyldquoMeasuring ethereum network peersrdquo in Proceedings of theInternet Measurement Conference 2018 pp 91ndash104 BostonMA USA October 2018

[69] Symmetricom ldquoDelivering sub-microsecond accurate time tolinux applications around the worldrdquo 2012 httpwwwchronoscoukfilespdfswpsWP_AccurateTimeForLinuxApplicationspdf

[70] Ycharts ldquoBlocktrail blockchain data query service (termi-nated)rdquo 2019 httpsblocktrailcom

18 Security and Communication Networks

Figure 13(a) As regards the block arrival processes Bitcoinblock arrivals exhibit a linear slope β minus23 e estimatedHurst parameter H 1 + β2 43 implies that the processis not a homogeneous Poisson process but LRD (Long-Range Dependent) contrary to what is expected for a regularinterval event generation [46] Ethereum block arrivalsapproximate the Bitcoinrsquos except for the high aggregationlevel due to high stale block rate EOS block arrivals incontrast follow the slope β minus1 in the low aggregation levelas the block generation is indeed regularly scheduled

Figure 14 shows the variance-time plot of Ethereum andEOS block arrival time series by taking all block arrivalevents (Bobs) and main chain block arrivals only (Bmain) Weconfirm that Ethereum block arrivals indeed exhibit astraight line (close to Bitcoin) if excluding stale blocksHowever EOS block arrivals do not exhibit a straight line

even if we exclude stale blocks due to delayed burst blockarrivals possibly due to cut-tail fork patterns (see Section41)

e transaction arrival processes of all three blockchainsappear to exhibit LRD with Hurst parameter Hgt 56 asβltminus13 To further identify analytical distributions that fitbest the empirical ones the coefficient of variation (σμ) andskewness (ie the standardized third moment) of transac-tion interarrival times are computed for every measurementdataset and compared to the relationships expected for theexponential lognormal Weibull and Gamma distributionsin Figure 13(b) We find that Bitcoin Ethereum and EOStransaction interarrival times are fit best Gamma Weibulland lognormal distribution respectively Individual datasetsare also examined for the fitness of the distribution to findthat the empirical distribution fits the analytical distribution

Virtualclock

Time

Transaction initiator

Time

Blockproducer

Time

Monitornode

Time

Scheduled block time of blib

Scheduled block time of bhead

Scheduled block time of bincl

1 Produce and propagate blib

2 Produce and propagate bhead

Expiration time of t

4 Produce and propagate bincl

Δexp

Δtrx

Δincl

3 Create and propagate t

Figure 11 EOS transaction analysis model

Tincluded

Tstale

Tunseen

0010203040506070809

1

Cum

ulat

ive f

requ

ency

100 200 300 400 5000Time difference (seconds)

(a)

Tincluded

Tunseen

01 1 10 100 1000001Time difference (seconds)

0010203040506070809

1

Cum

ulat

ive f

requ

ency

(b)

Tincluded

Tstale

0010203040506070809

1

Cum

ulat

ive f

requ

ency

01 1 10 100 1000001Time difference (seconds)

(c)

Figure 12 EOS transaction timing analysis (a) Δexp (b) Δincl (c) Δtrx

12 Security and Communication Networks

well except for the small interarrival time ranges For ex-ample Figure 15 depicts the CDF of Ethereum transactioninterarrival times observed in US-West Although the em-pirical distribution fits Weibull with parameters computedwith the maximum likelihood estimator [49] sample pointsunder several milliseconds appear to be unreliable (We areyet unaware of the reason However it is known that thetime source of commodity operating systems is not accurateand we need an external time source for accurate sub-millisecond timing measurement [50])

52AdvertisementRedundancy Bitcoin and Ethereum nodepieces of software are implemented to maintain a large

number of peer connections with multiple random remotenodes Bitcoin Core can connect up to 125 peers where 8 ofthem are outbound connections Go Ethereum maintains 50peer connections where 16 of them are outbound by default(see Table 1) On the other hand partitioning attacks aredeveloped to isolate a blockchain node from the others bytampering with all such peer connections Partitioning at-tacks usually exploit vulnerable peer management mecha-nisms of Bitcoin [51] and Ethereum [52] Such attacks arealso examined in the context of ISPrsquos BGP hijacking [53] anda stealthier variant relieving the attacker from the risk ofgetting exposed [54] e attacks often rely on imple-mentation vulnerabilities for efficient eclipsing of peerswhile known vulnerabilities are getting addressed for ex-ample the lack of parallel block download sessions causing

Slope = ndash1

Trx BitcoinTrx EthereumTrx EOS

Blk BitcoinBlk EthereumBlk EOS

ndash12

ndash10

ndash8

ndash6

ndash4

ndash2

0Lo

g no

rmal

ized

var

ianc

e

124 6 10 140 2 8Aggregation level

(a)

Lognormal

Weibull

Gamma

Exponential

BitcoinEthereumEOS

0

5

10

15

20

Stan

dard

ized

third

mom

ent

1 2 3 40Coefficient of variation

(b)

Figure 13 Transaction arrival characteristics (a) Variance-time plot of block and transaction arrivals (b) Cov versus skewness oftransaction interarrival times

Ethereum - Bobs

Ethereum - Bmain

EOS - Bobs

EOS - Bmain

ndash12

ndash10

ndash8

ndash6

ndash4

ndash2

0

Log

norm

aliz

ed v

aria

nce

2 4 6 8 10 12 140Aggregation level

Figure 14 Variance-time plot of block arrivals including staleblocks (Bobs) and excluding stale blocks (Bmain)

EmpiricalExponential μ = 0024

Lognormal μ = 00354 σ2 = 00486Pareto k = 0000212 a = 0231Weibull c = 0589 a = 00147

00001 0001 001 01 1000001Time (seconds)

0

02

04

06

08

1

Cum

ulat

ive f

requ

ency

Figure 15 Empirical and fitted analytical distributions of Ether-eum transaction interarrival times

Security and Communication Networks 13

temporary denial of blocks (reported in [27] and fixed byrecommending three concurrent download sessions in [55])let attackers successfully partition the node without eclipsingall peer connections [53] A simple countermeasure of in-creasing the number of peer connections on the other handis applied to the reference public blockchain implementa-tions [56 57] to inflate attack complexity

We investigate the degree of a peerrsquos advertisementredundancy on newly generated blocks and transactions toevaluate the efficacy of partitioning attacks and the coun-termeasure of increasing the number of peer connectionsFigure 16 shows how redundantly newly generated blockinformation is offered by peers Bitcoin nodes have main-tained sim43 peer connections that is 8 outbound and ad-ditional 35 inbound connections on average and Ethereumnodes record all 50 peer connections established during theentire observation period

For each newly generated block one-third of peersadvertised the block header to our Bitcoin node and morethan 90 of Ethereum peers signaled availability of theblocks In consequence successfully partitioning a noderequires compromise of peers proportional to the totalnumber of peer connections Increasing the number of peerconnections will burden the attacker linearly as expected

Figure 17 shows how redundantly the newly generatedtransaction information is offered by peers While one out ofthree Bitcoin peers also advertises new transactions viaINVENTORYmessage [58] half of the Ethereum peers havesent new transactions to our node in average Bitcoin andEthereum blocks are advertised with the block header(rather than the direct delivery of all block contents) Bitcointransactions are also advertised with INVENTORY messagebefore the whole contents are transferred HoweverEthereum transaction data that is the entire contents aredirectly sent by peers (Ethereum now has a pooled trans-action delivery model in its newer ETH64 protocol [30])We also find that there are cases with much less advertisedtransactions and have identified that they are indeed mostlystale ones stale transactions are mostly due to conflict (seeSection 42) and the nodes that already queued the conflicttransaction will not relay the stale one

6 Discussion

61 Implication on Mining Attacks Cryptocurrency mininghas been a popular subject in assessing the security ofBitcoin selfish mining [37] block withholding attack [36]and a mixed strategy [38] have been studied Although it isshown that selfish behavior in mining is always moreprofitable than being honest without need for a mutualagreement of not attacking each other [38] we find thatselfish mining is not the preferred strategy All selfish miningstrategies will result in blockchain forks but we observe avery low fork probability (ie 004) for Bitcoin On theother hand selfish mining on Ethereum has been studiedonly recently to unanimously claim that selfish mining isalso profitable for Ethereum miners however it is lessprofitable than Bitcoin due to its uncle reward system [59]Our result in Section 4 shows that a majority of Ethereum

miners choose to add to their own produced blocks over theearliest propagated blocks How does this affect the selfishmining strategy

e selfish mining strategy assumes a parameter c whichdefines the fraction of honest minersrsquo mines on the attackerrsquosfork branch (e parameter comes into play in case (f ) of[27]) If the attacking pool has a network-wise superiorposition in block propagation (ie cgt 05) the selfishmining strategy is profitable for pools with proportionalmining power αgt 25 [37] Absolute network inferiority(ie c 0 due to a defensive mining strategy such as the onepresented in Section 41) increases the required miningpower to 33 the 33 mining power appears to be sig-nificantly harder to achieve in the real world [20]

As for the FAW (Fork-After-Withholding) attackstrategy [38] the network capability parameter C defines theprobability that an attackerrsquos FPoW (Full Proof-of-Work)block (during infiltration mining) is selected as a main chainblock C affects both the attack reward and whether theminerrsquos dilemma holds or not in the mutual attacking gameAs an example case (Section 9 of [38]) of a two-pool gamebetween F2Pool and BitFury the absolute network inferi-ority drops C from 0914 to 03 to make it a dilemmatic gameagain Unfortunately minersrsquo own block preferences cannotbe directly transferred to a single parameter of c or C it callsfor a model change from previous mining studies

62 Conflict Transactions and Double-Spending AttacksDouble-spending attacks have been studied in the context ofBitcoin fast payments where zero or only one confirmation isrequired to complete an offline merchandise transaction[60] real-world cases where two conflict transactions dis-parately arrive at different measurement locations mayimply such attacks Table 10 shows the cases where twotransactions are in conflict (and thus only one of themis included in a block ie inputs(ti)cap inputs(ts)neemptyand existb isin Bmain ti isin transactions(b) (∄b isin Bmain ts isintransactions(b) is indisputable given a consistent transactionledger)) and two different subsets of the monitors havemempooled either one of them We also have identified 27unseen transactions implying possible one-confirmationattack variant requiring the private mining (ie not ad-vertising the double-spending transaction to the network) in

5 10 15 20 25 30 35 40 45 500 of peers

0

005

01

015

02

025

Freq

uenc

y

BitcoinEthereum

Figure 16 Peer redundancy of block advertisement

14 Security and Communication Networks

Section 42 As for the countermeasure of such attacks bydeploying monitors [60] deployment of 8 monitors in thenetwork to detect the attacks would fail at most 27 out of 95times (sim30) assuming that those 27 unseen transactionswe have identified are initially advertised to the network

63 Potential Impact on Blockchain ApplicationsEthereum and EOS are the most widely used smart contractplatforms fostering various decentralized applications Bit-coin which lacks the capability of executing complex smartcontract codes is also recently utilized to execute smartcontracts for decentralized applications [50 61] Eventhough our work focuses on the fundamental blockchainmechanisms in terms of transactionblock production andpropagation the impact of our findings on decentralizedapplications can be foresighted

According to our blockchain fork results (Section 41)the lack of selfish mining in the real world was speculated bya very low stale block rate of Bitcoin network and prevalenceof nonearliest block endorsement by Ethereum miners Asprofitability of selfish mining encourages miners to behavein a way of producing more blockchain forks the perfor-mance degradation is proportionate to the number of minerswho adopt the selfish mining strategy the key performancemetrics affecting the blockchain application performance

such as node response time or block delivery time are shownto be noticeably degraded due to the selfish mining [62] Forexample decentralized identities issued or revoked on suchblockchains [63 64] cannot be responsively finalized due toinflated blockchain forks Our results show that the selfishmining is not prevalent in the real world thus the appli-cation performance impact is overrated even though it istheoretically shown that miners have every reason to beselfish [38] As for EOS we reported cases where a sequenceof (up to 12) blocks being stale are often observed in suc-cessive mining of two BPs however the rate is too low (ie004) to impact the performance of applications (Section32)

Transaction arrival processes being LRD (Section 51)pose a technical challenge in provisioning transactionprocessing scalability especially for Layer-2 blockchain ap-plication solutions [65 66] For example Layer-2 rollupsolutions require transaction relays which aggregate indi-vidual user transactions of a given blockchain applicationdeployed in the network often without a priori knowledge ofnetwork load One way of solving the problem is a properprioritization of transactions based on the applicationcontext

Lastly blockchain network partitioning can be thebiggest concern for blockchain service providers We ob-served that the increased numbers of peer connections inblockchain reference implementations effectively provide ahigher degree of information redundancy (Section 52)However increased number of peer connections can beexploitable for an attacker who has a denial-of-service attackvector or an invalid transaction initiated by a simple ap-plication bug can flood the network [45]

64 Limitation Our measurement study has several limi-tations First of all our results may only capture only a fewmonths of blockchain network operations In the meantimethe permissionless blockchain pieces of software are in activedevelopment for example Ethereum now utilizes the pooledtransaction delivery [67] instead of unsolicited transactiondelivery which was the only mode at the time of our

Table 10 Bitcoin disparately mempooled transactions

monitors mempooledti

monitors mempooledts

Transactioncount

7 1 26 (3824)6 2 14 (2059)5 3 10 (1471)4 4 5 (735)3 5 5 (735)2 6 3 (441)1 7 3 (441)5 1 1 (147)6 1 1 (147)

Sum 68 (10000)

Tincluded

Tstale

5 10 15 20 25 30 35 40 45 500 of peers

0

005

01

015

02

025

03Fr

eque

ncy

(a)

Tincluded

Tstale

0002004006008

01012014016

Freq

uenc

y

4030 500 10 20 of peers

(b)

Figure 17 Peer redundancy of transaction advertisement (a) Bitcoin (b) Ethereum

Security and Communication Networks 15

measurement Both cryptocurrency market values andblockchain network utilizations are rapidly increasing andthus miners are getting more motivated to optimize theirperformance for example Bitcoin fork probability has be-come far smaller than what is reported previously (seeSection 41)

Second the blockchain state information is not collected inour measurement Our analysis is performed based on onlyavailable information stored in block and transaction logs Wehave utilized an Ethereum archive node [44] to query historicalstate information (eg account balance or account nonce) inSection 42 However such proactive state replication is farmore complicated with EOS unless the full node is configuredto operate as a producing node and logging the state infor-mation thus EOS stale transactions could not be fully un-derstood without the missing EOS network state information

7 Related Work

71 Blockchain Data Analysis Historical transaction data ofBitcoin have often been studied for economic aspects such ascryptocurrency abuse [17] anti-money-laundering [18] andmonetary flow of businesses [19] However historicalblockchain data usually available from block explorer ser-vices are not sufficient for our research purpose

72 Blockchain Measurement Researchers have performedblockchain measurement studies to assess the degree ofdecentralization [20] to investigate demographic informa-tion of network nodes [34 68] to study mining pool be-havior [22] and to evaluate security of PoW blockchains [21]against known attacks such as double-spending attack [60]and selfish mining [37] Our work expands the under-standing of previous security evaluations with the keyfindings acquired from our large-scale transaction and blockmeasurement

73 Blockchain Attacks Partitioning attacks usually exploitvulnerable peer management mechanisms of Bitcoin [51]and Ethereum [52] Such attacks are also examined in thecontext of ISPrsquos BGP hijacking [53] and a stealthier variantrelieving the attacker from the risk of getting exposed [54]Cryptocurrency mining has been a popular subject inassessing the security of Bitcoin selfish mining [37] blockwithholding attack [36] and a mixed strategy [38] have beenstudied Double-spending attacks have been studied in thecontext of Bitcoin fast payments [60]

74 Block Explorer Services We have surveyed the popularblock explorer services of Bitcoin [5 10 12] Ethereum[10 13 16] and EOS [11 14 15] to see the availability ofinformation beyond what is recorded in the main chainblock data we have utilized in our study namely

(i) Stale blockstransactions no Bitcoin and EOS blockexplorers provide stale block information (A relatedstudy [36] has utilized a Bitcoin block explorer service[68] to retrieve stale blocks However the service has

been terminated in March 2019) All Ethereum blockexplorers provide only reported stale blocks (ie uncleblocks [23]) (Ethereum provides incentives for unclestale blocks [44] so that miners include them in theirmined blocks for profit)No block explorers provide stale transaction infor-mation unless one is currently pooled

(ii) Blocktransaction arrival times all block explorersprovide block timestamps that are recorded in theblock headers not the actual times of arrival Ourblockchain fork and gap analysis require measuredblock arrival times at multiple locations All blockexplorers show transaction timestamps identical to theblock timestamp to which the transactions belong(Recent Bitcoin transactions have different timestampsthan the block timestamps in [4] while the timestampsare only at a granularity of one minute) [69 70]

8 Conclusion

We have measured transaction and block arrival events ofthe three permissionless blockchains We have devised anoble analysis model and analyzed completeness of ourblock and transaction logs Finally we have studied thediscrepancy in measured events and arrival characteristics toshare our key findings including a false universal assumptionof previous mining-related studies

Data Availability

e measurement data used to support the findings of thisstudy have not been made available because they containprivate information that can be used to identify individualblockchain nodes

Disclosure

is is an extended and revised version of a conference paperpresented in IEEE ICDCS 2021 [41]

Conflicts of Interest

e authors declare that they have no conflicts of interest

Acknowledgments

e authors would like to thank Seungwon Woo DaegeunYoon and Changhyun Lee for helping them with themeasurement instrumentation is work was supported byElectronics and Telecommunications Research Institute(ETRI) grant funded by the Korean Government (21ZR1300Research on Intelligent Cyber Security and Trust Infra)

References

[1] S Nakamoto ldquoBitcoin a peer-to-peer electronic cash systemrdquo2019

[2] V Buterin ldquoEthereum white paperrdquo 2013 httpsethereumorgenwhitepaper

[3] Monero ldquoMonerordquo 2020 httpswebgetmoneroorg

16 Security and Communication Networks

[4] bitcoincashorg httpswwwbitcoincashorg[5] Blockchaincom httpswwwblockchaincom[6] Ripple ldquoXRP e best digital asset for global paymentsrdquo

2020 httpsripplecomxrp[7] I Foundation ldquoIotardquo 2021 httpswwwiotaorg[8] ldquoEosiordquo 2020 httpseosio[9] S Orsquoneal ldquoEos proves yet again that decentralization is not its

priorityrdquo 2018 httpscointelegraphcomnewseos-proves-yet-again-that-decentralization-is-not-its-priority

[10] Blockchair httpsblockchaircom[11] Bloksio httpsbloksio[12] BTCcom ldquoBitcoin block explorerrdquo 2021 httpsbtccom[13] Ethereum block explorer httpsethbtccom[14] eosflareio Eos block explorer httpseosflareio[15] EOSPark ldquoEos block explorerrdquo 2021 httpseosparkcom[16] Etherscan Ethereum explorer httpsetherscanio[17] S Lee C Yoon and H Kang ldquoCybercriminal minds An

investigative study of cryptocurrency abuses in the dark webrdquoin Proceedings of the Network and Distributed System SecuritySymposium pp 1ndash15 Internet Society San Diego CA USAFebruary 2019

[18] MMoser R Bohme and D Breuker ldquoAn inquiry into moneylaundering tools in the bitcoin ecosystemrdquo in Proceedings ofthe 2013 APWG eCrime Researchers summit pp 1ndash14 IEEESan Francisco CA USA September 2013

[19] M Lischke and B Fabian ldquoAnalyzing the bitcoin network thefirst four yearsrdquo Future Internet vol 8 no 1 2016

[20] A E Gencer S Basu I Eyal R V Renesse and E G SirerldquoDecentralization in bitcoin and ethereum networksrdquo inProceedings of the International Conference On FinancialCryptography and Data Security pp 439ndash457 SpringerNieuwport Curaccedilao February 2018

[21] A Gervais G O Karame KWust V Glykantzis H Ritzdorfand S Capkun ldquoOn the security and performance of proof ofwork blockchainsrdquo in Proceedings Of the 2016 ACM SIGSACConference on Computer and Communications Securitypp 3ndash16 Vienna Austria October 2016

[22] C Wang X Chu and Q Yang ldquoMeasurement and analysis ofthe bitcoin networks a view from mining poolsrdquo 2019httpsarxivorgabs190207549

[23] G Wood ldquoEthereum A secure decentralised generalisedtransaction ledgerrdquo Ethereum Project Yellow Paper vol 1512014

[24] ldquoTransactions protocol eosio developer docsrdquo 2018 httpsdeveloperseosiowelcomev20protocoltransactions_protocol

[25] Y Sompolinsky and A Zohar ldquoSecure high-rate transactionprocessing in bitcoinrdquo in Proceedings of the InternationalConference On Financial Cryptography and Data Securitypp 507ndash527 Springer San Juan PR USA January 2015

[26] Blockone ldquoConsensus protocolrdquo 2018 httpsdeveloperseosiowelcomev20protocolconsensus_protocol

[27] A Gervais H Ritzdorf G O Karame and S CapkunldquoTampering with the delivery of blocks and transactions inbitcoinrdquo in Proceedings Of the 22nd ACM SIGSAC ConferenceOn Computer and Communications Security pp 692ndash705Denver CO USA October 2015

[28] ldquoGithub Bit coinrdquo 2020 httpsgithubcombitcoinbitcoin[29] G Ethereum ldquoGo ethereumrdquo 2020 httpsgithubcom

ethereumgo-ethereum[30] Google ldquoGoogle cloudrdquo 2021 httpscloudgooglecom[31] ldquoHow to replay from a snapshotrdquo 2018 httpsdeveloperseos

iomanualseoslatestnodeosreplayshow-to-replay-from-a-snapshot

[32] C Decker and R Wattenhofer ldquoInformation propagation inthe bitcoin networkrdquo in Proceedings of the IEEE P2P 2013Proceedings pp 1ndash10 IEEE Trento Italy September 2013

[33] ldquoEthereum uncle raterdquo 2020 httpsychartscomindicatorsethereum_uncle_rate

[34] J A Donet C P Sola and J H Joancomartı ldquoe bitcoin p2pnetworkrdquo in Proceedings of the International Conference OnFinancial Cryptography and Data Security pp 87ndash102Springer Christ Church Barbados March 2014

[35] G S Davies ldquoBit-booster - offline commit graph drawingtoolrdquo 2016 httpbit-boostercomgraphhtml

[36] N T Courtois and L Bahack ldquoOn subversive miner strategiesand block withholding attack in bitcoin digital currencyrdquo2014 httpsarxivorgabs14021718

[37] I Eyal and E G Sirer ldquoMajority is not enough bitcoin miningis vulnerablerdquo in Proceedings of the International Conferenceon Financial Cryptography and Data Security pp 436ndash454Springer Christ Church Barbados March 2014

[38] Y Kwon D Kim Y Son E Vasserman and Y Kim ldquoBeselfish and avoid dilemmas fork after withholding (faw) at-tacks on bitcoinrdquo in Proceedings Of the 2017 ACM SIGSACConference On Computer and Communications Securitypp 195ndash209 Abu Dhabi UAE April 2017

[39] B Research ldquoDecentralisation governance and eos - a lostcaserdquo 2020 httpsresearchbinancecomenanalysiseos-governance

[40] B Wiki ldquoIrreversible transactions - finney attackrdquo 2012httpsenbitcoinitwikiIrreversible_Transactions∖Finney_attack

[41] J Poon and T Dryja ldquoe bitcoin lightning network scalableoff-chain instant paymentsrdquo 2016

[42] M Bartoletti and L Pompianu ldquoAn analysis of bitcoin op_return metadatardquo in Proceedings of the International Con-ference On Financial Cryptography and Data Securitypp 218ndash230 Springer Sliema Malta April 2017

[43] ldquoReplace by feerdquo 2018 httpsenbitcoinitwikiReplace_by_fee

[44] E Foundation ldquoNode and clientsrdquo 2020 httpsethereumorgendevelopersdocsnodes-and-clients

[45] H Heo and S Shin ldquoBehind block explorers public block-chain measurement and security implicationrdquo in Proceedingsof the 41th IEEE International Conference On DistributedComputing Systems IEEE Washington DC USA In pressWashington DC USA July 2021

[46] R Bowden H P Keeler A E Krzesinski and P G TaylorldquoBlock arrivals in the bitcoin blockchainrdquo 2018 httpsarxivorgabs180107447

[47] M E Crovella and A Bestavros ldquoExplaining world wide webtraffic self-similarityrdquo Technical Report Citeseer PrincetonNJ USA 1995

[48] H Zhang Y Shu and O Yang ldquoEstimation of hurst pa-rameter by variance-time plotsrdquo in Proceedings of the 1997IEEE Pacific Rim Conference on Communications Computersand Signal Processing PACRIM 10 Years Networkingthe Pacific Rim 1987-1997 IEEE Victoria BC CanadaAugust 1997

[49] A Feldmann ldquoCharacteristics of TCP connection arrivalsrdquo inSelf-Similar Network Traffic and Performance EvaluationK Park andWWillinger Eds pp 367ndash399Wiley HobokenNJ USA 2000

[50] RSK ldquoRSKrdquo 2021 httpswwwrskco[51] E Heilman A Kendler A Zohar and S Goldberg ldquoEclipse

attacks on bitcoinrsquos peer-to-peer networkrdquo in Proceedings of

Security and Communication Networks 17

the 24th USENIX Security Symposium pp 129ndash144 Wash-ington DC USA April 2015

[52] Y Marcus E Heilman and S Goldberg ldquoLow-resourceeclipse attacks on ethereumrsquos peer-to-peer networkrdquo IACRCryptology vol 2018 p 236 2018

[53] M Apostolaki A Zohar and L Vanbever ldquoHijacking bitcoinRouting attacks on cryptocurrenciesrdquo in Proceedings of the2017 IEEE Symposium On Security and Privacy (SP)pp 375ndash392 IEEE San Jose CA USA May 2017

[54] M Tran I Choi G J Moon A V Vu and M S Kang ldquoAstealthier partitioning attack against bitcoin peer-to-peernetworkrdquo in Proceedings of the IEEE Symposium On Securityand Privacy (SampP) San Francisco CA USA May 2020

[55] B I Proposal ldquoBip 0152rdquo 2016 httpsenbitcoinitwikiBIP_0152

[56] B Core ldquoBitcoin Core Version 01901 Release Noterdquo 2016httpsbitcoinorgenreleasev01901

[57] ldquoGeth v190rdquo 2019 httpsblogethereumorg20190710geth-v1-9-0

[58] ldquoProtocol documentationrdquo 2016 httpsenbitcoinitwikiProtocoltext_documentation

[59] C Feng and J Niu ldquoSelfish mining in ethereumrdquo in Pro-ceedings of the 2019 IEEE 39th International Conference OnDistributed Computing Systems (ICDCS) pp 1306ndash1316IEEE Dallas TX USA July 2019

[60] G O Karame E Androulaki and S Capkun ldquoDouble-spending fast payments in bitcoinrdquo in Proceedings of the 2012ACM Conference on Computer and Communications Securitypp 906ndash917 Raleigh NC USA October 2012

[61] P Das L Eckey T Frassetto et al ldquoFastkitten practical smartcontracts on bitcoinrdquo in Proceedimgs of the 28th USENIXSecurity Symposium (USENIX Security 19) pp 801ndash818Santa Clara CA USA August 2019

[62] S G Motlagh J Misic and V B Misic ldquoe impact of selfishmining on bitcoin network performancerdquo IEEE Transactionson Network Science and Engineering vol 8 no 1 pp 724ndash7352021

[63] A Muhle A Gruner T Gayvoronskaya and C Meinel ldquoAsurvey on essential components of a self-sovereign identityrdquoComputer Science Review vol 30 pp 80ndash86 2018

[64] M Toorani and C Gehrmann ldquoA decentralized dynamic pkibased on blockchainrdquo in Proceedings Of the 36th Annual ACMSymposium On Applied Computing pp 1646ndash1655 GwangjuKorea March 2021

[65] E foundation ldquoOptimistic-rollupsrdquo 2021 httpsdocsethhubioethereum-roadmaplayer-2-scalingoptimistictext_rollups

[66] ldquoZk-rollupsrdquo 2021 httpsdocsethhubioethereum-roadmaplayer-2-scalingzk-rollups

[67] E foundation ldquoEthereumwire protocolrdquo 2019 httpsgithubcomethereumdevp2pblobmastercapseth

[68] S K Kim Z Ma S Murali J Mason A Miller andM BaileyldquoMeasuring ethereum network peersrdquo in Proceedings of theInternet Measurement Conference 2018 pp 91ndash104 BostonMA USA October 2018

[69] Symmetricom ldquoDelivering sub-microsecond accurate time tolinux applications around the worldrdquo 2012 httpwwwchronoscoukfilespdfswpsWP_AccurateTimeForLinuxApplicationspdf

[70] Ycharts ldquoBlocktrail blockchain data query service (termi-nated)rdquo 2019 httpsblocktrailcom

18 Security and Communication Networks

well except for the small interarrival time ranges For ex-ample Figure 15 depicts the CDF of Ethereum transactioninterarrival times observed in US-West Although the em-pirical distribution fits Weibull with parameters computedwith the maximum likelihood estimator [49] sample pointsunder several milliseconds appear to be unreliable (We areyet unaware of the reason However it is known that thetime source of commodity operating systems is not accurateand we need an external time source for accurate sub-millisecond timing measurement [50])

52AdvertisementRedundancy Bitcoin and Ethereum nodepieces of software are implemented to maintain a large

number of peer connections with multiple random remotenodes Bitcoin Core can connect up to 125 peers where 8 ofthem are outbound connections Go Ethereum maintains 50peer connections where 16 of them are outbound by default(see Table 1) On the other hand partitioning attacks aredeveloped to isolate a blockchain node from the others bytampering with all such peer connections Partitioning at-tacks usually exploit vulnerable peer management mecha-nisms of Bitcoin [51] and Ethereum [52] Such attacks arealso examined in the context of ISPrsquos BGP hijacking [53] anda stealthier variant relieving the attacker from the risk ofgetting exposed [54] e attacks often rely on imple-mentation vulnerabilities for efficient eclipsing of peerswhile known vulnerabilities are getting addressed for ex-ample the lack of parallel block download sessions causing

Slope = ndash1

Trx BitcoinTrx EthereumTrx EOS

Blk BitcoinBlk EthereumBlk EOS

ndash12

ndash10

ndash8

ndash6

ndash4

ndash2

0Lo

g no

rmal

ized

var

ianc

e

124 6 10 140 2 8Aggregation level

(a)

Lognormal

Weibull

Gamma

Exponential

BitcoinEthereumEOS

0

5

10

15

20

Stan

dard

ized

third

mom

ent

1 2 3 40Coefficient of variation

(b)

Figure 13 Transaction arrival characteristics (a) Variance-time plot of block and transaction arrivals (b) Cov versus skewness oftransaction interarrival times

Ethereum - Bobs

Ethereum - Bmain

EOS - Bobs

EOS - Bmain

ndash12

ndash10

ndash8

ndash6

ndash4

ndash2

0

Log

norm

aliz

ed v

aria

nce

2 4 6 8 10 12 140Aggregation level

Figure 14 Variance-time plot of block arrivals including staleblocks (Bobs) and excluding stale blocks (Bmain)

EmpiricalExponential μ = 0024

Lognormal μ = 00354 σ2 = 00486Pareto k = 0000212 a = 0231Weibull c = 0589 a = 00147

00001 0001 001 01 1000001Time (seconds)

0

02

04

06

08

1

Cum

ulat

ive f

requ

ency

Figure 15 Empirical and fitted analytical distributions of Ether-eum transaction interarrival times

Security and Communication Networks 13

temporary denial of blocks (reported in [27] and fixed byrecommending three concurrent download sessions in [55])let attackers successfully partition the node without eclipsingall peer connections [53] A simple countermeasure of in-creasing the number of peer connections on the other handis applied to the reference public blockchain implementa-tions [56 57] to inflate attack complexity

We investigate the degree of a peerrsquos advertisementredundancy on newly generated blocks and transactions toevaluate the efficacy of partitioning attacks and the coun-termeasure of increasing the number of peer connectionsFigure 16 shows how redundantly newly generated blockinformation is offered by peers Bitcoin nodes have main-tained sim43 peer connections that is 8 outbound and ad-ditional 35 inbound connections on average and Ethereumnodes record all 50 peer connections established during theentire observation period

For each newly generated block one-third of peersadvertised the block header to our Bitcoin node and morethan 90 of Ethereum peers signaled availability of theblocks In consequence successfully partitioning a noderequires compromise of peers proportional to the totalnumber of peer connections Increasing the number of peerconnections will burden the attacker linearly as expected

Figure 17 shows how redundantly the newly generatedtransaction information is offered by peers While one out ofthree Bitcoin peers also advertises new transactions viaINVENTORYmessage [58] half of the Ethereum peers havesent new transactions to our node in average Bitcoin andEthereum blocks are advertised with the block header(rather than the direct delivery of all block contents) Bitcointransactions are also advertised with INVENTORY messagebefore the whole contents are transferred HoweverEthereum transaction data that is the entire contents aredirectly sent by peers (Ethereum now has a pooled trans-action delivery model in its newer ETH64 protocol [30])We also find that there are cases with much less advertisedtransactions and have identified that they are indeed mostlystale ones stale transactions are mostly due to conflict (seeSection 42) and the nodes that already queued the conflicttransaction will not relay the stale one

6 Discussion

61 Implication on Mining Attacks Cryptocurrency mininghas been a popular subject in assessing the security ofBitcoin selfish mining [37] block withholding attack [36]and a mixed strategy [38] have been studied Although it isshown that selfish behavior in mining is always moreprofitable than being honest without need for a mutualagreement of not attacking each other [38] we find thatselfish mining is not the preferred strategy All selfish miningstrategies will result in blockchain forks but we observe avery low fork probability (ie 004) for Bitcoin On theother hand selfish mining on Ethereum has been studiedonly recently to unanimously claim that selfish mining isalso profitable for Ethereum miners however it is lessprofitable than Bitcoin due to its uncle reward system [59]Our result in Section 4 shows that a majority of Ethereum

miners choose to add to their own produced blocks over theearliest propagated blocks How does this affect the selfishmining strategy

e selfish mining strategy assumes a parameter c whichdefines the fraction of honest minersrsquo mines on the attackerrsquosfork branch (e parameter comes into play in case (f ) of[27]) If the attacking pool has a network-wise superiorposition in block propagation (ie cgt 05) the selfishmining strategy is profitable for pools with proportionalmining power αgt 25 [37] Absolute network inferiority(ie c 0 due to a defensive mining strategy such as the onepresented in Section 41) increases the required miningpower to 33 the 33 mining power appears to be sig-nificantly harder to achieve in the real world [20]

As for the FAW (Fork-After-Withholding) attackstrategy [38] the network capability parameter C defines theprobability that an attackerrsquos FPoW (Full Proof-of-Work)block (during infiltration mining) is selected as a main chainblock C affects both the attack reward and whether theminerrsquos dilemma holds or not in the mutual attacking gameAs an example case (Section 9 of [38]) of a two-pool gamebetween F2Pool and BitFury the absolute network inferi-ority drops C from 0914 to 03 to make it a dilemmatic gameagain Unfortunately minersrsquo own block preferences cannotbe directly transferred to a single parameter of c or C it callsfor a model change from previous mining studies

62 Conflict Transactions and Double-Spending AttacksDouble-spending attacks have been studied in the context ofBitcoin fast payments where zero or only one confirmation isrequired to complete an offline merchandise transaction[60] real-world cases where two conflict transactions dis-parately arrive at different measurement locations mayimply such attacks Table 10 shows the cases where twotransactions are in conflict (and thus only one of themis included in a block ie inputs(ti)cap inputs(ts)neemptyand existb isin Bmain ti isin transactions(b) (∄b isin Bmain ts isintransactions(b) is indisputable given a consistent transactionledger)) and two different subsets of the monitors havemempooled either one of them We also have identified 27unseen transactions implying possible one-confirmationattack variant requiring the private mining (ie not ad-vertising the double-spending transaction to the network) in

5 10 15 20 25 30 35 40 45 500 of peers

0

005

01

015

02

025

Freq

uenc

y

BitcoinEthereum

Figure 16 Peer redundancy of block advertisement

14 Security and Communication Networks

Section 42 As for the countermeasure of such attacks bydeploying monitors [60] deployment of 8 monitors in thenetwork to detect the attacks would fail at most 27 out of 95times (sim30) assuming that those 27 unseen transactionswe have identified are initially advertised to the network

63 Potential Impact on Blockchain ApplicationsEthereum and EOS are the most widely used smart contractplatforms fostering various decentralized applications Bit-coin which lacks the capability of executing complex smartcontract codes is also recently utilized to execute smartcontracts for decentralized applications [50 61] Eventhough our work focuses on the fundamental blockchainmechanisms in terms of transactionblock production andpropagation the impact of our findings on decentralizedapplications can be foresighted

According to our blockchain fork results (Section 41)the lack of selfish mining in the real world was speculated bya very low stale block rate of Bitcoin network and prevalenceof nonearliest block endorsement by Ethereum miners Asprofitability of selfish mining encourages miners to behavein a way of producing more blockchain forks the perfor-mance degradation is proportionate to the number of minerswho adopt the selfish mining strategy the key performancemetrics affecting the blockchain application performance

such as node response time or block delivery time are shownto be noticeably degraded due to the selfish mining [62] Forexample decentralized identities issued or revoked on suchblockchains [63 64] cannot be responsively finalized due toinflated blockchain forks Our results show that the selfishmining is not prevalent in the real world thus the appli-cation performance impact is overrated even though it istheoretically shown that miners have every reason to beselfish [38] As for EOS we reported cases where a sequenceof (up to 12) blocks being stale are often observed in suc-cessive mining of two BPs however the rate is too low (ie004) to impact the performance of applications (Section32)

Transaction arrival processes being LRD (Section 51)pose a technical challenge in provisioning transactionprocessing scalability especially for Layer-2 blockchain ap-plication solutions [65 66] For example Layer-2 rollupsolutions require transaction relays which aggregate indi-vidual user transactions of a given blockchain applicationdeployed in the network often without a priori knowledge ofnetwork load One way of solving the problem is a properprioritization of transactions based on the applicationcontext

Lastly blockchain network partitioning can be thebiggest concern for blockchain service providers We ob-served that the increased numbers of peer connections inblockchain reference implementations effectively provide ahigher degree of information redundancy (Section 52)However increased number of peer connections can beexploitable for an attacker who has a denial-of-service attackvector or an invalid transaction initiated by a simple ap-plication bug can flood the network [45]

64 Limitation Our measurement study has several limi-tations First of all our results may only capture only a fewmonths of blockchain network operations In the meantimethe permissionless blockchain pieces of software are in activedevelopment for example Ethereum now utilizes the pooledtransaction delivery [67] instead of unsolicited transactiondelivery which was the only mode at the time of our

Table 10 Bitcoin disparately mempooled transactions

monitors mempooledti

monitors mempooledts

Transactioncount

7 1 26 (3824)6 2 14 (2059)5 3 10 (1471)4 4 5 (735)3 5 5 (735)2 6 3 (441)1 7 3 (441)5 1 1 (147)6 1 1 (147)

Sum 68 (10000)

Tincluded

Tstale

5 10 15 20 25 30 35 40 45 500 of peers

0

005

01

015

02

025

03Fr

eque

ncy

(a)

Tincluded

Tstale

0002004006008

01012014016

Freq

uenc

y

4030 500 10 20 of peers

(b)

Figure 17 Peer redundancy of transaction advertisement (a) Bitcoin (b) Ethereum

Security and Communication Networks 15

measurement Both cryptocurrency market values andblockchain network utilizations are rapidly increasing andthus miners are getting more motivated to optimize theirperformance for example Bitcoin fork probability has be-come far smaller than what is reported previously (seeSection 41)

Second the blockchain state information is not collected inour measurement Our analysis is performed based on onlyavailable information stored in block and transaction logs Wehave utilized an Ethereum archive node [44] to query historicalstate information (eg account balance or account nonce) inSection 42 However such proactive state replication is farmore complicated with EOS unless the full node is configuredto operate as a producing node and logging the state infor-mation thus EOS stale transactions could not be fully un-derstood without the missing EOS network state information

7 Related Work

71 Blockchain Data Analysis Historical transaction data ofBitcoin have often been studied for economic aspects such ascryptocurrency abuse [17] anti-money-laundering [18] andmonetary flow of businesses [19] However historicalblockchain data usually available from block explorer ser-vices are not sufficient for our research purpose

72 Blockchain Measurement Researchers have performedblockchain measurement studies to assess the degree ofdecentralization [20] to investigate demographic informa-tion of network nodes [34 68] to study mining pool be-havior [22] and to evaluate security of PoW blockchains [21]against known attacks such as double-spending attack [60]and selfish mining [37] Our work expands the under-standing of previous security evaluations with the keyfindings acquired from our large-scale transaction and blockmeasurement

73 Blockchain Attacks Partitioning attacks usually exploitvulnerable peer management mechanisms of Bitcoin [51]and Ethereum [52] Such attacks are also examined in thecontext of ISPrsquos BGP hijacking [53] and a stealthier variantrelieving the attacker from the risk of getting exposed [54]Cryptocurrency mining has been a popular subject inassessing the security of Bitcoin selfish mining [37] blockwithholding attack [36] and a mixed strategy [38] have beenstudied Double-spending attacks have been studied in thecontext of Bitcoin fast payments [60]

74 Block Explorer Services We have surveyed the popularblock explorer services of Bitcoin [5 10 12] Ethereum[10 13 16] and EOS [11 14 15] to see the availability ofinformation beyond what is recorded in the main chainblock data we have utilized in our study namely

(i) Stale blockstransactions no Bitcoin and EOS blockexplorers provide stale block information (A relatedstudy [36] has utilized a Bitcoin block explorer service[68] to retrieve stale blocks However the service has

been terminated in March 2019) All Ethereum blockexplorers provide only reported stale blocks (ie uncleblocks [23]) (Ethereum provides incentives for unclestale blocks [44] so that miners include them in theirmined blocks for profit)No block explorers provide stale transaction infor-mation unless one is currently pooled

(ii) Blocktransaction arrival times all block explorersprovide block timestamps that are recorded in theblock headers not the actual times of arrival Ourblockchain fork and gap analysis require measuredblock arrival times at multiple locations All blockexplorers show transaction timestamps identical to theblock timestamp to which the transactions belong(Recent Bitcoin transactions have different timestampsthan the block timestamps in [4] while the timestampsare only at a granularity of one minute) [69 70]

8 Conclusion

We have measured transaction and block arrival events ofthe three permissionless blockchains We have devised anoble analysis model and analyzed completeness of ourblock and transaction logs Finally we have studied thediscrepancy in measured events and arrival characteristics toshare our key findings including a false universal assumptionof previous mining-related studies

Data Availability

e measurement data used to support the findings of thisstudy have not been made available because they containprivate information that can be used to identify individualblockchain nodes

Disclosure

is is an extended and revised version of a conference paperpresented in IEEE ICDCS 2021 [41]

Conflicts of Interest

e authors declare that they have no conflicts of interest

Acknowledgments

e authors would like to thank Seungwon Woo DaegeunYoon and Changhyun Lee for helping them with themeasurement instrumentation is work was supported byElectronics and Telecommunications Research Institute(ETRI) grant funded by the Korean Government (21ZR1300Research on Intelligent Cyber Security and Trust Infra)

References

[1] S Nakamoto ldquoBitcoin a peer-to-peer electronic cash systemrdquo2019

[2] V Buterin ldquoEthereum white paperrdquo 2013 httpsethereumorgenwhitepaper

[3] Monero ldquoMonerordquo 2020 httpswebgetmoneroorg

16 Security and Communication Networks

[4] bitcoincashorg httpswwwbitcoincashorg[5] Blockchaincom httpswwwblockchaincom[6] Ripple ldquoXRP e best digital asset for global paymentsrdquo

2020 httpsripplecomxrp[7] I Foundation ldquoIotardquo 2021 httpswwwiotaorg[8] ldquoEosiordquo 2020 httpseosio[9] S Orsquoneal ldquoEos proves yet again that decentralization is not its

priorityrdquo 2018 httpscointelegraphcomnewseos-proves-yet-again-that-decentralization-is-not-its-priority

[10] Blockchair httpsblockchaircom[11] Bloksio httpsbloksio[12] BTCcom ldquoBitcoin block explorerrdquo 2021 httpsbtccom[13] Ethereum block explorer httpsethbtccom[14] eosflareio Eos block explorer httpseosflareio[15] EOSPark ldquoEos block explorerrdquo 2021 httpseosparkcom[16] Etherscan Ethereum explorer httpsetherscanio[17] S Lee C Yoon and H Kang ldquoCybercriminal minds An

investigative study of cryptocurrency abuses in the dark webrdquoin Proceedings of the Network and Distributed System SecuritySymposium pp 1ndash15 Internet Society San Diego CA USAFebruary 2019

[18] MMoser R Bohme and D Breuker ldquoAn inquiry into moneylaundering tools in the bitcoin ecosystemrdquo in Proceedings ofthe 2013 APWG eCrime Researchers summit pp 1ndash14 IEEESan Francisco CA USA September 2013

[19] M Lischke and B Fabian ldquoAnalyzing the bitcoin network thefirst four yearsrdquo Future Internet vol 8 no 1 2016

[20] A E Gencer S Basu I Eyal R V Renesse and E G SirerldquoDecentralization in bitcoin and ethereum networksrdquo inProceedings of the International Conference On FinancialCryptography and Data Security pp 439ndash457 SpringerNieuwport Curaccedilao February 2018

[21] A Gervais G O Karame KWust V Glykantzis H Ritzdorfand S Capkun ldquoOn the security and performance of proof ofwork blockchainsrdquo in Proceedings Of the 2016 ACM SIGSACConference on Computer and Communications Securitypp 3ndash16 Vienna Austria October 2016

[22] C Wang X Chu and Q Yang ldquoMeasurement and analysis ofthe bitcoin networks a view from mining poolsrdquo 2019httpsarxivorgabs190207549

[23] G Wood ldquoEthereum A secure decentralised generalisedtransaction ledgerrdquo Ethereum Project Yellow Paper vol 1512014

[24] ldquoTransactions protocol eosio developer docsrdquo 2018 httpsdeveloperseosiowelcomev20protocoltransactions_protocol

[25] Y Sompolinsky and A Zohar ldquoSecure high-rate transactionprocessing in bitcoinrdquo in Proceedings of the InternationalConference On Financial Cryptography and Data Securitypp 507ndash527 Springer San Juan PR USA January 2015

[26] Blockone ldquoConsensus protocolrdquo 2018 httpsdeveloperseosiowelcomev20protocolconsensus_protocol

[27] A Gervais H Ritzdorf G O Karame and S CapkunldquoTampering with the delivery of blocks and transactions inbitcoinrdquo in Proceedings Of the 22nd ACM SIGSAC ConferenceOn Computer and Communications Security pp 692ndash705Denver CO USA October 2015

[28] ldquoGithub Bit coinrdquo 2020 httpsgithubcombitcoinbitcoin[29] G Ethereum ldquoGo ethereumrdquo 2020 httpsgithubcom

ethereumgo-ethereum[30] Google ldquoGoogle cloudrdquo 2021 httpscloudgooglecom[31] ldquoHow to replay from a snapshotrdquo 2018 httpsdeveloperseos

iomanualseoslatestnodeosreplayshow-to-replay-from-a-snapshot

[32] C Decker and R Wattenhofer ldquoInformation propagation inthe bitcoin networkrdquo in Proceedings of the IEEE P2P 2013Proceedings pp 1ndash10 IEEE Trento Italy September 2013

[33] ldquoEthereum uncle raterdquo 2020 httpsychartscomindicatorsethereum_uncle_rate

[34] J A Donet C P Sola and J H Joancomartı ldquoe bitcoin p2pnetworkrdquo in Proceedings of the International Conference OnFinancial Cryptography and Data Security pp 87ndash102Springer Christ Church Barbados March 2014

[35] G S Davies ldquoBit-booster - offline commit graph drawingtoolrdquo 2016 httpbit-boostercomgraphhtml

[36] N T Courtois and L Bahack ldquoOn subversive miner strategiesand block withholding attack in bitcoin digital currencyrdquo2014 httpsarxivorgabs14021718

[37] I Eyal and E G Sirer ldquoMajority is not enough bitcoin miningis vulnerablerdquo in Proceedings of the International Conferenceon Financial Cryptography and Data Security pp 436ndash454Springer Christ Church Barbados March 2014

[38] Y Kwon D Kim Y Son E Vasserman and Y Kim ldquoBeselfish and avoid dilemmas fork after withholding (faw) at-tacks on bitcoinrdquo in Proceedings Of the 2017 ACM SIGSACConference On Computer and Communications Securitypp 195ndash209 Abu Dhabi UAE April 2017

[39] B Research ldquoDecentralisation governance and eos - a lostcaserdquo 2020 httpsresearchbinancecomenanalysiseos-governance

[40] B Wiki ldquoIrreversible transactions - finney attackrdquo 2012httpsenbitcoinitwikiIrreversible_Transactions∖Finney_attack

[41] J Poon and T Dryja ldquoe bitcoin lightning network scalableoff-chain instant paymentsrdquo 2016

[42] M Bartoletti and L Pompianu ldquoAn analysis of bitcoin op_return metadatardquo in Proceedings of the International Con-ference On Financial Cryptography and Data Securitypp 218ndash230 Springer Sliema Malta April 2017

[43] ldquoReplace by feerdquo 2018 httpsenbitcoinitwikiReplace_by_fee

[44] E Foundation ldquoNode and clientsrdquo 2020 httpsethereumorgendevelopersdocsnodes-and-clients

[45] H Heo and S Shin ldquoBehind block explorers public block-chain measurement and security implicationrdquo in Proceedingsof the 41th IEEE International Conference On DistributedComputing Systems IEEE Washington DC USA In pressWashington DC USA July 2021

[46] R Bowden H P Keeler A E Krzesinski and P G TaylorldquoBlock arrivals in the bitcoin blockchainrdquo 2018 httpsarxivorgabs180107447

[47] M E Crovella and A Bestavros ldquoExplaining world wide webtraffic self-similarityrdquo Technical Report Citeseer PrincetonNJ USA 1995

[48] H Zhang Y Shu and O Yang ldquoEstimation of hurst pa-rameter by variance-time plotsrdquo in Proceedings of the 1997IEEE Pacific Rim Conference on Communications Computersand Signal Processing PACRIM 10 Years Networkingthe Pacific Rim 1987-1997 IEEE Victoria BC CanadaAugust 1997

[49] A Feldmann ldquoCharacteristics of TCP connection arrivalsrdquo inSelf-Similar Network Traffic and Performance EvaluationK Park andWWillinger Eds pp 367ndash399Wiley HobokenNJ USA 2000

[50] RSK ldquoRSKrdquo 2021 httpswwwrskco[51] E Heilman A Kendler A Zohar and S Goldberg ldquoEclipse

attacks on bitcoinrsquos peer-to-peer networkrdquo in Proceedings of

Security and Communication Networks 17

the 24th USENIX Security Symposium pp 129ndash144 Wash-ington DC USA April 2015

[52] Y Marcus E Heilman and S Goldberg ldquoLow-resourceeclipse attacks on ethereumrsquos peer-to-peer networkrdquo IACRCryptology vol 2018 p 236 2018

[53] M Apostolaki A Zohar and L Vanbever ldquoHijacking bitcoinRouting attacks on cryptocurrenciesrdquo in Proceedings of the2017 IEEE Symposium On Security and Privacy (SP)pp 375ndash392 IEEE San Jose CA USA May 2017

[54] M Tran I Choi G J Moon A V Vu and M S Kang ldquoAstealthier partitioning attack against bitcoin peer-to-peernetworkrdquo in Proceedings of the IEEE Symposium On Securityand Privacy (SampP) San Francisco CA USA May 2020

[55] B I Proposal ldquoBip 0152rdquo 2016 httpsenbitcoinitwikiBIP_0152

[56] B Core ldquoBitcoin Core Version 01901 Release Noterdquo 2016httpsbitcoinorgenreleasev01901

[57] ldquoGeth v190rdquo 2019 httpsblogethereumorg20190710geth-v1-9-0

[58] ldquoProtocol documentationrdquo 2016 httpsenbitcoinitwikiProtocoltext_documentation

[59] C Feng and J Niu ldquoSelfish mining in ethereumrdquo in Pro-ceedings of the 2019 IEEE 39th International Conference OnDistributed Computing Systems (ICDCS) pp 1306ndash1316IEEE Dallas TX USA July 2019

[60] G O Karame E Androulaki and S Capkun ldquoDouble-spending fast payments in bitcoinrdquo in Proceedings of the 2012ACM Conference on Computer and Communications Securitypp 906ndash917 Raleigh NC USA October 2012

[61] P Das L Eckey T Frassetto et al ldquoFastkitten practical smartcontracts on bitcoinrdquo in Proceedimgs of the 28th USENIXSecurity Symposium (USENIX Security 19) pp 801ndash818Santa Clara CA USA August 2019

[62] S G Motlagh J Misic and V B Misic ldquoe impact of selfishmining on bitcoin network performancerdquo IEEE Transactionson Network Science and Engineering vol 8 no 1 pp 724ndash7352021

[63] A Muhle A Gruner T Gayvoronskaya and C Meinel ldquoAsurvey on essential components of a self-sovereign identityrdquoComputer Science Review vol 30 pp 80ndash86 2018

[64] M Toorani and C Gehrmann ldquoA decentralized dynamic pkibased on blockchainrdquo in Proceedings Of the 36th Annual ACMSymposium On Applied Computing pp 1646ndash1655 GwangjuKorea March 2021

[65] E foundation ldquoOptimistic-rollupsrdquo 2021 httpsdocsethhubioethereum-roadmaplayer-2-scalingoptimistictext_rollups

[66] ldquoZk-rollupsrdquo 2021 httpsdocsethhubioethereum-roadmaplayer-2-scalingzk-rollups

[67] E foundation ldquoEthereumwire protocolrdquo 2019 httpsgithubcomethereumdevp2pblobmastercapseth

[68] S K Kim Z Ma S Murali J Mason A Miller andM BaileyldquoMeasuring ethereum network peersrdquo in Proceedings of theInternet Measurement Conference 2018 pp 91ndash104 BostonMA USA October 2018

[69] Symmetricom ldquoDelivering sub-microsecond accurate time tolinux applications around the worldrdquo 2012 httpwwwchronoscoukfilespdfswpsWP_AccurateTimeForLinuxApplicationspdf

[70] Ycharts ldquoBlocktrail blockchain data query service (termi-nated)rdquo 2019 httpsblocktrailcom

18 Security and Communication Networks

temporary denial of blocks (reported in [27] and fixed byrecommending three concurrent download sessions in [55])let attackers successfully partition the node without eclipsingall peer connections [53] A simple countermeasure of in-creasing the number of peer connections on the other handis applied to the reference public blockchain implementa-tions [56 57] to inflate attack complexity

We investigate the degree of a peerrsquos advertisementredundancy on newly generated blocks and transactions toevaluate the efficacy of partitioning attacks and the coun-termeasure of increasing the number of peer connectionsFigure 16 shows how redundantly newly generated blockinformation is offered by peers Bitcoin nodes have main-tained sim43 peer connections that is 8 outbound and ad-ditional 35 inbound connections on average and Ethereumnodes record all 50 peer connections established during theentire observation period

For each newly generated block one-third of peersadvertised the block header to our Bitcoin node and morethan 90 of Ethereum peers signaled availability of theblocks In consequence successfully partitioning a noderequires compromise of peers proportional to the totalnumber of peer connections Increasing the number of peerconnections will burden the attacker linearly as expected

Figure 17 shows how redundantly the newly generatedtransaction information is offered by peers While one out ofthree Bitcoin peers also advertises new transactions viaINVENTORYmessage [58] half of the Ethereum peers havesent new transactions to our node in average Bitcoin andEthereum blocks are advertised with the block header(rather than the direct delivery of all block contents) Bitcointransactions are also advertised with INVENTORY messagebefore the whole contents are transferred HoweverEthereum transaction data that is the entire contents aredirectly sent by peers (Ethereum now has a pooled trans-action delivery model in its newer ETH64 protocol [30])We also find that there are cases with much less advertisedtransactions and have identified that they are indeed mostlystale ones stale transactions are mostly due to conflict (seeSection 42) and the nodes that already queued the conflicttransaction will not relay the stale one

6 Discussion

61 Implication on Mining Attacks Cryptocurrency mininghas been a popular subject in assessing the security ofBitcoin selfish mining [37] block withholding attack [36]and a mixed strategy [38] have been studied Although it isshown that selfish behavior in mining is always moreprofitable than being honest without need for a mutualagreement of not attacking each other [38] we find thatselfish mining is not the preferred strategy All selfish miningstrategies will result in blockchain forks but we observe avery low fork probability (ie 004) for Bitcoin On theother hand selfish mining on Ethereum has been studiedonly recently to unanimously claim that selfish mining isalso profitable for Ethereum miners however it is lessprofitable than Bitcoin due to its uncle reward system [59]Our result in Section 4 shows that a majority of Ethereum

miners choose to add to their own produced blocks over theearliest propagated blocks How does this affect the selfishmining strategy

e selfish mining strategy assumes a parameter c whichdefines the fraction of honest minersrsquo mines on the attackerrsquosfork branch (e parameter comes into play in case (f ) of[27]) If the attacking pool has a network-wise superiorposition in block propagation (ie cgt 05) the selfishmining strategy is profitable for pools with proportionalmining power αgt 25 [37] Absolute network inferiority(ie c 0 due to a defensive mining strategy such as the onepresented in Section 41) increases the required miningpower to 33 the 33 mining power appears to be sig-nificantly harder to achieve in the real world [20]

As for the FAW (Fork-After-Withholding) attackstrategy [38] the network capability parameter C defines theprobability that an attackerrsquos FPoW (Full Proof-of-Work)block (during infiltration mining) is selected as a main chainblock C affects both the attack reward and whether theminerrsquos dilemma holds or not in the mutual attacking gameAs an example case (Section 9 of [38]) of a two-pool gamebetween F2Pool and BitFury the absolute network inferi-ority drops C from 0914 to 03 to make it a dilemmatic gameagain Unfortunately minersrsquo own block preferences cannotbe directly transferred to a single parameter of c or C it callsfor a model change from previous mining studies

62 Conflict Transactions and Double-Spending AttacksDouble-spending attacks have been studied in the context ofBitcoin fast payments where zero or only one confirmation isrequired to complete an offline merchandise transaction[60] real-world cases where two conflict transactions dis-parately arrive at different measurement locations mayimply such attacks Table 10 shows the cases where twotransactions are in conflict (and thus only one of themis included in a block ie inputs(ti)cap inputs(ts)neemptyand existb isin Bmain ti isin transactions(b) (∄b isin Bmain ts isintransactions(b) is indisputable given a consistent transactionledger)) and two different subsets of the monitors havemempooled either one of them We also have identified 27unseen transactions implying possible one-confirmationattack variant requiring the private mining (ie not ad-vertising the double-spending transaction to the network) in

5 10 15 20 25 30 35 40 45 500 of peers

0

005

01

015

02

025

Freq

uenc

y

BitcoinEthereum

Figure 16 Peer redundancy of block advertisement

14 Security and Communication Networks

Section 42 As for the countermeasure of such attacks bydeploying monitors [60] deployment of 8 monitors in thenetwork to detect the attacks would fail at most 27 out of 95times (sim30) assuming that those 27 unseen transactionswe have identified are initially advertised to the network

63 Potential Impact on Blockchain ApplicationsEthereum and EOS are the most widely used smart contractplatforms fostering various decentralized applications Bit-coin which lacks the capability of executing complex smartcontract codes is also recently utilized to execute smartcontracts for decentralized applications [50 61] Eventhough our work focuses on the fundamental blockchainmechanisms in terms of transactionblock production andpropagation the impact of our findings on decentralizedapplications can be foresighted

According to our blockchain fork results (Section 41)the lack of selfish mining in the real world was speculated bya very low stale block rate of Bitcoin network and prevalenceof nonearliest block endorsement by Ethereum miners Asprofitability of selfish mining encourages miners to behavein a way of producing more blockchain forks the perfor-mance degradation is proportionate to the number of minerswho adopt the selfish mining strategy the key performancemetrics affecting the blockchain application performance

such as node response time or block delivery time are shownto be noticeably degraded due to the selfish mining [62] Forexample decentralized identities issued or revoked on suchblockchains [63 64] cannot be responsively finalized due toinflated blockchain forks Our results show that the selfishmining is not prevalent in the real world thus the appli-cation performance impact is overrated even though it istheoretically shown that miners have every reason to beselfish [38] As for EOS we reported cases where a sequenceof (up to 12) blocks being stale are often observed in suc-cessive mining of two BPs however the rate is too low (ie004) to impact the performance of applications (Section32)

Transaction arrival processes being LRD (Section 51)pose a technical challenge in provisioning transactionprocessing scalability especially for Layer-2 blockchain ap-plication solutions [65 66] For example Layer-2 rollupsolutions require transaction relays which aggregate indi-vidual user transactions of a given blockchain applicationdeployed in the network often without a priori knowledge ofnetwork load One way of solving the problem is a properprioritization of transactions based on the applicationcontext

Lastly blockchain network partitioning can be thebiggest concern for blockchain service providers We ob-served that the increased numbers of peer connections inblockchain reference implementations effectively provide ahigher degree of information redundancy (Section 52)However increased number of peer connections can beexploitable for an attacker who has a denial-of-service attackvector or an invalid transaction initiated by a simple ap-plication bug can flood the network [45]

64 Limitation Our measurement study has several limi-tations First of all our results may only capture only a fewmonths of blockchain network operations In the meantimethe permissionless blockchain pieces of software are in activedevelopment for example Ethereum now utilizes the pooledtransaction delivery [67] instead of unsolicited transactiondelivery which was the only mode at the time of our

Table 10 Bitcoin disparately mempooled transactions

monitors mempooledti

monitors mempooledts

Transactioncount

7 1 26 (3824)6 2 14 (2059)5 3 10 (1471)4 4 5 (735)3 5 5 (735)2 6 3 (441)1 7 3 (441)5 1 1 (147)6 1 1 (147)

Sum 68 (10000)

Tincluded

Tstale

5 10 15 20 25 30 35 40 45 500 of peers

0

005

01

015

02

025

03Fr

eque

ncy

(a)

Tincluded

Tstale

0002004006008

01012014016

Freq

uenc

y

4030 500 10 20 of peers

(b)

Figure 17 Peer redundancy of transaction advertisement (a) Bitcoin (b) Ethereum

Security and Communication Networks 15

measurement Both cryptocurrency market values andblockchain network utilizations are rapidly increasing andthus miners are getting more motivated to optimize theirperformance for example Bitcoin fork probability has be-come far smaller than what is reported previously (seeSection 41)

Second the blockchain state information is not collected inour measurement Our analysis is performed based on onlyavailable information stored in block and transaction logs Wehave utilized an Ethereum archive node [44] to query historicalstate information (eg account balance or account nonce) inSection 42 However such proactive state replication is farmore complicated with EOS unless the full node is configuredto operate as a producing node and logging the state infor-mation thus EOS stale transactions could not be fully un-derstood without the missing EOS network state information

7 Related Work

71 Blockchain Data Analysis Historical transaction data ofBitcoin have often been studied for economic aspects such ascryptocurrency abuse [17] anti-money-laundering [18] andmonetary flow of businesses [19] However historicalblockchain data usually available from block explorer ser-vices are not sufficient for our research purpose

72 Blockchain Measurement Researchers have performedblockchain measurement studies to assess the degree ofdecentralization [20] to investigate demographic informa-tion of network nodes [34 68] to study mining pool be-havior [22] and to evaluate security of PoW blockchains [21]against known attacks such as double-spending attack [60]and selfish mining [37] Our work expands the under-standing of previous security evaluations with the keyfindings acquired from our large-scale transaction and blockmeasurement

73 Blockchain Attacks Partitioning attacks usually exploitvulnerable peer management mechanisms of Bitcoin [51]and Ethereum [52] Such attacks are also examined in thecontext of ISPrsquos BGP hijacking [53] and a stealthier variantrelieving the attacker from the risk of getting exposed [54]Cryptocurrency mining has been a popular subject inassessing the security of Bitcoin selfish mining [37] blockwithholding attack [36] and a mixed strategy [38] have beenstudied Double-spending attacks have been studied in thecontext of Bitcoin fast payments [60]

74 Block Explorer Services We have surveyed the popularblock explorer services of Bitcoin [5 10 12] Ethereum[10 13 16] and EOS [11 14 15] to see the availability ofinformation beyond what is recorded in the main chainblock data we have utilized in our study namely

(i) Stale blockstransactions no Bitcoin and EOS blockexplorers provide stale block information (A relatedstudy [36] has utilized a Bitcoin block explorer service[68] to retrieve stale blocks However the service has

been terminated in March 2019) All Ethereum blockexplorers provide only reported stale blocks (ie uncleblocks [23]) (Ethereum provides incentives for unclestale blocks [44] so that miners include them in theirmined blocks for profit)No block explorers provide stale transaction infor-mation unless one is currently pooled

(ii) Blocktransaction arrival times all block explorersprovide block timestamps that are recorded in theblock headers not the actual times of arrival Ourblockchain fork and gap analysis require measuredblock arrival times at multiple locations All blockexplorers show transaction timestamps identical to theblock timestamp to which the transactions belong(Recent Bitcoin transactions have different timestampsthan the block timestamps in [4] while the timestampsare only at a granularity of one minute) [69 70]

8 Conclusion

We have measured transaction and block arrival events ofthe three permissionless blockchains We have devised anoble analysis model and analyzed completeness of ourblock and transaction logs Finally we have studied thediscrepancy in measured events and arrival characteristics toshare our key findings including a false universal assumptionof previous mining-related studies

Data Availability

e measurement data used to support the findings of thisstudy have not been made available because they containprivate information that can be used to identify individualblockchain nodes

Disclosure

is is an extended and revised version of a conference paperpresented in IEEE ICDCS 2021 [41]

Conflicts of Interest

e authors declare that they have no conflicts of interest

Acknowledgments

e authors would like to thank Seungwon Woo DaegeunYoon and Changhyun Lee for helping them with themeasurement instrumentation is work was supported byElectronics and Telecommunications Research Institute(ETRI) grant funded by the Korean Government (21ZR1300Research on Intelligent Cyber Security and Trust Infra)

References

[1] S Nakamoto ldquoBitcoin a peer-to-peer electronic cash systemrdquo2019

[2] V Buterin ldquoEthereum white paperrdquo 2013 httpsethereumorgenwhitepaper

[3] Monero ldquoMonerordquo 2020 httpswebgetmoneroorg

16 Security and Communication Networks

[4] bitcoincashorg httpswwwbitcoincashorg[5] Blockchaincom httpswwwblockchaincom[6] Ripple ldquoXRP e best digital asset for global paymentsrdquo

2020 httpsripplecomxrp[7] I Foundation ldquoIotardquo 2021 httpswwwiotaorg[8] ldquoEosiordquo 2020 httpseosio[9] S Orsquoneal ldquoEos proves yet again that decentralization is not its

priorityrdquo 2018 httpscointelegraphcomnewseos-proves-yet-again-that-decentralization-is-not-its-priority

[10] Blockchair httpsblockchaircom[11] Bloksio httpsbloksio[12] BTCcom ldquoBitcoin block explorerrdquo 2021 httpsbtccom[13] Ethereum block explorer httpsethbtccom[14] eosflareio Eos block explorer httpseosflareio[15] EOSPark ldquoEos block explorerrdquo 2021 httpseosparkcom[16] Etherscan Ethereum explorer httpsetherscanio[17] S Lee C Yoon and H Kang ldquoCybercriminal minds An

investigative study of cryptocurrency abuses in the dark webrdquoin Proceedings of the Network and Distributed System SecuritySymposium pp 1ndash15 Internet Society San Diego CA USAFebruary 2019

[18] MMoser R Bohme and D Breuker ldquoAn inquiry into moneylaundering tools in the bitcoin ecosystemrdquo in Proceedings ofthe 2013 APWG eCrime Researchers summit pp 1ndash14 IEEESan Francisco CA USA September 2013

[19] M Lischke and B Fabian ldquoAnalyzing the bitcoin network thefirst four yearsrdquo Future Internet vol 8 no 1 2016

[20] A E Gencer S Basu I Eyal R V Renesse and E G SirerldquoDecentralization in bitcoin and ethereum networksrdquo inProceedings of the International Conference On FinancialCryptography and Data Security pp 439ndash457 SpringerNieuwport Curaccedilao February 2018

[21] A Gervais G O Karame KWust V Glykantzis H Ritzdorfand S Capkun ldquoOn the security and performance of proof ofwork blockchainsrdquo in Proceedings Of the 2016 ACM SIGSACConference on Computer and Communications Securitypp 3ndash16 Vienna Austria October 2016

[22] C Wang X Chu and Q Yang ldquoMeasurement and analysis ofthe bitcoin networks a view from mining poolsrdquo 2019httpsarxivorgabs190207549

[23] G Wood ldquoEthereum A secure decentralised generalisedtransaction ledgerrdquo Ethereum Project Yellow Paper vol 1512014

[24] ldquoTransactions protocol eosio developer docsrdquo 2018 httpsdeveloperseosiowelcomev20protocoltransactions_protocol

[25] Y Sompolinsky and A Zohar ldquoSecure high-rate transactionprocessing in bitcoinrdquo in Proceedings of the InternationalConference On Financial Cryptography and Data Securitypp 507ndash527 Springer San Juan PR USA January 2015

[26] Blockone ldquoConsensus protocolrdquo 2018 httpsdeveloperseosiowelcomev20protocolconsensus_protocol

[27] A Gervais H Ritzdorf G O Karame and S CapkunldquoTampering with the delivery of blocks and transactions inbitcoinrdquo in Proceedings Of the 22nd ACM SIGSAC ConferenceOn Computer and Communications Security pp 692ndash705Denver CO USA October 2015

[28] ldquoGithub Bit coinrdquo 2020 httpsgithubcombitcoinbitcoin[29] G Ethereum ldquoGo ethereumrdquo 2020 httpsgithubcom

ethereumgo-ethereum[30] Google ldquoGoogle cloudrdquo 2021 httpscloudgooglecom[31] ldquoHow to replay from a snapshotrdquo 2018 httpsdeveloperseos

iomanualseoslatestnodeosreplayshow-to-replay-from-a-snapshot

[32] C Decker and R Wattenhofer ldquoInformation propagation inthe bitcoin networkrdquo in Proceedings of the IEEE P2P 2013Proceedings pp 1ndash10 IEEE Trento Italy September 2013

[33] ldquoEthereum uncle raterdquo 2020 httpsychartscomindicatorsethereum_uncle_rate

[34] J A Donet C P Sola and J H Joancomartı ldquoe bitcoin p2pnetworkrdquo in Proceedings of the International Conference OnFinancial Cryptography and Data Security pp 87ndash102Springer Christ Church Barbados March 2014

[35] G S Davies ldquoBit-booster - offline commit graph drawingtoolrdquo 2016 httpbit-boostercomgraphhtml

[36] N T Courtois and L Bahack ldquoOn subversive miner strategiesand block withholding attack in bitcoin digital currencyrdquo2014 httpsarxivorgabs14021718

[37] I Eyal and E G Sirer ldquoMajority is not enough bitcoin miningis vulnerablerdquo in Proceedings of the International Conferenceon Financial Cryptography and Data Security pp 436ndash454Springer Christ Church Barbados March 2014

[38] Y Kwon D Kim Y Son E Vasserman and Y Kim ldquoBeselfish and avoid dilemmas fork after withholding (faw) at-tacks on bitcoinrdquo in Proceedings Of the 2017 ACM SIGSACConference On Computer and Communications Securitypp 195ndash209 Abu Dhabi UAE April 2017

[39] B Research ldquoDecentralisation governance and eos - a lostcaserdquo 2020 httpsresearchbinancecomenanalysiseos-governance

[40] B Wiki ldquoIrreversible transactions - finney attackrdquo 2012httpsenbitcoinitwikiIrreversible_Transactions∖Finney_attack

[41] J Poon and T Dryja ldquoe bitcoin lightning network scalableoff-chain instant paymentsrdquo 2016

[42] M Bartoletti and L Pompianu ldquoAn analysis of bitcoin op_return metadatardquo in Proceedings of the International Con-ference On Financial Cryptography and Data Securitypp 218ndash230 Springer Sliema Malta April 2017

[43] ldquoReplace by feerdquo 2018 httpsenbitcoinitwikiReplace_by_fee

[44] E Foundation ldquoNode and clientsrdquo 2020 httpsethereumorgendevelopersdocsnodes-and-clients

[45] H Heo and S Shin ldquoBehind block explorers public block-chain measurement and security implicationrdquo in Proceedingsof the 41th IEEE International Conference On DistributedComputing Systems IEEE Washington DC USA In pressWashington DC USA July 2021

[46] R Bowden H P Keeler A E Krzesinski and P G TaylorldquoBlock arrivals in the bitcoin blockchainrdquo 2018 httpsarxivorgabs180107447

[47] M E Crovella and A Bestavros ldquoExplaining world wide webtraffic self-similarityrdquo Technical Report Citeseer PrincetonNJ USA 1995

[48] H Zhang Y Shu and O Yang ldquoEstimation of hurst pa-rameter by variance-time plotsrdquo in Proceedings of the 1997IEEE Pacific Rim Conference on Communications Computersand Signal Processing PACRIM 10 Years Networkingthe Pacific Rim 1987-1997 IEEE Victoria BC CanadaAugust 1997

[49] A Feldmann ldquoCharacteristics of TCP connection arrivalsrdquo inSelf-Similar Network Traffic and Performance EvaluationK Park andWWillinger Eds pp 367ndash399Wiley HobokenNJ USA 2000

[50] RSK ldquoRSKrdquo 2021 httpswwwrskco[51] E Heilman A Kendler A Zohar and S Goldberg ldquoEclipse

attacks on bitcoinrsquos peer-to-peer networkrdquo in Proceedings of

Security and Communication Networks 17

the 24th USENIX Security Symposium pp 129ndash144 Wash-ington DC USA April 2015

[52] Y Marcus E Heilman and S Goldberg ldquoLow-resourceeclipse attacks on ethereumrsquos peer-to-peer networkrdquo IACRCryptology vol 2018 p 236 2018

[53] M Apostolaki A Zohar and L Vanbever ldquoHijacking bitcoinRouting attacks on cryptocurrenciesrdquo in Proceedings of the2017 IEEE Symposium On Security and Privacy (SP)pp 375ndash392 IEEE San Jose CA USA May 2017

[54] M Tran I Choi G J Moon A V Vu and M S Kang ldquoAstealthier partitioning attack against bitcoin peer-to-peernetworkrdquo in Proceedings of the IEEE Symposium On Securityand Privacy (SampP) San Francisco CA USA May 2020

[55] B I Proposal ldquoBip 0152rdquo 2016 httpsenbitcoinitwikiBIP_0152

[56] B Core ldquoBitcoin Core Version 01901 Release Noterdquo 2016httpsbitcoinorgenreleasev01901

[57] ldquoGeth v190rdquo 2019 httpsblogethereumorg20190710geth-v1-9-0

[58] ldquoProtocol documentationrdquo 2016 httpsenbitcoinitwikiProtocoltext_documentation

[59] C Feng and J Niu ldquoSelfish mining in ethereumrdquo in Pro-ceedings of the 2019 IEEE 39th International Conference OnDistributed Computing Systems (ICDCS) pp 1306ndash1316IEEE Dallas TX USA July 2019

[60] G O Karame E Androulaki and S Capkun ldquoDouble-spending fast payments in bitcoinrdquo in Proceedings of the 2012ACM Conference on Computer and Communications Securitypp 906ndash917 Raleigh NC USA October 2012

[61] P Das L Eckey T Frassetto et al ldquoFastkitten practical smartcontracts on bitcoinrdquo in Proceedimgs of the 28th USENIXSecurity Symposium (USENIX Security 19) pp 801ndash818Santa Clara CA USA August 2019

[62] S G Motlagh J Misic and V B Misic ldquoe impact of selfishmining on bitcoin network performancerdquo IEEE Transactionson Network Science and Engineering vol 8 no 1 pp 724ndash7352021

[63] A Muhle A Gruner T Gayvoronskaya and C Meinel ldquoAsurvey on essential components of a self-sovereign identityrdquoComputer Science Review vol 30 pp 80ndash86 2018

[64] M Toorani and C Gehrmann ldquoA decentralized dynamic pkibased on blockchainrdquo in Proceedings Of the 36th Annual ACMSymposium On Applied Computing pp 1646ndash1655 GwangjuKorea March 2021

[65] E foundation ldquoOptimistic-rollupsrdquo 2021 httpsdocsethhubioethereum-roadmaplayer-2-scalingoptimistictext_rollups

[66] ldquoZk-rollupsrdquo 2021 httpsdocsethhubioethereum-roadmaplayer-2-scalingzk-rollups

[67] E foundation ldquoEthereumwire protocolrdquo 2019 httpsgithubcomethereumdevp2pblobmastercapseth

[68] S K Kim Z Ma S Murali J Mason A Miller andM BaileyldquoMeasuring ethereum network peersrdquo in Proceedings of theInternet Measurement Conference 2018 pp 91ndash104 BostonMA USA October 2018

[69] Symmetricom ldquoDelivering sub-microsecond accurate time tolinux applications around the worldrdquo 2012 httpwwwchronoscoukfilespdfswpsWP_AccurateTimeForLinuxApplicationspdf

[70] Ycharts ldquoBlocktrail blockchain data query service (termi-nated)rdquo 2019 httpsblocktrailcom

18 Security and Communication Networks

Section 42 As for the countermeasure of such attacks bydeploying monitors [60] deployment of 8 monitors in thenetwork to detect the attacks would fail at most 27 out of 95times (sim30) assuming that those 27 unseen transactionswe have identified are initially advertised to the network

63 Potential Impact on Blockchain ApplicationsEthereum and EOS are the most widely used smart contractplatforms fostering various decentralized applications Bit-coin which lacks the capability of executing complex smartcontract codes is also recently utilized to execute smartcontracts for decentralized applications [50 61] Eventhough our work focuses on the fundamental blockchainmechanisms in terms of transactionblock production andpropagation the impact of our findings on decentralizedapplications can be foresighted

According to our blockchain fork results (Section 41)the lack of selfish mining in the real world was speculated bya very low stale block rate of Bitcoin network and prevalenceof nonearliest block endorsement by Ethereum miners Asprofitability of selfish mining encourages miners to behavein a way of producing more blockchain forks the perfor-mance degradation is proportionate to the number of minerswho adopt the selfish mining strategy the key performancemetrics affecting the blockchain application performance

such as node response time or block delivery time are shownto be noticeably degraded due to the selfish mining [62] Forexample decentralized identities issued or revoked on suchblockchains [63 64] cannot be responsively finalized due toinflated blockchain forks Our results show that the selfishmining is not prevalent in the real world thus the appli-cation performance impact is overrated even though it istheoretically shown that miners have every reason to beselfish [38] As for EOS we reported cases where a sequenceof (up to 12) blocks being stale are often observed in suc-cessive mining of two BPs however the rate is too low (ie004) to impact the performance of applications (Section32)

Transaction arrival processes being LRD (Section 51)pose a technical challenge in provisioning transactionprocessing scalability especially for Layer-2 blockchain ap-plication solutions [65 66] For example Layer-2 rollupsolutions require transaction relays which aggregate indi-vidual user transactions of a given blockchain applicationdeployed in the network often without a priori knowledge ofnetwork load One way of solving the problem is a properprioritization of transactions based on the applicationcontext

Lastly blockchain network partitioning can be thebiggest concern for blockchain service providers We ob-served that the increased numbers of peer connections inblockchain reference implementations effectively provide ahigher degree of information redundancy (Section 52)However increased number of peer connections can beexploitable for an attacker who has a denial-of-service attackvector or an invalid transaction initiated by a simple ap-plication bug can flood the network [45]

64 Limitation Our measurement study has several limi-tations First of all our results may only capture only a fewmonths of blockchain network operations In the meantimethe permissionless blockchain pieces of software are in activedevelopment for example Ethereum now utilizes the pooledtransaction delivery [67] instead of unsolicited transactiondelivery which was the only mode at the time of our

Table 10 Bitcoin disparately mempooled transactions

monitors mempooledti

monitors mempooledts

Transactioncount

7 1 26 (3824)6 2 14 (2059)5 3 10 (1471)4 4 5 (735)3 5 5 (735)2 6 3 (441)1 7 3 (441)5 1 1 (147)6 1 1 (147)

Sum 68 (10000)

Tincluded

Tstale

5 10 15 20 25 30 35 40 45 500 of peers

0

005

01

015

02

025

03Fr

eque

ncy

(a)

Tincluded

Tstale

0002004006008

01012014016

Freq

uenc

y

4030 500 10 20 of peers

(b)

Figure 17 Peer redundancy of transaction advertisement (a) Bitcoin (b) Ethereum

Security and Communication Networks 15

measurement Both cryptocurrency market values andblockchain network utilizations are rapidly increasing andthus miners are getting more motivated to optimize theirperformance for example Bitcoin fork probability has be-come far smaller than what is reported previously (seeSection 41)

Second the blockchain state information is not collected inour measurement Our analysis is performed based on onlyavailable information stored in block and transaction logs Wehave utilized an Ethereum archive node [44] to query historicalstate information (eg account balance or account nonce) inSection 42 However such proactive state replication is farmore complicated with EOS unless the full node is configuredto operate as a producing node and logging the state infor-mation thus EOS stale transactions could not be fully un-derstood without the missing EOS network state information

7 Related Work

71 Blockchain Data Analysis Historical transaction data ofBitcoin have often been studied for economic aspects such ascryptocurrency abuse [17] anti-money-laundering [18] andmonetary flow of businesses [19] However historicalblockchain data usually available from block explorer ser-vices are not sufficient for our research purpose

72 Blockchain Measurement Researchers have performedblockchain measurement studies to assess the degree ofdecentralization [20] to investigate demographic informa-tion of network nodes [34 68] to study mining pool be-havior [22] and to evaluate security of PoW blockchains [21]against known attacks such as double-spending attack [60]and selfish mining [37] Our work expands the under-standing of previous security evaluations with the keyfindings acquired from our large-scale transaction and blockmeasurement

73 Blockchain Attacks Partitioning attacks usually exploitvulnerable peer management mechanisms of Bitcoin [51]and Ethereum [52] Such attacks are also examined in thecontext of ISPrsquos BGP hijacking [53] and a stealthier variantrelieving the attacker from the risk of getting exposed [54]Cryptocurrency mining has been a popular subject inassessing the security of Bitcoin selfish mining [37] blockwithholding attack [36] and a mixed strategy [38] have beenstudied Double-spending attacks have been studied in thecontext of Bitcoin fast payments [60]

74 Block Explorer Services We have surveyed the popularblock explorer services of Bitcoin [5 10 12] Ethereum[10 13 16] and EOS [11 14 15] to see the availability ofinformation beyond what is recorded in the main chainblock data we have utilized in our study namely

(i) Stale blockstransactions no Bitcoin and EOS blockexplorers provide stale block information (A relatedstudy [36] has utilized a Bitcoin block explorer service[68] to retrieve stale blocks However the service has

been terminated in March 2019) All Ethereum blockexplorers provide only reported stale blocks (ie uncleblocks [23]) (Ethereum provides incentives for unclestale blocks [44] so that miners include them in theirmined blocks for profit)No block explorers provide stale transaction infor-mation unless one is currently pooled

(ii) Blocktransaction arrival times all block explorersprovide block timestamps that are recorded in theblock headers not the actual times of arrival Ourblockchain fork and gap analysis require measuredblock arrival times at multiple locations All blockexplorers show transaction timestamps identical to theblock timestamp to which the transactions belong(Recent Bitcoin transactions have different timestampsthan the block timestamps in [4] while the timestampsare only at a granularity of one minute) [69 70]

8 Conclusion

We have measured transaction and block arrival events ofthe three permissionless blockchains We have devised anoble analysis model and analyzed completeness of ourblock and transaction logs Finally we have studied thediscrepancy in measured events and arrival characteristics toshare our key findings including a false universal assumptionof previous mining-related studies

Data Availability

e measurement data used to support the findings of thisstudy have not been made available because they containprivate information that can be used to identify individualblockchain nodes

Disclosure

is is an extended and revised version of a conference paperpresented in IEEE ICDCS 2021 [41]

Conflicts of Interest

e authors declare that they have no conflicts of interest

Acknowledgments

e authors would like to thank Seungwon Woo DaegeunYoon and Changhyun Lee for helping them with themeasurement instrumentation is work was supported byElectronics and Telecommunications Research Institute(ETRI) grant funded by the Korean Government (21ZR1300Research on Intelligent Cyber Security and Trust Infra)

References

[1] S Nakamoto ldquoBitcoin a peer-to-peer electronic cash systemrdquo2019

[2] V Buterin ldquoEthereum white paperrdquo 2013 httpsethereumorgenwhitepaper

[3] Monero ldquoMonerordquo 2020 httpswebgetmoneroorg

16 Security and Communication Networks

[4] bitcoincashorg httpswwwbitcoincashorg[5] Blockchaincom httpswwwblockchaincom[6] Ripple ldquoXRP e best digital asset for global paymentsrdquo

2020 httpsripplecomxrp[7] I Foundation ldquoIotardquo 2021 httpswwwiotaorg[8] ldquoEosiordquo 2020 httpseosio[9] S Orsquoneal ldquoEos proves yet again that decentralization is not its

priorityrdquo 2018 httpscointelegraphcomnewseos-proves-yet-again-that-decentralization-is-not-its-priority

[10] Blockchair httpsblockchaircom[11] Bloksio httpsbloksio[12] BTCcom ldquoBitcoin block explorerrdquo 2021 httpsbtccom[13] Ethereum block explorer httpsethbtccom[14] eosflareio Eos block explorer httpseosflareio[15] EOSPark ldquoEos block explorerrdquo 2021 httpseosparkcom[16] Etherscan Ethereum explorer httpsetherscanio[17] S Lee C Yoon and H Kang ldquoCybercriminal minds An

investigative study of cryptocurrency abuses in the dark webrdquoin Proceedings of the Network and Distributed System SecuritySymposium pp 1ndash15 Internet Society San Diego CA USAFebruary 2019

[18] MMoser R Bohme and D Breuker ldquoAn inquiry into moneylaundering tools in the bitcoin ecosystemrdquo in Proceedings ofthe 2013 APWG eCrime Researchers summit pp 1ndash14 IEEESan Francisco CA USA September 2013

[19] M Lischke and B Fabian ldquoAnalyzing the bitcoin network thefirst four yearsrdquo Future Internet vol 8 no 1 2016

[20] A E Gencer S Basu I Eyal R V Renesse and E G SirerldquoDecentralization in bitcoin and ethereum networksrdquo inProceedings of the International Conference On FinancialCryptography and Data Security pp 439ndash457 SpringerNieuwport Curaccedilao February 2018

[21] A Gervais G O Karame KWust V Glykantzis H Ritzdorfand S Capkun ldquoOn the security and performance of proof ofwork blockchainsrdquo in Proceedings Of the 2016 ACM SIGSACConference on Computer and Communications Securitypp 3ndash16 Vienna Austria October 2016

[22] C Wang X Chu and Q Yang ldquoMeasurement and analysis ofthe bitcoin networks a view from mining poolsrdquo 2019httpsarxivorgabs190207549

[23] G Wood ldquoEthereum A secure decentralised generalisedtransaction ledgerrdquo Ethereum Project Yellow Paper vol 1512014

[24] ldquoTransactions protocol eosio developer docsrdquo 2018 httpsdeveloperseosiowelcomev20protocoltransactions_protocol

[25] Y Sompolinsky and A Zohar ldquoSecure high-rate transactionprocessing in bitcoinrdquo in Proceedings of the InternationalConference On Financial Cryptography and Data Securitypp 507ndash527 Springer San Juan PR USA January 2015

[26] Blockone ldquoConsensus protocolrdquo 2018 httpsdeveloperseosiowelcomev20protocolconsensus_protocol

[27] A Gervais H Ritzdorf G O Karame and S CapkunldquoTampering with the delivery of blocks and transactions inbitcoinrdquo in Proceedings Of the 22nd ACM SIGSAC ConferenceOn Computer and Communications Security pp 692ndash705Denver CO USA October 2015

[28] ldquoGithub Bit coinrdquo 2020 httpsgithubcombitcoinbitcoin[29] G Ethereum ldquoGo ethereumrdquo 2020 httpsgithubcom

ethereumgo-ethereum[30] Google ldquoGoogle cloudrdquo 2021 httpscloudgooglecom[31] ldquoHow to replay from a snapshotrdquo 2018 httpsdeveloperseos

iomanualseoslatestnodeosreplayshow-to-replay-from-a-snapshot

[32] C Decker and R Wattenhofer ldquoInformation propagation inthe bitcoin networkrdquo in Proceedings of the IEEE P2P 2013Proceedings pp 1ndash10 IEEE Trento Italy September 2013

[33] ldquoEthereum uncle raterdquo 2020 httpsychartscomindicatorsethereum_uncle_rate

[34] J A Donet C P Sola and J H Joancomartı ldquoe bitcoin p2pnetworkrdquo in Proceedings of the International Conference OnFinancial Cryptography and Data Security pp 87ndash102Springer Christ Church Barbados March 2014

[35] G S Davies ldquoBit-booster - offline commit graph drawingtoolrdquo 2016 httpbit-boostercomgraphhtml

[36] N T Courtois and L Bahack ldquoOn subversive miner strategiesand block withholding attack in bitcoin digital currencyrdquo2014 httpsarxivorgabs14021718

[37] I Eyal and E G Sirer ldquoMajority is not enough bitcoin miningis vulnerablerdquo in Proceedings of the International Conferenceon Financial Cryptography and Data Security pp 436ndash454Springer Christ Church Barbados March 2014

[38] Y Kwon D Kim Y Son E Vasserman and Y Kim ldquoBeselfish and avoid dilemmas fork after withholding (faw) at-tacks on bitcoinrdquo in Proceedings Of the 2017 ACM SIGSACConference On Computer and Communications Securitypp 195ndash209 Abu Dhabi UAE April 2017

[39] B Research ldquoDecentralisation governance and eos - a lostcaserdquo 2020 httpsresearchbinancecomenanalysiseos-governance

[40] B Wiki ldquoIrreversible transactions - finney attackrdquo 2012httpsenbitcoinitwikiIrreversible_Transactions∖Finney_attack

[41] J Poon and T Dryja ldquoe bitcoin lightning network scalableoff-chain instant paymentsrdquo 2016

[42] M Bartoletti and L Pompianu ldquoAn analysis of bitcoin op_return metadatardquo in Proceedings of the International Con-ference On Financial Cryptography and Data Securitypp 218ndash230 Springer Sliema Malta April 2017

[43] ldquoReplace by feerdquo 2018 httpsenbitcoinitwikiReplace_by_fee

[44] E Foundation ldquoNode and clientsrdquo 2020 httpsethereumorgendevelopersdocsnodes-and-clients

[45] H Heo and S Shin ldquoBehind block explorers public block-chain measurement and security implicationrdquo in Proceedingsof the 41th IEEE International Conference On DistributedComputing Systems IEEE Washington DC USA In pressWashington DC USA July 2021

[46] R Bowden H P Keeler A E Krzesinski and P G TaylorldquoBlock arrivals in the bitcoin blockchainrdquo 2018 httpsarxivorgabs180107447

[47] M E Crovella and A Bestavros ldquoExplaining world wide webtraffic self-similarityrdquo Technical Report Citeseer PrincetonNJ USA 1995

[48] H Zhang Y Shu and O Yang ldquoEstimation of hurst pa-rameter by variance-time plotsrdquo in Proceedings of the 1997IEEE Pacific Rim Conference on Communications Computersand Signal Processing PACRIM 10 Years Networkingthe Pacific Rim 1987-1997 IEEE Victoria BC CanadaAugust 1997

[49] A Feldmann ldquoCharacteristics of TCP connection arrivalsrdquo inSelf-Similar Network Traffic and Performance EvaluationK Park andWWillinger Eds pp 367ndash399Wiley HobokenNJ USA 2000

[50] RSK ldquoRSKrdquo 2021 httpswwwrskco[51] E Heilman A Kendler A Zohar and S Goldberg ldquoEclipse

attacks on bitcoinrsquos peer-to-peer networkrdquo in Proceedings of

Security and Communication Networks 17

the 24th USENIX Security Symposium pp 129ndash144 Wash-ington DC USA April 2015

[52] Y Marcus E Heilman and S Goldberg ldquoLow-resourceeclipse attacks on ethereumrsquos peer-to-peer networkrdquo IACRCryptology vol 2018 p 236 2018

[53] M Apostolaki A Zohar and L Vanbever ldquoHijacking bitcoinRouting attacks on cryptocurrenciesrdquo in Proceedings of the2017 IEEE Symposium On Security and Privacy (SP)pp 375ndash392 IEEE San Jose CA USA May 2017

[54] M Tran I Choi G J Moon A V Vu and M S Kang ldquoAstealthier partitioning attack against bitcoin peer-to-peernetworkrdquo in Proceedings of the IEEE Symposium On Securityand Privacy (SampP) San Francisco CA USA May 2020

[55] B I Proposal ldquoBip 0152rdquo 2016 httpsenbitcoinitwikiBIP_0152

[56] B Core ldquoBitcoin Core Version 01901 Release Noterdquo 2016httpsbitcoinorgenreleasev01901

[57] ldquoGeth v190rdquo 2019 httpsblogethereumorg20190710geth-v1-9-0

[58] ldquoProtocol documentationrdquo 2016 httpsenbitcoinitwikiProtocoltext_documentation

[59] C Feng and J Niu ldquoSelfish mining in ethereumrdquo in Pro-ceedings of the 2019 IEEE 39th International Conference OnDistributed Computing Systems (ICDCS) pp 1306ndash1316IEEE Dallas TX USA July 2019

[60] G O Karame E Androulaki and S Capkun ldquoDouble-spending fast payments in bitcoinrdquo in Proceedings of the 2012ACM Conference on Computer and Communications Securitypp 906ndash917 Raleigh NC USA October 2012

[61] P Das L Eckey T Frassetto et al ldquoFastkitten practical smartcontracts on bitcoinrdquo in Proceedimgs of the 28th USENIXSecurity Symposium (USENIX Security 19) pp 801ndash818Santa Clara CA USA August 2019

[62] S G Motlagh J Misic and V B Misic ldquoe impact of selfishmining on bitcoin network performancerdquo IEEE Transactionson Network Science and Engineering vol 8 no 1 pp 724ndash7352021

[63] A Muhle A Gruner T Gayvoronskaya and C Meinel ldquoAsurvey on essential components of a self-sovereign identityrdquoComputer Science Review vol 30 pp 80ndash86 2018

[64] M Toorani and C Gehrmann ldquoA decentralized dynamic pkibased on blockchainrdquo in Proceedings Of the 36th Annual ACMSymposium On Applied Computing pp 1646ndash1655 GwangjuKorea March 2021

[65] E foundation ldquoOptimistic-rollupsrdquo 2021 httpsdocsethhubioethereum-roadmaplayer-2-scalingoptimistictext_rollups

[66] ldquoZk-rollupsrdquo 2021 httpsdocsethhubioethereum-roadmaplayer-2-scalingzk-rollups

[67] E foundation ldquoEthereumwire protocolrdquo 2019 httpsgithubcomethereumdevp2pblobmastercapseth

[68] S K Kim Z Ma S Murali J Mason A Miller andM BaileyldquoMeasuring ethereum network peersrdquo in Proceedings of theInternet Measurement Conference 2018 pp 91ndash104 BostonMA USA October 2018

[69] Symmetricom ldquoDelivering sub-microsecond accurate time tolinux applications around the worldrdquo 2012 httpwwwchronoscoukfilespdfswpsWP_AccurateTimeForLinuxApplicationspdf

[70] Ycharts ldquoBlocktrail blockchain data query service (termi-nated)rdquo 2019 httpsblocktrailcom

18 Security and Communication Networks

measurement Both cryptocurrency market values andblockchain network utilizations are rapidly increasing andthus miners are getting more motivated to optimize theirperformance for example Bitcoin fork probability has be-come far smaller than what is reported previously (seeSection 41)

Second the blockchain state information is not collected inour measurement Our analysis is performed based on onlyavailable information stored in block and transaction logs Wehave utilized an Ethereum archive node [44] to query historicalstate information (eg account balance or account nonce) inSection 42 However such proactive state replication is farmore complicated with EOS unless the full node is configuredto operate as a producing node and logging the state infor-mation thus EOS stale transactions could not be fully un-derstood without the missing EOS network state information

7 Related Work

71 Blockchain Data Analysis Historical transaction data ofBitcoin have often been studied for economic aspects such ascryptocurrency abuse [17] anti-money-laundering [18] andmonetary flow of businesses [19] However historicalblockchain data usually available from block explorer ser-vices are not sufficient for our research purpose

72 Blockchain Measurement Researchers have performedblockchain measurement studies to assess the degree ofdecentralization [20] to investigate demographic informa-tion of network nodes [34 68] to study mining pool be-havior [22] and to evaluate security of PoW blockchains [21]against known attacks such as double-spending attack [60]and selfish mining [37] Our work expands the under-standing of previous security evaluations with the keyfindings acquired from our large-scale transaction and blockmeasurement

73 Blockchain Attacks Partitioning attacks usually exploitvulnerable peer management mechanisms of Bitcoin [51]and Ethereum [52] Such attacks are also examined in thecontext of ISPrsquos BGP hijacking [53] and a stealthier variantrelieving the attacker from the risk of getting exposed [54]Cryptocurrency mining has been a popular subject inassessing the security of Bitcoin selfish mining [37] blockwithholding attack [36] and a mixed strategy [38] have beenstudied Double-spending attacks have been studied in thecontext of Bitcoin fast payments [60]

74 Block Explorer Services We have surveyed the popularblock explorer services of Bitcoin [5 10 12] Ethereum[10 13 16] and EOS [11 14 15] to see the availability ofinformation beyond what is recorded in the main chainblock data we have utilized in our study namely

(i) Stale blockstransactions no Bitcoin and EOS blockexplorers provide stale block information (A relatedstudy [36] has utilized a Bitcoin block explorer service[68] to retrieve stale blocks However the service has

been terminated in March 2019) All Ethereum blockexplorers provide only reported stale blocks (ie uncleblocks [23]) (Ethereum provides incentives for unclestale blocks [44] so that miners include them in theirmined blocks for profit)No block explorers provide stale transaction infor-mation unless one is currently pooled

(ii) Blocktransaction arrival times all block explorersprovide block timestamps that are recorded in theblock headers not the actual times of arrival Ourblockchain fork and gap analysis require measuredblock arrival times at multiple locations All blockexplorers show transaction timestamps identical to theblock timestamp to which the transactions belong(Recent Bitcoin transactions have different timestampsthan the block timestamps in [4] while the timestampsare only at a granularity of one minute) [69 70]

8 Conclusion

We have measured transaction and block arrival events ofthe three permissionless blockchains We have devised anoble analysis model and analyzed completeness of ourblock and transaction logs Finally we have studied thediscrepancy in measured events and arrival characteristics toshare our key findings including a false universal assumptionof previous mining-related studies

Data Availability

e measurement data used to support the findings of thisstudy have not been made available because they containprivate information that can be used to identify individualblockchain nodes

Disclosure

is is an extended and revised version of a conference paperpresented in IEEE ICDCS 2021 [41]

Conflicts of Interest

e authors declare that they have no conflicts of interest

Acknowledgments

e authors would like to thank Seungwon Woo DaegeunYoon and Changhyun Lee for helping them with themeasurement instrumentation is work was supported byElectronics and Telecommunications Research Institute(ETRI) grant funded by the Korean Government (21ZR1300Research on Intelligent Cyber Security and Trust Infra)

References

[1] S Nakamoto ldquoBitcoin a peer-to-peer electronic cash systemrdquo2019

[2] V Buterin ldquoEthereum white paperrdquo 2013 httpsethereumorgenwhitepaper

[3] Monero ldquoMonerordquo 2020 httpswebgetmoneroorg

16 Security and Communication Networks

[4] bitcoincashorg httpswwwbitcoincashorg[5] Blockchaincom httpswwwblockchaincom[6] Ripple ldquoXRP e best digital asset for global paymentsrdquo

2020 httpsripplecomxrp[7] I Foundation ldquoIotardquo 2021 httpswwwiotaorg[8] ldquoEosiordquo 2020 httpseosio[9] S Orsquoneal ldquoEos proves yet again that decentralization is not its

priorityrdquo 2018 httpscointelegraphcomnewseos-proves-yet-again-that-decentralization-is-not-its-priority

[10] Blockchair httpsblockchaircom[11] Bloksio httpsbloksio[12] BTCcom ldquoBitcoin block explorerrdquo 2021 httpsbtccom[13] Ethereum block explorer httpsethbtccom[14] eosflareio Eos block explorer httpseosflareio[15] EOSPark ldquoEos block explorerrdquo 2021 httpseosparkcom[16] Etherscan Ethereum explorer httpsetherscanio[17] S Lee C Yoon and H Kang ldquoCybercriminal minds An

investigative study of cryptocurrency abuses in the dark webrdquoin Proceedings of the Network and Distributed System SecuritySymposium pp 1ndash15 Internet Society San Diego CA USAFebruary 2019

[18] MMoser R Bohme and D Breuker ldquoAn inquiry into moneylaundering tools in the bitcoin ecosystemrdquo in Proceedings ofthe 2013 APWG eCrime Researchers summit pp 1ndash14 IEEESan Francisco CA USA September 2013

[19] M Lischke and B Fabian ldquoAnalyzing the bitcoin network thefirst four yearsrdquo Future Internet vol 8 no 1 2016

[20] A E Gencer S Basu I Eyal R V Renesse and E G SirerldquoDecentralization in bitcoin and ethereum networksrdquo inProceedings of the International Conference On FinancialCryptography and Data Security pp 439ndash457 SpringerNieuwport Curaccedilao February 2018

[21] A Gervais G O Karame KWust V Glykantzis H Ritzdorfand S Capkun ldquoOn the security and performance of proof ofwork blockchainsrdquo in Proceedings Of the 2016 ACM SIGSACConference on Computer and Communications Securitypp 3ndash16 Vienna Austria October 2016

[22] C Wang X Chu and Q Yang ldquoMeasurement and analysis ofthe bitcoin networks a view from mining poolsrdquo 2019httpsarxivorgabs190207549

[23] G Wood ldquoEthereum A secure decentralised generalisedtransaction ledgerrdquo Ethereum Project Yellow Paper vol 1512014

[24] ldquoTransactions protocol eosio developer docsrdquo 2018 httpsdeveloperseosiowelcomev20protocoltransactions_protocol

[25] Y Sompolinsky and A Zohar ldquoSecure high-rate transactionprocessing in bitcoinrdquo in Proceedings of the InternationalConference On Financial Cryptography and Data Securitypp 507ndash527 Springer San Juan PR USA January 2015

[26] Blockone ldquoConsensus protocolrdquo 2018 httpsdeveloperseosiowelcomev20protocolconsensus_protocol

[27] A Gervais H Ritzdorf G O Karame and S CapkunldquoTampering with the delivery of blocks and transactions inbitcoinrdquo in Proceedings Of the 22nd ACM SIGSAC ConferenceOn Computer and Communications Security pp 692ndash705Denver CO USA October 2015

[28] ldquoGithub Bit coinrdquo 2020 httpsgithubcombitcoinbitcoin[29] G Ethereum ldquoGo ethereumrdquo 2020 httpsgithubcom

ethereumgo-ethereum[30] Google ldquoGoogle cloudrdquo 2021 httpscloudgooglecom[31] ldquoHow to replay from a snapshotrdquo 2018 httpsdeveloperseos

iomanualseoslatestnodeosreplayshow-to-replay-from-a-snapshot

[32] C Decker and R Wattenhofer ldquoInformation propagation inthe bitcoin networkrdquo in Proceedings of the IEEE P2P 2013Proceedings pp 1ndash10 IEEE Trento Italy September 2013

[33] ldquoEthereum uncle raterdquo 2020 httpsychartscomindicatorsethereum_uncle_rate

[34] J A Donet C P Sola and J H Joancomartı ldquoe bitcoin p2pnetworkrdquo in Proceedings of the International Conference OnFinancial Cryptography and Data Security pp 87ndash102Springer Christ Church Barbados March 2014

[35] G S Davies ldquoBit-booster - offline commit graph drawingtoolrdquo 2016 httpbit-boostercomgraphhtml

[36] N T Courtois and L Bahack ldquoOn subversive miner strategiesand block withholding attack in bitcoin digital currencyrdquo2014 httpsarxivorgabs14021718

[37] I Eyal and E G Sirer ldquoMajority is not enough bitcoin miningis vulnerablerdquo in Proceedings of the International Conferenceon Financial Cryptography and Data Security pp 436ndash454Springer Christ Church Barbados March 2014

[38] Y Kwon D Kim Y Son E Vasserman and Y Kim ldquoBeselfish and avoid dilemmas fork after withholding (faw) at-tacks on bitcoinrdquo in Proceedings Of the 2017 ACM SIGSACConference On Computer and Communications Securitypp 195ndash209 Abu Dhabi UAE April 2017

[39] B Research ldquoDecentralisation governance and eos - a lostcaserdquo 2020 httpsresearchbinancecomenanalysiseos-governance

[40] B Wiki ldquoIrreversible transactions - finney attackrdquo 2012httpsenbitcoinitwikiIrreversible_Transactions∖Finney_attack

[41] J Poon and T Dryja ldquoe bitcoin lightning network scalableoff-chain instant paymentsrdquo 2016

[42] M Bartoletti and L Pompianu ldquoAn analysis of bitcoin op_return metadatardquo in Proceedings of the International Con-ference On Financial Cryptography and Data Securitypp 218ndash230 Springer Sliema Malta April 2017

[43] ldquoReplace by feerdquo 2018 httpsenbitcoinitwikiReplace_by_fee

[44] E Foundation ldquoNode and clientsrdquo 2020 httpsethereumorgendevelopersdocsnodes-and-clients

[45] H Heo and S Shin ldquoBehind block explorers public block-chain measurement and security implicationrdquo in Proceedingsof the 41th IEEE International Conference On DistributedComputing Systems IEEE Washington DC USA In pressWashington DC USA July 2021

[46] R Bowden H P Keeler A E Krzesinski and P G TaylorldquoBlock arrivals in the bitcoin blockchainrdquo 2018 httpsarxivorgabs180107447

[47] M E Crovella and A Bestavros ldquoExplaining world wide webtraffic self-similarityrdquo Technical Report Citeseer PrincetonNJ USA 1995

[48] H Zhang Y Shu and O Yang ldquoEstimation of hurst pa-rameter by variance-time plotsrdquo in Proceedings of the 1997IEEE Pacific Rim Conference on Communications Computersand Signal Processing PACRIM 10 Years Networkingthe Pacific Rim 1987-1997 IEEE Victoria BC CanadaAugust 1997

[49] A Feldmann ldquoCharacteristics of TCP connection arrivalsrdquo inSelf-Similar Network Traffic and Performance EvaluationK Park andWWillinger Eds pp 367ndash399Wiley HobokenNJ USA 2000

[50] RSK ldquoRSKrdquo 2021 httpswwwrskco[51] E Heilman A Kendler A Zohar and S Goldberg ldquoEclipse

attacks on bitcoinrsquos peer-to-peer networkrdquo in Proceedings of

Security and Communication Networks 17

the 24th USENIX Security Symposium pp 129ndash144 Wash-ington DC USA April 2015

[52] Y Marcus E Heilman and S Goldberg ldquoLow-resourceeclipse attacks on ethereumrsquos peer-to-peer networkrdquo IACRCryptology vol 2018 p 236 2018

[53] M Apostolaki A Zohar and L Vanbever ldquoHijacking bitcoinRouting attacks on cryptocurrenciesrdquo in Proceedings of the2017 IEEE Symposium On Security and Privacy (SP)pp 375ndash392 IEEE San Jose CA USA May 2017

[54] M Tran I Choi G J Moon A V Vu and M S Kang ldquoAstealthier partitioning attack against bitcoin peer-to-peernetworkrdquo in Proceedings of the IEEE Symposium On Securityand Privacy (SampP) San Francisco CA USA May 2020

[55] B I Proposal ldquoBip 0152rdquo 2016 httpsenbitcoinitwikiBIP_0152

[56] B Core ldquoBitcoin Core Version 01901 Release Noterdquo 2016httpsbitcoinorgenreleasev01901

[57] ldquoGeth v190rdquo 2019 httpsblogethereumorg20190710geth-v1-9-0

[58] ldquoProtocol documentationrdquo 2016 httpsenbitcoinitwikiProtocoltext_documentation

[59] C Feng and J Niu ldquoSelfish mining in ethereumrdquo in Pro-ceedings of the 2019 IEEE 39th International Conference OnDistributed Computing Systems (ICDCS) pp 1306ndash1316IEEE Dallas TX USA July 2019

[60] G O Karame E Androulaki and S Capkun ldquoDouble-spending fast payments in bitcoinrdquo in Proceedings of the 2012ACM Conference on Computer and Communications Securitypp 906ndash917 Raleigh NC USA October 2012

[61] P Das L Eckey T Frassetto et al ldquoFastkitten practical smartcontracts on bitcoinrdquo in Proceedimgs of the 28th USENIXSecurity Symposium (USENIX Security 19) pp 801ndash818Santa Clara CA USA August 2019

[62] S G Motlagh J Misic and V B Misic ldquoe impact of selfishmining on bitcoin network performancerdquo IEEE Transactionson Network Science and Engineering vol 8 no 1 pp 724ndash7352021

[63] A Muhle A Gruner T Gayvoronskaya and C Meinel ldquoAsurvey on essential components of a self-sovereign identityrdquoComputer Science Review vol 30 pp 80ndash86 2018

[64] M Toorani and C Gehrmann ldquoA decentralized dynamic pkibased on blockchainrdquo in Proceedings Of the 36th Annual ACMSymposium On Applied Computing pp 1646ndash1655 GwangjuKorea March 2021

[65] E foundation ldquoOptimistic-rollupsrdquo 2021 httpsdocsethhubioethereum-roadmaplayer-2-scalingoptimistictext_rollups

[66] ldquoZk-rollupsrdquo 2021 httpsdocsethhubioethereum-roadmaplayer-2-scalingzk-rollups

[67] E foundation ldquoEthereumwire protocolrdquo 2019 httpsgithubcomethereumdevp2pblobmastercapseth

[68] S K Kim Z Ma S Murali J Mason A Miller andM BaileyldquoMeasuring ethereum network peersrdquo in Proceedings of theInternet Measurement Conference 2018 pp 91ndash104 BostonMA USA October 2018

[69] Symmetricom ldquoDelivering sub-microsecond accurate time tolinux applications around the worldrdquo 2012 httpwwwchronoscoukfilespdfswpsWP_AccurateTimeForLinuxApplicationspdf

[70] Ycharts ldquoBlocktrail blockchain data query service (termi-nated)rdquo 2019 httpsblocktrailcom

18 Security and Communication Networks

[4] bitcoincashorg httpswwwbitcoincashorg[5] Blockchaincom httpswwwblockchaincom[6] Ripple ldquoXRP e best digital asset for global paymentsrdquo

2020 httpsripplecomxrp[7] I Foundation ldquoIotardquo 2021 httpswwwiotaorg[8] ldquoEosiordquo 2020 httpseosio[9] S Orsquoneal ldquoEos proves yet again that decentralization is not its

priorityrdquo 2018 httpscointelegraphcomnewseos-proves-yet-again-that-decentralization-is-not-its-priority

[10] Blockchair httpsblockchaircom[11] Bloksio httpsbloksio[12] BTCcom ldquoBitcoin block explorerrdquo 2021 httpsbtccom[13] Ethereum block explorer httpsethbtccom[14] eosflareio Eos block explorer httpseosflareio[15] EOSPark ldquoEos block explorerrdquo 2021 httpseosparkcom[16] Etherscan Ethereum explorer httpsetherscanio[17] S Lee C Yoon and H Kang ldquoCybercriminal minds An

investigative study of cryptocurrency abuses in the dark webrdquoin Proceedings of the Network and Distributed System SecuritySymposium pp 1ndash15 Internet Society San Diego CA USAFebruary 2019

[18] MMoser R Bohme and D Breuker ldquoAn inquiry into moneylaundering tools in the bitcoin ecosystemrdquo in Proceedings ofthe 2013 APWG eCrime Researchers summit pp 1ndash14 IEEESan Francisco CA USA September 2013

[19] M Lischke and B Fabian ldquoAnalyzing the bitcoin network thefirst four yearsrdquo Future Internet vol 8 no 1 2016

[20] A E Gencer S Basu I Eyal R V Renesse and E G SirerldquoDecentralization in bitcoin and ethereum networksrdquo inProceedings of the International Conference On FinancialCryptography and Data Security pp 439ndash457 SpringerNieuwport Curaccedilao February 2018

[21] A Gervais G O Karame KWust V Glykantzis H Ritzdorfand S Capkun ldquoOn the security and performance of proof ofwork blockchainsrdquo in Proceedings Of the 2016 ACM SIGSACConference on Computer and Communications Securitypp 3ndash16 Vienna Austria October 2016

[22] C Wang X Chu and Q Yang ldquoMeasurement and analysis ofthe bitcoin networks a view from mining poolsrdquo 2019httpsarxivorgabs190207549

[23] G Wood ldquoEthereum A secure decentralised generalisedtransaction ledgerrdquo Ethereum Project Yellow Paper vol 1512014

[24] ldquoTransactions protocol eosio developer docsrdquo 2018 httpsdeveloperseosiowelcomev20protocoltransactions_protocol

[25] Y Sompolinsky and A Zohar ldquoSecure high-rate transactionprocessing in bitcoinrdquo in Proceedings of the InternationalConference On Financial Cryptography and Data Securitypp 507ndash527 Springer San Juan PR USA January 2015

[26] Blockone ldquoConsensus protocolrdquo 2018 httpsdeveloperseosiowelcomev20protocolconsensus_protocol

[27] A Gervais H Ritzdorf G O Karame and S CapkunldquoTampering with the delivery of blocks and transactions inbitcoinrdquo in Proceedings Of the 22nd ACM SIGSAC ConferenceOn Computer and Communications Security pp 692ndash705Denver CO USA October 2015

[28] ldquoGithub Bit coinrdquo 2020 httpsgithubcombitcoinbitcoin[29] G Ethereum ldquoGo ethereumrdquo 2020 httpsgithubcom

ethereumgo-ethereum[30] Google ldquoGoogle cloudrdquo 2021 httpscloudgooglecom[31] ldquoHow to replay from a snapshotrdquo 2018 httpsdeveloperseos

iomanualseoslatestnodeosreplayshow-to-replay-from-a-snapshot

[32] C Decker and R Wattenhofer ldquoInformation propagation inthe bitcoin networkrdquo in Proceedings of the IEEE P2P 2013Proceedings pp 1ndash10 IEEE Trento Italy September 2013

[33] ldquoEthereum uncle raterdquo 2020 httpsychartscomindicatorsethereum_uncle_rate

[34] J A Donet C P Sola and J H Joancomartı ldquoe bitcoin p2pnetworkrdquo in Proceedings of the International Conference OnFinancial Cryptography and Data Security pp 87ndash102Springer Christ Church Barbados March 2014

[35] G S Davies ldquoBit-booster - offline commit graph drawingtoolrdquo 2016 httpbit-boostercomgraphhtml

[36] N T Courtois and L Bahack ldquoOn subversive miner strategiesand block withholding attack in bitcoin digital currencyrdquo2014 httpsarxivorgabs14021718

[37] I Eyal and E G Sirer ldquoMajority is not enough bitcoin miningis vulnerablerdquo in Proceedings of the International Conferenceon Financial Cryptography and Data Security pp 436ndash454Springer Christ Church Barbados March 2014

[38] Y Kwon D Kim Y Son E Vasserman and Y Kim ldquoBeselfish and avoid dilemmas fork after withholding (faw) at-tacks on bitcoinrdquo in Proceedings Of the 2017 ACM SIGSACConference On Computer and Communications Securitypp 195ndash209 Abu Dhabi UAE April 2017

[39] B Research ldquoDecentralisation governance and eos - a lostcaserdquo 2020 httpsresearchbinancecomenanalysiseos-governance

[40] B Wiki ldquoIrreversible transactions - finney attackrdquo 2012httpsenbitcoinitwikiIrreversible_Transactions∖Finney_attack

[41] J Poon and T Dryja ldquoe bitcoin lightning network scalableoff-chain instant paymentsrdquo 2016

[42] M Bartoletti and L Pompianu ldquoAn analysis of bitcoin op_return metadatardquo in Proceedings of the International Con-ference On Financial Cryptography and Data Securitypp 218ndash230 Springer Sliema Malta April 2017

[43] ldquoReplace by feerdquo 2018 httpsenbitcoinitwikiReplace_by_fee

[44] E Foundation ldquoNode and clientsrdquo 2020 httpsethereumorgendevelopersdocsnodes-and-clients

[45] H Heo and S Shin ldquoBehind block explorers public block-chain measurement and security implicationrdquo in Proceedingsof the 41th IEEE International Conference On DistributedComputing Systems IEEE Washington DC USA In pressWashington DC USA July 2021

[46] R Bowden H P Keeler A E Krzesinski and P G TaylorldquoBlock arrivals in the bitcoin blockchainrdquo 2018 httpsarxivorgabs180107447

[47] M E Crovella and A Bestavros ldquoExplaining world wide webtraffic self-similarityrdquo Technical Report Citeseer PrincetonNJ USA 1995

[48] H Zhang Y Shu and O Yang ldquoEstimation of hurst pa-rameter by variance-time plotsrdquo in Proceedings of the 1997IEEE Pacific Rim Conference on Communications Computersand Signal Processing PACRIM 10 Years Networkingthe Pacific Rim 1987-1997 IEEE Victoria BC CanadaAugust 1997

[49] A Feldmann ldquoCharacteristics of TCP connection arrivalsrdquo inSelf-Similar Network Traffic and Performance EvaluationK Park andWWillinger Eds pp 367ndash399Wiley HobokenNJ USA 2000

[50] RSK ldquoRSKrdquo 2021 httpswwwrskco[51] E Heilman A Kendler A Zohar and S Goldberg ldquoEclipse

attacks on bitcoinrsquos peer-to-peer networkrdquo in Proceedings of

Security and Communication Networks 17

the 24th USENIX Security Symposium pp 129ndash144 Wash-ington DC USA April 2015

[52] Y Marcus E Heilman and S Goldberg ldquoLow-resourceeclipse attacks on ethereumrsquos peer-to-peer networkrdquo IACRCryptology vol 2018 p 236 2018

[53] M Apostolaki A Zohar and L Vanbever ldquoHijacking bitcoinRouting attacks on cryptocurrenciesrdquo in Proceedings of the2017 IEEE Symposium On Security and Privacy (SP)pp 375ndash392 IEEE San Jose CA USA May 2017

[54] M Tran I Choi G J Moon A V Vu and M S Kang ldquoAstealthier partitioning attack against bitcoin peer-to-peernetworkrdquo in Proceedings of the IEEE Symposium On Securityand Privacy (SampP) San Francisco CA USA May 2020

[55] B I Proposal ldquoBip 0152rdquo 2016 httpsenbitcoinitwikiBIP_0152

[56] B Core ldquoBitcoin Core Version 01901 Release Noterdquo 2016httpsbitcoinorgenreleasev01901

[57] ldquoGeth v190rdquo 2019 httpsblogethereumorg20190710geth-v1-9-0

[58] ldquoProtocol documentationrdquo 2016 httpsenbitcoinitwikiProtocoltext_documentation

[59] C Feng and J Niu ldquoSelfish mining in ethereumrdquo in Pro-ceedings of the 2019 IEEE 39th International Conference OnDistributed Computing Systems (ICDCS) pp 1306ndash1316IEEE Dallas TX USA July 2019

[60] G O Karame E Androulaki and S Capkun ldquoDouble-spending fast payments in bitcoinrdquo in Proceedings of the 2012ACM Conference on Computer and Communications Securitypp 906ndash917 Raleigh NC USA October 2012

[61] P Das L Eckey T Frassetto et al ldquoFastkitten practical smartcontracts on bitcoinrdquo in Proceedimgs of the 28th USENIXSecurity Symposium (USENIX Security 19) pp 801ndash818Santa Clara CA USA August 2019

[62] S G Motlagh J Misic and V B Misic ldquoe impact of selfishmining on bitcoin network performancerdquo IEEE Transactionson Network Science and Engineering vol 8 no 1 pp 724ndash7352021

[63] A Muhle A Gruner T Gayvoronskaya and C Meinel ldquoAsurvey on essential components of a self-sovereign identityrdquoComputer Science Review vol 30 pp 80ndash86 2018

[64] M Toorani and C Gehrmann ldquoA decentralized dynamic pkibased on blockchainrdquo in Proceedings Of the 36th Annual ACMSymposium On Applied Computing pp 1646ndash1655 GwangjuKorea March 2021

[65] E foundation ldquoOptimistic-rollupsrdquo 2021 httpsdocsethhubioethereum-roadmaplayer-2-scalingoptimistictext_rollups

[66] ldquoZk-rollupsrdquo 2021 httpsdocsethhubioethereum-roadmaplayer-2-scalingzk-rollups

[67] E foundation ldquoEthereumwire protocolrdquo 2019 httpsgithubcomethereumdevp2pblobmastercapseth

[68] S K Kim Z Ma S Murali J Mason A Miller andM BaileyldquoMeasuring ethereum network peersrdquo in Proceedings of theInternet Measurement Conference 2018 pp 91ndash104 BostonMA USA October 2018

[69] Symmetricom ldquoDelivering sub-microsecond accurate time tolinux applications around the worldrdquo 2012 httpwwwchronoscoukfilespdfswpsWP_AccurateTimeForLinuxApplicationspdf

[70] Ycharts ldquoBlocktrail blockchain data query service (termi-nated)rdquo 2019 httpsblocktrailcom

18 Security and Communication Networks

the 24th USENIX Security Symposium pp 129ndash144 Wash-ington DC USA April 2015

[52] Y Marcus E Heilman and S Goldberg ldquoLow-resourceeclipse attacks on ethereumrsquos peer-to-peer networkrdquo IACRCryptology vol 2018 p 236 2018

[53] M Apostolaki A Zohar and L Vanbever ldquoHijacking bitcoinRouting attacks on cryptocurrenciesrdquo in Proceedings of the2017 IEEE Symposium On Security and Privacy (SP)pp 375ndash392 IEEE San Jose CA USA May 2017

[54] M Tran I Choi G J Moon A V Vu and M S Kang ldquoAstealthier partitioning attack against bitcoin peer-to-peernetworkrdquo in Proceedings of the IEEE Symposium On Securityand Privacy (SampP) San Francisco CA USA May 2020

[55] B I Proposal ldquoBip 0152rdquo 2016 httpsenbitcoinitwikiBIP_0152

[56] B Core ldquoBitcoin Core Version 01901 Release Noterdquo 2016httpsbitcoinorgenreleasev01901

[57] ldquoGeth v190rdquo 2019 httpsblogethereumorg20190710geth-v1-9-0

[58] ldquoProtocol documentationrdquo 2016 httpsenbitcoinitwikiProtocoltext_documentation

[59] C Feng and J Niu ldquoSelfish mining in ethereumrdquo in Pro-ceedings of the 2019 IEEE 39th International Conference OnDistributed Computing Systems (ICDCS) pp 1306ndash1316IEEE Dallas TX USA July 2019

[60] G O Karame E Androulaki and S Capkun ldquoDouble-spending fast payments in bitcoinrdquo in Proceedings of the 2012ACM Conference on Computer and Communications Securitypp 906ndash917 Raleigh NC USA October 2012

[61] P Das L Eckey T Frassetto et al ldquoFastkitten practical smartcontracts on bitcoinrdquo in Proceedimgs of the 28th USENIXSecurity Symposium (USENIX Security 19) pp 801ndash818Santa Clara CA USA August 2019

[62] S G Motlagh J Misic and V B Misic ldquoe impact of selfishmining on bitcoin network performancerdquo IEEE Transactionson Network Science and Engineering vol 8 no 1 pp 724ndash7352021

[63] A Muhle A Gruner T Gayvoronskaya and C Meinel ldquoAsurvey on essential components of a self-sovereign identityrdquoComputer Science Review vol 30 pp 80ndash86 2018

[64] M Toorani and C Gehrmann ldquoA decentralized dynamic pkibased on blockchainrdquo in Proceedings Of the 36th Annual ACMSymposium On Applied Computing pp 1646ndash1655 GwangjuKorea March 2021

[65] E foundation ldquoOptimistic-rollupsrdquo 2021 httpsdocsethhubioethereum-roadmaplayer-2-scalingoptimistictext_rollups

[66] ldquoZk-rollupsrdquo 2021 httpsdocsethhubioethereum-roadmaplayer-2-scalingzk-rollups

[67] E foundation ldquoEthereumwire protocolrdquo 2019 httpsgithubcomethereumdevp2pblobmastercapseth

[68] S K Kim Z Ma S Murali J Mason A Miller andM BaileyldquoMeasuring ethereum network peersrdquo in Proceedings of theInternet Measurement Conference 2018 pp 91ndash104 BostonMA USA October 2018

[69] Symmetricom ldquoDelivering sub-microsecond accurate time tolinux applications around the worldrdquo 2012 httpwwwchronoscoukfilespdfswpsWP_AccurateTimeForLinuxApplicationspdf

[70] Ycharts ldquoBlocktrail blockchain data query service (termi-nated)rdquo 2019 httpsblocktrailcom

18 Security and Communication Networks