i

The Interdisciplinary Center, Herzlia Efi Arazi School of Computer Science

Tortoise and Hares

Consensus:

A Framework for Incentive-

Compatible, Scalable

Cryptocurrencies

M.Sc. dissertation proposal

Submitted by Asaf Nadler

Under the supervision

of Dr. Tal Moran

March, 2017

ii

Acknowledgments

I would like to express my gratitude to my advisor, Dr. Tal Moran from

the Interdisciplinary Center (IDC). I would also like to thank my work

partners Pavel Hubacek from IDC and Iddo Bentov from Cornell

University. I could not have completed this work without their

professional knowledge and personal investment.

טבעות סגרת לבניית פרוטוקולים עבור ממ, Meshcashבעבודה זו, אנו מציגים את

הוכחות מבוסס (Consensus) משלבת פרוטוקול הסכמהמסגרת ה. םיקריפטוגרפימבטיח החסר הרשאות )פרוטוקול "הצב"( -במודל ביזנטי (Proofs-of-Work) עבודה

אשר הצלחתו איננה מובטחת אך התכנסות הסכמה לאורך זמן בשילוב עם פרוטוקול מודולרית קבלת ההסכמה )פרוטוקול "הארנב"(. הבנייה היא במידה וחלה מאיצה את

סגרת מדרישות. האשר עומדים בבמגוון פרוטוקולי "ארנב" שימושובכך מאפשרת במידה ופרוטוקול "הארנב" הצליח המשולבת נהנית משני העולמות: הסכמה מהירה

-אך הבטחה להסכמה גם במידה ונכשל. בניגוד לפרוטוקולי הסכמה מבוססי הוכחותעבודה, פרוטוקול "הצב" שלנו איננו נתמך על בחירת מנהיג )למשל: בביטקוין, הכורה

הראשון המאריך את השרשרת(. במקום זאת, אנו משתמשים ברעיונות מבוססי מתוכנן להיות Meshcashסינכרונית כדי להגיע בהדרגה להסכמה. -אהסכמה ביזנטית

בלוקים שיוצרו בהתאם כלל התחרות": אין "תחרות" לייצור הבלוק הבא ולכן -"נטולל, אשר מוגדר באמצעות מושגים בתורת לפרוטוקול מתוגמלים. המאפיין הנ"

סים להגדיל המשחקים, מאפשר אנליזה באשר להתנהגותם של כורים רציונליים המנ-אנחנו מוכיחים באמצעות הכללה של מודל תורתאת רווחם במידת האפשר.

את הטענה כי פרוטוקולים Kaiyasשל Blockchain mining gamesהמשחקים ( ומקיימים תגמול ליניארי incentive compatibleתמריץ )-תחרות הם תואמי-נטולי

החישוב שהשקיע(. הנ"ל מאפשר לנו )כל שחקן מתוגמל באופן פרופורציונאלי לכוח להוריד את השונות והתוחלת של הזמן בין בלוקים עוקבים עבור שחקנים העוקבים

( pooled mining) כורים אחרי הפרוטוקול. בשילוב עם תגמול ליניארי, התאחדותצמיחה של תחרות מאפשרים -הופכת לפחות אטרקטיבית. בנוסף, פרוטוקולים נטולי

עברות ברשת. זאת מכיוון שהיעדר התחרות מסיר את השפעת ה נפחם וקצבם של גמול.תמשך העיכוב של הרשת על ה

,Pass, Seemanסינכרוני של -אנו מוכיחים את כל טענותינו במודל התקשורת האshelat )לצד שחקנים רציונאליים ;וכנגד חלק קבוע של שחקנים ביזנטיים )זדוניים.

We propose Meshcash, a new framework for cryptocurrency protocols that combines a novel,proof-of-work based, permissionless byzantine consensus protocol (the tortoise) that guaranteeseventual consensus and irreversibility, with a possibly-faulty but quick consensus protocol (thehare). The construction is modular, allowing any suitable “hare” protocol to be plugged in.The combined protocol enjoys best of both worlds properties: consensus is quick if the hareprotocol succeeds, but guaranteed even if it is faulty. Unlike most existing proof-of-work basedconsensus protocols, our tortoise protocol does not rely on leader-election (e.g., the single minerwho managed to extend the longest chain). Rather, we use ideas from asynchronous byzantineagreement protocols to gradually converge to a consensus.

Meshcash, is designed to be race-free: there is no “race” to generate the next block, hencehonestly-generated blocks are always rewarded. This property, which we define formally asa game-theoretic notion, turns out to be useful in analyzing rational miners’ behavior: weprove (using a generalization of the blockchain mining games of Kiayias et al.) that race-free blockchain protocols are incentive-compatible and satisfy linearity of rewards (i.e., a partyreceives rewards proportional to its computational power).

Because Meshcash can tolerate a high block rate regardless of network propagation delays(which will only affect latency), it allows us to lower both the variance and the expected timebetween blocks for honest miners; together with linearity of rewards, this makes pooled miningfar less attractive. Moreover, race-free protocols scale more easily (in terms of transaction rate).This is because the race-free property implies that the network propagation delays are not afactor in terms of rewards, which removes the main impediment to accommodating a largervolume of transactions.

We formally prove that all of our guarantees hold in the asynchronous communication modelof Pass, Seeman and shelat, and against a constant fraction of byzantine (malicious) miners;not just rational ones.

Contents

1. Introduction 71.1. Our Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.2. Related Works . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91.3. Leader-Election-Based Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

1.3.1. Winner-takes-all . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101.3.2. Reward-sharing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

1.4. Leaderless Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

2. Protocol Description 132.1. Informal Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.2. Modeling Generic BlockDAG Protocols . . . . . . . . . . . . . . . . . . . . . . . 13

2.2.1. Validity. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.2.2. Total Order on Blocks. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.2.3. Security Properties. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

2.3. Weak Common Coins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.3.1. Implementing a Weak Common Coin Based on Proof-of-Work. . . . . . . 15

2.4. Modular (Tortoise) Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.4.1. Overview. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162.4.2. Hare Protocol Requirements. . . . . . . . . . . . . . . . . . . . . . . . . . 162.4.3. Tortoise Protocol Description. . . . . . . . . . . . . . . . . . . . . . . . . . 172.4.4. Protocol Parameters. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182.4.5. Protocol Concepts. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2.5. Security Proof Overview for Tortoise Protocol . . . . . . . . . . . . . . . . . . . . 202.5.1. Irreversibility. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.5.2. Pure Tortoise Consensus. . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.5.3. Hare & Tortoise Consensus. . . . . . . . . . . . . . . . . . . . . . . . . . . 212.5.4. Race-Freeness. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

2.6. Hare Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.6.1. Simple Hare Protocol. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212.6.2. Byzantine-Agreement-Based Hare Protocols. . . . . . . . . . . . . . . . . 22

2.7. Communication/Storage Optimizations. . . . . . . . . . . . . . . . . . . . . . . . 222.7.1. Efficient Verification Algorithm. . . . . . . . . . . . . . . . . . . . . . . . 23

3. Proof of Security 243.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243.2. Bounding the Layer Interval and the Size of the Future Reserve . . . . . . . . . . 263.3. Consistency and Future Self-Consistence (Irreversibility) . . . . . . . . . . . . . . 28

4. Proof of Theorem 3.3.1 324.1. Proof Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.2. Bounding the quantity M∗i (A) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 324.3. Bounding the Actual Confirmation Margin . . . . . . . . . . . . . . . . . . . . . 36

5

5. Byzantine-Agreement-Based Hare Protocol 375.1. The ABA Protocol’s Environment . . . . . . . . . . . . . . . . . . . . . . . . . . 37

5.1.1. Implementing the Environment. . . . . . . . . . . . . . . . . . . . . . . . . 385.2. Using the ABA Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 395.3. Improving the Hare-Protocol Parameters using Multivalued ABA . . . . . . . . . 405.4. Additional Potential Improvements . . . . . . . . . . . . . . . . . . . . . . . . . . 40

6. Improving the Hare-Protocol Parameters using Multivalued ABA: Details 42

7. Incentive-Compatibility of Race-Free Protocols 457.1. Generalized Blockchain Mining Games . . . . . . . . . . . . . . . . . . . . . . . . 457.2. Race-Free Games . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

7.2.1. Properties of Race-Free Games. . . . . . . . . . . . . . . . . . . . . . . . . 467.2.2. Race-Free Blockchain Protocols. . . . . . . . . . . . . . . . . . . . . . . . 46

7.3. Meshcash is Race-Free . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 477.4. When Fees Dominate Coinbase . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

A. Some standard tail bounds for the Poisson distribution 51

6

1. Introduction

For a currency to be effective, it should satisfy several conditions:

• Limited Supply: The supply of new coins should be limited.

• No double spending: The total amount of money expended by a party cannot be morethan the amount received by that party. That is, Alice should not be able to pay Boband Charlie with the same coin.

• Liveness: If Alice wishes to pay Bob and has enough funds to do so, then she will be ableto.

• Consensus on history: All the participants must have an agreed upon history of thetransactions in the currency. That is, if Charlie believes that Alice paid Bob, then Danaand Eve should not believe a contradicting claim.

• Irreversibility: Once a transaction is in the agreed history, it should stay there. That is,if everyone agrees that Alice paid Bob today, they should also believe this tomorrow.

These requirements apply to all currencies, but are particularly problematic for digital curren-cies. The “traditional” solution (e.g., as employed by the financial industry) is to rely on acentral authority in order to guarantee these properties (e.g., a government or a bank). Themain innovation of Bitcoin [27, 11, 28] is a method to distribute the trust requirements; insteadof having to trust entirely in a single authority, the underlying assumptions are about largergroups. In Bitcoin, the assumption is that the majority of the active participants behaveshonestly, where majority is measured by computational power.

As described by Nakamoto [27], the core mechanism for achieving the above desiderata isby constructing a distributed timestamping server. This allows all participants to agree on thetransaction history, and in particular on the order in which transactions occurred (ensuring thatif a party tries to spend the same coin twice, everyone will agree which of the two transactionsis valid). Loosely speaking, participants “vote” for the history they consider valid, and themajority “wins”. In an ideal, democratic cryptocurrency, every participant would be allowedthe same number of votes. However, this seems impossible to enforce in the current Internet;since there is no mechanism for identity verification, a malicious party can create many fakeidentities. Instead of using a “one-person-one-vote” rule, Bitcoin enforces a “one-resource-one-vote” rule, with the resource in question being computational work. That is, participantsgenerate Proofs of Work, with each proof corresponding to a “vote”. To reduce communication,Bitcoin actually uses a lottery system, where each Proof of Work (PoW) corresponds to a lotteryticket, and only the winning ticket gets to vote.

The decentralized nature of the Bitcoin protocol stems from the fact that it allows anyonewho contributes computational power to participate. In this sense, Bitcoin is regarded to be apermissionless consensus protocol (cf. [3]).

Indeed, the Bitcoin network has been running without major setbacks since its launch inJanuary 2009. Yet, a significant volume of academic work has been done to analyze futureobstacles that Bitcoin may face: centralization of the mining power in the hands of few largedata centers [24, 8], scalability barrier w.r.t. high volume of commerce [7, 34, 16] or selfishmining [10, 32].

7

1.1. Our Contributions

In this work, we describe our novel Meshcash framework, which aims to either solve or mitigatethe aforementioned risks that Bitcoin faces. The fundamental idea behind Meshcash is a novelconsensus protocol that is not based on leader-election. Instead of a race to be chosen as the“leader” of the next round, in which only one party can be the winner (e.g., generate the nextblock in Bitcoin), we use ideas from the byzantine agreement literature to achieve a consensuson all generated blocks. In particular, this means that one miner’s success does not prevent thesuccess of another.

The construction is modular, combining our long-term “tortoise” consensus protocol (thatguarantees eventual consensus and irreversibility very robustly) with a short-term “hare” pro-tocol that can achieve consensus quickly but is not robust (or irreversible). This allows us to getthe best of both worlds: fast, irreversible consensus if the hare protocol succeeds, and long-termirreversible consensus under more extreme conditions.

Unlike most alternative cryptocurrency protocols, we prove our security guarantees withregards to malicious adversaries and in an asynchronous communication model. This meansthat our protocol is robust even against non-rational adversaries (as long as they do not havetoo large a fraction of the computation power). At the same time, we can still show that theprotocol is incentive-compatible (under some simplifying assumptions).

Our protocol replaces the single chain of blocks (in which only one block can be next) witha mesh—a layered directed acyclic graph (DAG) which allows multiple blocks to coexist inparallel, while the rewards are still shared proportionally to the work performed. This offersmitigating factors for the risks that Bitcoin faces:

• Greatly reduced incentives for pool mining. This risk stems from the simple factthat the expected time and variance of solving blocks is too high for a hobbyist miner.For example, if there are 100, 000 miners with equal hashrate, and the Bitcoin difficultydictates it takes 10 minutes on average to solve a block, then each miner will need towait for 1 million minutes (slightly less than 2 years) on average before solving a block.This would obviously be unacceptable from the point of view of the individual miners, asthey have running expenses and their mining equipment may fail before they are ever re-warded. Therefore, Bitcoin miners have a strong incentive to combine their resources intocentralized pools. This is unhealthy for decentralization, because pools tend to increase insize over time. As a remedy against the centralization pressure, many more blocks wouldget created per unit of time in Meshcash (e.g., we can easily support 200 blocks in every10-minute period), and hence solo-mining or participating in small pools is more feasiblecompared to Bitcoin.

• Improved scalability. One of the main barriers to scalability is the effect of larger blocksizes on the network propagation delay. By removing the “race” aspect of mining, thepropagation delay becomes much less relevant, allowing the system to support larger blocksizes.

• Incentive-compatible verification. When a Bitcoin miner verifies and includes certaintransactions in a block that she creates, she collects the transaction fees as her reward.Other miners should also verify those transactions and thereby ensure that the chainthat they try to extend is valid, even though they do not collect any rewards for thosetransactions. Thus, rational miners can do a cost-benefit analysis, and may decide toskip the verification of transactions in prior blocks [19]. Indeed, this behavior appears tobe widespread among Bitcoin miners, as some miners lost a significant amount of fundsdue to the BIP66 softfork [21]. In Meshcash this risk is mitigated because miners do notengage in tight races against one another, therefore they have plenty of time to verify thetransactions that reside in the blocks that they endorse. Thus, it is less risky to have

8

transactions with complex scripts in Meshcash relative to blockchain protocols, though aquantification of this claim requires analysis that we do not provide in this work.

• Incentive-compatible propagation. A rational Bitcoin miner may decline to re-transmit transactions that were sent to her, thereby increasing the likelihood that shewill collect more fees when she eventually solves a block [2]. Such a behavior damagesthe performance of the Bitcoin system from the point of view of its users, as transactionswould become confirmed at a slower pace overall. In Meshcash, the transaction fees aredivided among all miners who created blocks in the recent layers, and hence an individualminer does not gain by keeping transactions secret.

• Resistance to bribe attacks. In Bitcoin, rational and malicious parties may benefitfrom offering bribes to other miners, by sending in-band messages in an anonymous fashion[4, 17]. A rational miner may fork a high-value block by collecting only some of itstransactions, thereby enabling the next miners to pick up the rest of the transactionsand earn extra fees. A malicious adversary may even put a “poisonous” transaction tx0in the honest chain and then offer high fees for blocks that include another transactionthat conflicts with tx0, and thus incentivize rational miners to work on a fork. Similarlyto the rational miner, this adversary may also mine blocks that do not include all thetransactions that honest miners collected in their chain, and in effect incentivize rationalminers to work on her fork (without offering overt bribes). In Meshcash, the fees areshared among all the blocks of a layer, and conflicting transactions do not invalidateblocks that reference them (cf. Section 2.4.4), hence these kinds of bribe strategies areineffective.

• Resistance to forking. An important property of our protocol (and one that, to thebest of our knowledge, is not satisfied by any other cryptocurrency) is that forking themesh is hard even for an attacker with a constant fraction of the computational power.This makes it much easier to argue about rational behavior—honest miners know thatwith high probability their work will not go to waste. In particular, it makes the standardselfish-mining attacks moot.

Informally, our Meshcash protocol achieves the following guarantees.

Theorem 1.1.1 (informal). If the hare protocol achieves fast consensus in the presence of adver-saries controlling q < 1/3 fraction of the computational power then the combined tortoise/hareprotocol achieves consensus and irreversibility against the same adversary.

For the formal statement see Corollary 3.3.7.

Theorem 1.1.2 (informal). When the adversary controls q < 115 fraction of the computational

power, then the tortoise protocol achieves consensus and irreversibility irrespective of the initialconditions and the properties of the hare protocol.

For the formal statement see Theorem 3.3.1.Note that because the tortoise protocol guarantees consensus irrespective of the initial condi-

tions, it is extremely robust to temporary violations of our security assumptions. For example,if the adversary normally has low computational power, but might be able to generate short“spikes”, the tortoise protocol guarantees that the system will recover. Moreover, we expect thesecurity of the protocol in practice to be much better than our worst-case analysis shows—ouranalysis is optimized for readability and asymptotic results rather than reducing the constants.

1.2. Related Works

The idea of replacing the blockchain with a DAG is not new; to the best of our knowledge theearliest consideration of it was in [20], though the treatment there was rather abstract.

9

1.3. Leader-Election-Based Protocols

Protocols based on leader election have an inherent asymmetry: loosely speaking, consensusis achieved by selecting some “special” party (the leader) in each round of the protocol. InBitcoin and several other permissionless protocols, the leader is the first party that successfullyto successfully solve a proof-of-work. Due to the possibility that more than one party will bespecial in a round, these protocols all imply some sort of “race”. We note that this is a propertyof the consensus protocol, not the reward mechanism; thus, in theory, a leader-election-basedprotocol can still be completely race-free. We classify the protocols into those in which thechosen leader receives all of the reward (these have an inherent race), and those in whichleaders have less power and the rewards are shared more equally between the parties.

1.3.1. Winner-takes-all

GHOST

The GHOST protocol of Zohar and Sompolinsky [34] modifies the Bitcoin best-chain rule totake into account valid blocks that are not on the longest chain. This means that less honestmining power goes to waste, and therefore GHOST can support a shorter interval betweenblocks without sacrificing security (cf. [13] for a formal analysis). The main motivation behindGHOST is to increase the transaction throughput. While this is also a secondary motivationfor Meshcash, our main design goal is to make the cryptocurreny race-free, so that incentive-compatibility is easier to achieve (and to prove). These concerns are not addressed in theGHOST protocol (e.g., GHOST is vulnerable to selfish mining attacks). With regard to frequentpayouts to small miners, GHOST improves upon Bitcoin since it allows an increase in the blockgeneration rate, but the growth rate of the main chain (i.e., the payout rate) is still bounded as afunction of the network propagation time. In fact, the main chain in GHOST grows at a slowerpace than what the propagation time would imply, due to the commonplace orphaned blocks.For example, if blocks are generated every 15 seconds on average and network propagation timeis 20 seconds, then the effective interval between blocks in the main chain in GHOST is atleast 55 seconds (this bound is implied by the tightness of [34, Lemma 6]). That is, the payoutrate is only about 10 times faster than Bitcoin. In Meshcash, on the other hand, we can easilysupport (say) 200 times the Bitcoin payout rate by using a layer width of 200. It should alsobe noted that GHOST exhibits the nonlinearity of rewards phenomenon, implying that a fastchain growth is likely to result in centralization instead of decentralization (see ??).

Bitcoin-NG

The Bitcoin-NG protocol of Eyal et al. [9] seeks to improve upon Bitcoin by offering fasterconfirmation time and better throughput. The incentive-compatibility aspects of the Bitcoin-NG protocol are not analyzed in [9], and Bitcoin-NG may indeed suffer from the same kind ofproblems that Bitcoin can potentially have. E.g., when a rational Bitcoin-NG miner sees thatthe microblocks before the most recent leader L have collected a relatively high amount of fees,she may opt to fork L by extending one of the intermediate microblocks that preceded L, andthus offer more fees so that the next leader will prefer her fork. Moreover, due to the chainstructure, the scalability improvements of Bitcoin-NG require sending microblocks of a smallersize as the transaction volume increases, otherwise the competing miners will be discouragedfrom collecting too many transactions. This becomes impractical for microblock sizes that aretoo small (the reported experiments in Bitcoin-NG were done with a transaction volume thatis at most 5 times greater than that of Bitcoin).

10

Blockchain as Bootstrap for Byzantine Agreement

Hybrid Consensus [30], Solidus [1], SCP [18], and Byzcoin [14] are protocols that harness theconsensus guarantees of a PoW based blockchain in order to select a committee of partieswho would then use a Byzantine agreement protocol (PBFT [6]) to achieve faster transactionirreversibility and higher throughput, in the permissionless setting. Thus, the objective of theseprotocols is a mirror image of our hare component in Chapter 2, i.e., we use an optional off-chain ABA protocol for a single bit (much simpler than PBFT) in order to help the PoW basedmesh achieve consensus in the first place. These four protocols guarantee security only if 2/3of every committee remains honest for at least τ time. If this new assumption is violated, thecommittee can reverse history and create unresolvable conflicts for a long period. Moreover,there is no definite cost for the adversary in attempting a collusion attack, since a failure wouldnot involve depletion of physical scarce resources. In comparison, Meshcash relies only on astandard hashpower majority assumption for security and is more robust against temporaryadversarial “power spikes”, as even a completely corrupt ABA committee can—at worst—slowdown consensus.

1.3.2. Reward-sharing

Inclusive Blockchains

The work of Lewenberg, Sompolinsky and Zohar [16] presents a cryptocurrency protocol that isbased upon a DAG instead of a chain, but unlike Meshcash it does not provide a mechanism forcooperative sharing of the block rewards. In fact, [16] explicitly states that it does not mitigateselfish mining attacks. Furthermore, [16] is still, in some sense, a blockchain protocol; thereis always a main chain, but parties will incorporate non-conflicting transactions from off-chainblocks that do not appear on the main chain.

DagCoin and Braidcoin

DagCoin [15] is another DAG-based proposal that focuses on possible improvements over Bitcoinin terms of faster security confirmations and greater throughput. Braidcoin [22] is a more recentDAG-based cryptocurrency construction, that aims to support more frequent blocks and thusfaster payouts to small miners. However, neither [15] nor [22] give a security analysis of theirprotocols.

FruitChain

The FruitChain protocol of Pass and Shi [29] is a blockchain-based scheme in which minerswho create blocks are not rewarded, but the blocks incorporate “fruits” and miners earn re-wards for the fruits that they create. Similarly to Meshcash, FruitChain attains a protocolthat is ε-incentive-compatible, by employing a scheme that shares the rewards among thosewho contributed to the recent ledger history. However, the analysis of [29] sidesteps the po-tential freeloading risk by using a model in which verification complexity has a negligible cost,and assuming that an honest majority follows protocol without having a clear rationale to doso. Additionally, [29] does not claim to improve upon the scalability aspects of Bitcoin, andFruitChain may potentially inherit the throughput limitations that chain-based protocols have.

1.4. Leaderless Protocols

Blockchain-free Ledger

A recent work by Boyen, Carr and Haines [5] presents a cooperative DAG-based cryptocurrencyprotocol, though it only considers security against a rational adversary. While it is not based in

11

leader-election, this protocol is not race-free—conflicts between honest parties may occur dueto network delays, in which case some of the honest parties will not receive a reward.

SPECTRE

The SPECTRE protocol of Sompolinsky, Lewenberg, and Zohar [33] is a DAG-based construc-tion, and hence it bears a resemblance to Meshcash in the way that each block commits to a listof earlier blocks. However, SPECTRE only guarantees consensus on blocks that were honestlygenerated, and makes no guarantees at all for maliciously-generated blocks. This relaxed guar-antee is enough to construct a crypto-currency supporting basic monetary transactions, but isinsufficient for more advanced uses (such as complex scripts), as they may require consensuson a total ordering of the blocks in order to evaluate even honest transactions. Meshcash,on the other hand, supports and in fact mitigates the potential risks that are associated withcomplex scripts, due to its race-freeness. A major design goal of SPECTRE is fast transactionirreversibility. While transactions are confirmed faster in Meshcash than in Bitcoin, this is notan aspect that Meshcash excels in. Another main goal that SPECTRE seeks to accomplish ishigh scalability. However, the SPECTRE protocol is not of a cooperative nature, and is there-fore more likely to exhibit the nonlinear rewards phenomenon when the transaction volumeincreases.

12

2. Protocol Description

2.1. Informal Overview

Meshcash is a modular protocol combining a fixed “tortoise” protocol to guarantee long-termconsensus and irreversibility with an interchangeable “hare” protocol that can aid in gettingquick consensus. In terms of execution, miners in the combined Meshcash protocol behavesimilarly to Bitcoin. As in Bitcoin, each Meshcash miner performs PoW computations togenerate blocks. Abstractly, the main distinction between Bitcoin and Meshcash is the structureof the “blockchain”. In Bitcoin, each block points to one previous block, forming a chain. Theconsensus rule is that the longest (heaviest) chain is the “correct” one. In Meshcash, thestructure is instead a layered DAG; each block belongs to a layer (it contains a layerid fieldthat declares the layer number) and points blocks previous layers. The consensus rule is slightlymore complex—for blocks that are in the recent past, Meshcash delegates consensus to thehare protocol (i.e., deciding which blocks are part of the “correct” history depends on thehare protocol rules). For blocks in the far past, we use the tortoise protocol rule, which takes aweighted “vote” of all subsequent blocks to decide whether or not a block is part of the canonicalhistory.

The mining protocol is actually much simpler, and avoids much of the consensus rule complex-ity: essentially, miners generate blocks pointing to every valid block they see in the previouslayers (the number of previous layers to include depends on the hare protocol). A detaileddescription of the protocol is specified in Section 2.4.

2.2. Modeling Generic BlockDAG Protocols

We generalize the model of Pass, Seeman and shelat [28] from blockchains to blockDAGs (thiscan also be seen as a generalization of the Kiayas and Panagiotakos model [13] from trees toDAGs, but using the asynchronous communication model of Pass et al.)

In the spirit of [28], we define a blockDAG protocol to be an interactive protocol where eachparticipant has a local state that contains a list of messages received (and the time at whicheach message was received). Based on this state, each participant constructs a graph of blockswith directed edges between them. In a blockDAG protocol, the graph is an arbitrary DAG (in[28] only chains are permissible, while [13] also allows trees).

For timing purposes, we identify each block with one of the messages in the state. Each blockis uniquely labeled by (a collision-resistant hash of) its contents: these include the labels of allblocks to which it points, as well as an arbitrary “content string” (which is interpreted in aprotocol-specific way; e.g., it can contain a list of transactions).

2.2.1. Validity.

A blockDAG protocol (like a blockchain protocol) defines a “validation function” for blocks;given a state, the validation function labels every block in the graph as either valid or invalid.We separate the validation function into two types of validity (both are required for a block tobe considered valid):

• Syntactic Validity: this can be computed based only on contents of block and its view(the subset of the DAG that is reachable from that block).

13

• Contextual Validity: everything that is not syntactic.

For example, the hash proof validity in Bitcoin is syntactic, while the chain selection rule iscontextual (it depends on whether a longer chain that does not include the block exists in thestate, something that cannot be determined from the block’s view by itself).

A blockDAG protocol’s validation function may allow valid blocks to have invalid blocks intheir view (this is not allowed in existing blockchain protocols). We define the valid DAG to bethe DAG restricted to valid blocks (note that this subgraph may not be connected).

2.2.2. Total Order on Blocks.

Unlike a chain, a DAG does not guarantee a unique topological ordering of its blocks. Thus, the“T last blocks” in the DAG may not be well-defined. To generalize the Pass et al. definitions,we will require the blockDAG protocol additionally to define a unique total order on its blocksthat is consistent with the topological ordering of the DAG (that is, for every pair of blocks Aand B such that A < B, there does not exist a directed path in the DAG from A to B).

2.2.3. Security Properties.

Our basic security properties are exactly as in [28]:

• consistency : with overwhelming probability (in T ), at any point, the valid DAGs of twohonest players can differ only in the last T blocks;

• future self-consistence: with overwhelming probability (in T ), at any two points in timer < s the valid DAGs of any honest user at r and s differ only in the last T blocks (asthey appear at time r);

• g-chain-growth: with overwhelming probability (in T ), at any point in the execution, thevalid DAG of honest players grew by at least T blocks in the last g rounds, where g iscalled the chain-growth of the protocol;

• µ-chain quality : with overwhelming probability (in T ), for any T consecutive blocks inany valid DAG held by some honest player, the fraction of blocks that were “contributedby honest players” is at least µ.

2.3. Weak Common Coins

Our protocols rely on a weak common coin as a black box (this is used both in the ABA protocolof Moustfaoui et al. [25] and to guarantee eventual consensus of the tortoise protocol when thehare protocol does not achieve consensus). A weak common coin with parameter pcoin ≤ 1

2 isa protocol with the following guarantees (probabilities are over the coins of the honest partiesand the adversary):

1. The probability that all honest parties have the same output and it is 0 is at least pcoin.

2. The probability that all honest parties have the same output and it is 1 is at least pcoin.

3. Before the beginning of the protocol, for every honest player P , the adversary cannotguess the output of P with probability more than 1− pcoin.

Note that this definition does not prevent the adversary from completely controlling the outputof all honest parties with probability 1 − 2pcoin. Moreover, the results of the coin toss are notrequired to be verifiable (i.e., an honest party might not be able to prove to another party thatits output was correct), and honest parties might not know whether they are in consensus ontheir output or not.

14

2.3.1. Implementing a Weak Common Coin Based on Proof-of-Work.

We can implement a weak common coin based on any proof-of-work protocol (assuming thePoW hashes are the output of a random oracle) in which block publication can be modeled asa Poisson process with rate proportional to computational power. Assume blocks are generatedas a Poisson process with rate λ for an interval of length T , and that the network propagationdelay δ is defined as in Section 2.4.4. Our protocol is as follows, for party P starting at time t:

1. Wait until time t + T . Denote SP the set of fresh1 syntactically valid blocks received inthe interval [t, t+ T ].

2. Sort the blocks in SP by their hash values. P outputs the LSB of the minimum block inSP (according to the sort order).

Lemma 2.3.1 gives the resulting parameters for the weak coin.

Lemma 2.3.1. If the rate of blocks generated by the adversary is at most qλ, then for everyconstant c > 1 our protocol generates a weak common coin with parameter pcoin ≥ c−2 · 1−q2 ·T−2δT+2δ − neg(λ).

Proof. Denote S−P the set of blocks received by P in the interval [t + δ, t + T − δ] and S+P the

set of blocks received by P in the interval [t− δ, t+ T + δ].By our communication assumption, honest nodes will agree on the time at which they received

every message up to a difference of δ. Thus, for every pair of honest parties P.P ′, we must haveS−P ⊆ SP ′ and SP ⊆ S+

P ′ .This means that if A is the minimum block of S+

P and A ∈ S−P , then for every honest P ′ itmust be the minimum block for SP ′ (if SP ′ contains a lower-weight block, then it would alsobe in S+

P , contradicting the minimality of A). Let S∗P ⊆ S−P be the subset of blocks that werehonestly generated.

If the minimum block of S+P is in S∗P , then the LSB (and hence the coin) is uniformly random,

even conditioned on the set of published blocks (formally, we assume the hashes are the outputof a random oracle; we can ignore the LSB in the sort order to make it fully independent).Moreover, since S∗P ⊆ S−P , all honest parties agree on the coin. Let 2pcoin be the probabilitythat this occurs; then the protocol is a weak common coin with parameter pcoin.

To lower-bound pcoin, note that since the hashes are the output of a random oracle, we canthink of the sorting as a random shuffle of all the blocks in S+

P . So 2pcoin ≥ E[|S∗P |/|S

+P |].2

By our block rate assumption |S+P | has a Poisson distribution with parameter λ+ = λ · T+2δ

T ,

while |S∗P | is Poisson with parameter λ∗ = λ · (1− q) · T−2δT . The ratio of the two parameters is

λ · (1− q) · T−2δT

λ · T+2δT

= (1− q) · T − 2δ

T + 2δ

For all c > 1, let pc−(λ) = PrX∼Pois(λ) [X ≤ λ/c] and pc+(λ) = PrX∼Pois(λ) [X ≥ c · λ]. Notethat for every constant c, both pc−(λ) and pc+(λ) are negligible in λ. Then

E[|S∗P |/|S+

P |]≥ Pr

[|S∗P |/|S+

P | ≥ c−2 λ

∗

λ+

]c−2(1− q) · T − 2δ

T + 2δ

≥(1− pc−(λ∗)− pc+(λ+)

)c−2(1− q) · T − 2δ

T + 2δ

≥ c−2(1− q) · T − 2δ

T + 2δ− neg(λ) .

1To ensure blocks are not pre-generated by the adversary, we require blocks to include a “freshness indicator”.This can be, for example, pointers to all blocks received before time t, or a special transaction that is generatedjust before time t.

2formally, we condition on |S+P | > 0, but this event occurs with overwhelming probability so for clarity we omit

it.

15

2.4. Modular (Tortoise) Protocol

2.4.1. Overview.

Our high-level construction combines a “tortoise” protocol (that we describe below) with anarbitrary “hare” protocol. The long-term “tortoise” protocol guarantees consistency, regardlessof the hare protocol’s properties. For every block X on whose validity honest parties agreeat the end of the hare protocol, the tortoise protocol will ensure that all honest parties willcontinue to agree (and will not change their opinion in the future).

1. If the hare protocol is race-free (i.e., honest blocks are always accepted as valid), thecomposed protocol will also be race-free.

2. If the hare protocol guarantees agreement on all blocks with probability p, the composedprotocol will guarantee irreversible consensus by the end of the hare protocol with prob-ability p− ε (for some negligible ε).

Our tortoise protocol has the property that the opinion of a node about the validity of anyblock in its view depends only on the view itself (and not on additional private context). Thus,given the node’s view, we can “simulate” its computation and reconstruct its opinion about anyblock. To make this possible, when mining on a block, the block’s content will include “view”edges to every other block in the node’s view that cannot be reached by existing edges (i.e.,edges to the “heads” of the blockDAG).

Layers.

The DAG defined by our tortoise protocol uses the notion of layers to partition blocks intosets. Layers are sequentially numbered, and we require each block to include its correspondinglayer number as part of its content (i.e., this number is included in the PoW that gives theblock its “name”). We also require honest parties to maintain weak consensus about a layercounter, signifying the current layer number. By weak consensus, we mean that if any honestparty increments its own layer counter at time t (according to its own local clock), every otherhonest party will increment its counter to the same value by time t + δ (according to the firstparty’s local clock).

Note that the event that triggers the layer counter increment can be simply the passage oftime, but it can also depend on each party’s view (since we assume δ-bounded delays in thenetwork, this will still guarantee weak consensus). In our case, the layer counter will incrementwhenever the node can see sufficiently many syntactically valid blocks in the current layer.

Block Weights.

For the purpose of computing the “weight” of a set of blocks, we sum up the weights of eachblock in the set. The weight of a block is the expected amount of work (e.g., number of hashevaluations) required to generate a block of the same difficulty. That is, if the threshold forblock generation is p for layer i, the weight of all blocks in layer i is exactly 1/p.

2.4.2. Hare Protocol Requirements.

For simplicity, we will assume the hare protocol uses the same notion of layers and layer counter(this is indeed the case for the protocols we propose in this paper). We have two main require-ments from the hare protocol:

16

• Preventing pre-generation of blocks. To guarantee convergence, we need a bound on thenumber of syntactically valid blocks the adversary can “pre-generate” (i.e., blocks whoselayer number is in the future). The tortoise protocol inherits its syntactic-validity rulesfrom the hare protocol, so these rules must ensure the bound. For simplicity, in this paperwe assume all hare protocols require a minimum out-degree rule: blocks in layer i aresyntactically valid only if they have at least Tmin syntactically valid layer i− 1 blocks intheir view.

• Limited [t, s]-consistency: ideally, we want that for every block X claiming to be in layer i,all honest nodes whose layer counter is in the interval [i+t, i+s] are in consensus about thevalidity of X, and this consensus does not change in the interval [starti+t, starti+s+1).

2.4.3. Tortoise Protocol Description.

Let Π be a qualifying hare protocol with output interval [t, s]. To construct the correspondingtortoise protocol, we modify the validation function and graph construction for Π. Let i be thecurrent value of the layer counter:

• Add view and voting edges. In addition to the edges specified by Π, every block generatedby an honest player with DAG G will now include special edges:

– view edges: an edge to every “head” block in G (i.e., blocks that have in-degree 0).These edges ensure that the view of a block generated by an honest party includesthe entire view of that party.

– voting edges: an edge to every valid block in layer i− s through i− t, where validityis computed using Π’s validation function (note that if validity can be inferred fromthe DAG itself, then explicit voting edges are not necessary).

Π will ignore the extra edges.

• Add coin bits. Every block adds a coin to its header. The value of the coin is determinedby a weak common coin protocol (cf. Section 2.3) that starts at time starti + δ. TheCoin bit is set to 1 if the coin was 1 and 0 otherwise;

• Add “before coin” bit. This bit indicates whether the block was generated before the coinprotocol ended (this is used to “abstain” from voting in cases where the coin bit matters).

• Add “early block” bit. Every block adds a additional bit to its header to specify whetherthe block was generated within less than δ time after the start of the layer. (this is usedto abstain from voting in cases where the late blocks from the previous layer might makea difference.)

• “Block Voting”. For every block A in layer i′ < i−s, the validity of A will be determined bya simple “election”. Every syntactically valid block Y claiming to be in layers i′+1, . . . , i−1is given a “vote”, in the set {−1, 0, 1}, as long as Y was received by time starti+δ. BlockA will be considered valid if the weighted sum of the votes for A is positive, where we usethe block weights derived from their PoW. The algorithm to determine how a block Xvotes is recursive. Consider a block X in layer j > i′. The basic voting rules depend onthe distance (in layers) between X and A:

– If j < i′ + t, then X votes 0 (it is neutral with regards to A since it was generatedbefore the hare protocol guaranteed consensus about A).

– If j ∈ {i′ + t, . . . , i′ + s}, then X votes 1 if X has a voting edge to A and −1 if itdoes not.

17

view edge

voting edge

AB

+1

+1

Consensus Interval

+1

-1

-1

Hare Protocol (Π)

Tortoise Protocol

i-s i-t ii-s-1

Π edge

i-2 i-1

Figure 2.4.1.: In block voting, the validity of any block is determined by election. In the figure,block A considers block B as valid because the sum of block votes in its view infavor of B is positive

– Otherwise (j > i′ + s), consider all the blocks in X’s view and sum their weightedvotes; X votes 1 if the sum is positive, −1 otherwise.

To ensure convergence even if the hare protocol fails to achieve consensus between honestnodes, we also add a randomized voting rule when there is not a clear majority in eitherdirection:

– If j > i′+ s and the weighted sum of votes for the blocks in X’s view is in the range[−θ, θ], X votes 1 if the coin bit is set to 1 and -1 otherwise (unless “before coin” bitis set to 1 in which case it votes 0).

2.4.4. Protocol Parameters.

The Meshcash protocol has several tunable parameters which are set globally and remain fixedonce the protocol has started:

1. Tmin: The minimum number of blocks in a layer. A higher number increases the robustnessof the protocol and decreases the interval between rewards for miners, at the cost ofincreased communication overhead.

2. `: The average length of a layer interval. This is kept approximately constant by adjustingthe difficulty parameter according to estimates of the total hash rate (similarly to Bitcoin’smechanism for difficulty adjustment).

3. δ: A bound on the combined network propagation time/local clock differences betweenhonest nodes. If any honest node sees a block at time t according to its local clock, allhonest nodes are guaranteed to receive the block by time t+δ according to their own local

18

clocks. (Note that the actual network propagation delay is not tunable, but the boundwe use is.)

4. tcoin: Bound on the time required to execute the weak coin protocol (in multiples of δ).

5. θ: A threshold for using the randomized block-voting protocol. If the vote margin (sumof the votes) for a block is less than θ (in absolute value) nodes will vote according tothe output of the weak coin (instead of using the majority). A larger θ will guaranteeconvergence faster from arbitrary initial conditions, but will make it easier for the adver-sary to invalidate honest blocks (if the honest block has less than θ margin it might beinvalidated by coin flip).

2.4.5. Protocol Concepts.

Syntactic Validity of Blocks.

Syntactic validity of a block can be decided purely based on the block’s visible mesh (i.e., itdoes not depend on “context”, such as the time it was received or other blocks in the same orfuture layers). There are several conditions for a block to be syntactically valid in layer i:

1. It is not pointing to a syntactically invalid block.

2. The block has a valid proof-of-work for layer i’s difficulty level (note that the difficultylevel is a function of the view).

3. Its view contains at least Tmin syntactically-valid blocks in layer i− 1.

4. Transactions included in the block are valid according to the block view.

Layer Boundaries.

Honest nodes maintain a layer counter which determines the serial number of the “currentlayer”. The layer counter is initialized to 1 on receiving the genesis layer. The layer counter isincremented to i+ 1 when at least Tmin syntactically-valid blocks were received in layer i.

The honest start for layer i, denoted starti, is the time at which the first honest nodeincrements its counter to i.

Transactions in Blocks.

Each block contains a list of transactions. Unlike Bitcoin, however, the same transaction mayappear in multiple blocks; what matters for the purpose of considering the transaction valid iswhether it is included in a layer. We consider a transaction L to be included in layer i (accordingto block A) if i is the first layer in which L appears in at least one of the valid blocks of A’s view.There is a fixed cap on the number of transactions that can be included in a block. The capcan be easily adjusted proportionally to the transaction publication rate in the system, and canaward a bonus. Every miner selects transactions to include in a block according to protocol 1.

Conflicting Transactions and Validity.

There are no conflicts between blocks due to the transactions included in them. However, thetransactions themselves may conflict (e.g., double spending). If two conflicting transactions areincluded in the same layer, the first one (according to the total ordering of blocks) is consideredvalid and the second invalid.

19

Protocol 1 Honest Mining Algorithm (transaction selection)

Let i∗ be the latest layer about whose contents we are confident.Let n be the cap for the number of transactions that can be included in a block.Add a transaction L to the currently mined block up to the cap n if:

• L is not included in a layer j ≤ i∗ in our view.

• There does not exist a transaction L′ conflicting with L that is included in a layer j ≤ i∗in our view.

After reaching the cap, swap a transaction L with a transaction L′ appearing in the currentlymined block if L is not included in any published block up to the current layer and L′ is.

Distributing Rewards

We stress that the system for distributing the block rewards is completely independent ofthe security properties of Meshcash. In particular, we can choose any method for allocatingthe rewards that maintains the race-free property while ensuring incentive compatibility ofMeshcash. We propose such as scheme in Section 7.4.

2.5. Security Proof Overview for Tortoise Protocol

In this section we give an informal overview of our security proof and intuitions.

2.5.1. Irreversibility.

At a high level, we can view the tortoise protocol as a voting process: every new block “votes” foror against all previous blocks. The irreversibility of the tortoise protocol stems from the fact thatonce consensus is reached, all honest users will vote in the same direction; this causes the marginof votes (the difference between positive and negative votes) to increase linearly with time.Similarly to the Bitcoin race analysis, an adversary can only reverse history by generating enoughvotes to overturn the current consensus. However, since the adversary generates blocks at alower rate than the honest parties, the probability that this can be done decreases exponentiallywith time.

The main wrinkle here is that the adversary might keep a “reserve” of unpublished blocksand then publish them at a later date to reverse what seems like a consensus with large margin.However, in order to reverse the honest users’ consensus about a block A, the adversary’s reservemust contain “future” blocks (whose layer id is greater than that of block A)—since only futureblocks have a “vote” regarding A. We show this cannot happen by bounding the adversary’sability to keep a large reserve of “future” blocks. In Corollary 3.2.4, we show that, irrespectiveof the initial conditions, there will be a layer in which the adversary’s future reserve reachesa steady-state (see Definition 3.2.1). Additionally, we use the fact that with overwhelmingprobability no layer is “too long” (see Lemma 3.1.6) to prove that once in a steady state, theprobability that the adversary leaves it is negligible; since in order to generate enough “future”blocks, the adversary needs a long layer-interval (see Corollary 3.2.5).

Finally, in Theorem 3.3.2 we formalize the race-analysis and show that the vote margin willgrow linearly with the number of layers.

2.5.2. Pure Tortoise Consensus.

The harder part of the proof is to show that consensus will always (eventually) be achieved, evenunder active attack. Intuitively, the difficulty of guaranteeing consensus is due to the adversary’sability to “play” with network latency. By sending blocks near the “edge” of a layer, some honest

20

parties would consider the block valid, while others would not. The voting scheme does nothelp in this instance, since the honest parties now disagree on the votes themselves (each voteis a block). Further complicating the analysis is that the adversary can generate and maintaina “reserve” of valid blocks (for the current or future layers) that can be used strategically bythe adversary to cause disagreements among the honest miners on the contents of the layers.

Our main technical theorem, Theorem 3.3.1, shows that for any initial reserve of blocks(here we do not care about whether they are in the future or the past), the tortoise protocolwill eventually arrive at consensus. We do this by a case analysis on the adversary’s strategy,showing that the adversary has to “spend” her reserve in order to keep honest parties fromagreement. Since the adversary’s ability to generate new blocks is limited, either the honestparties will reach consensus, or the adversary will exhaust her reserve (in which case the honestparties will also reach consensus).

At a lower level, to show that the adversary must spend blocks from its reserve, we considerbasically the following cases:

Case 1: There is already a large vote margin. In this case, the adversary has to spend at leastthat much blocks from her reserve to prevent consensus.

Case 2: The vote margin is small. In this case, some honest parties will use a coin-flip to choosehow they vote, while others might see a large enough margin that they vote disregardingthe coin. If the adversary spends too few blocks, we show that all parties that disregardthe coin will vote in the same direction, so if the adversary does not guess the outcome ofthe coin correctly, all honest parties will agree.

2.5.3. Hare & Tortoise Consensus.

Theorem 3.3.1 does not use the hare protocol at all. Our bounds on the adversary’s ability topre-generate blocks (i.e., the bound on the future reserve) allow us to show that once we reachthe future reserve steady-state, any hare protocol assuring limited consistency combined witha tortoise protocol will guarantee consistency and future self-consistency (see Corollary 3.3.3).The idea here is straightforward—once we have achieved consensus in the hare protocol, thehonest parties all vote in the same direction;

2.5.4. Race-Freeness.

To show that honestly-generated blocks are always in the consensus, we need to lower-boundthe number of honest blocks in every layer (since honest blocks are “guaranteed” to vote forother honest blocks). We can do this when the adversary is in a future reserve steady-state, byshowing that no layer is too short (since the adversary can only shorten a layer by “dumping”blocks from its future reserve), which implies that the honest parties have enough time togenerate blocks in every layer (see Lemma 3.3.4).

2.6. Hare Protocols

We propose several different hare protocols. The first is almost trivial, but guarantees consensusonly when all participants are honest. The others are more complex, and use an off-chainasynchronous byzantine agreement protocol (ABA) to achieve a more robust consensus, evenunder malicious attack.

2.6.1. Simple Hare Protocol.

The simple hare protocol does not define additional edges (beyond the view and vote edgesfrom the tortoise protocol). Its contextual validity rule is: “a block A claiming to be in layer iis valid iff it was received in the interval (starti − δ, starti+1 + δ)”.

21

Lemma 2.6.1. The simple protocol has [1, 1]-limited consistency for honestly-generated blocks

Proof. If all parties are honest, layer-i blocks are always mined in the interval (starti, starti+1),so every honest party will receive them in the interval (starti − δ, starti+1 + δ) and considerthem valid.

Note that while there is guaranteed consensus about honestly-generated blocks within a singlelayer, an adversary can create disagreement by publishing blocks near the layer-interval bound-ary, so that some honest parties receive them before the boundary and some after. In this case,we have to rely on the tortoise protocol to achieve consensus.

2.6.2. Byzantine-Agreement-Based Hare Protocols.

Overview.

The basic idea behind the ABA-based hare protocols is to use the blocks published in a layer toselect a committee that will then run an off-chain “traditional” byzantine agreement protocolto achieve consensus about the validity of each block in the layer. The off-chain protocol canbe performed using direct links, so can be quite fast; at the end of the protocol, the committeewill append digital signatures (using public keys provided in their published blocks) testifyingto each block’s validity. The contextual validity rule is now “a block A claiming to be in layeri is valid iff it has valid signatures from a majority of the layer-i committee members”.

There are two main difficulties to overcome in using this paradigm: the first is that we donot have consensus about the committee members; standard ABA protocols assume there isagreement on the participants. We solve this problem by using an identity-free ABA protocol(we use the protocol of Mostfaoui et al [25]) and a bound on the total number of participants.Every party will interact with the committee members it recognizes, and consider any othersas faulty. The properties of the ABA protocol guarantee that security still holds as long as thenumber of honest parties is 2/3 of the maximal number of participants.

The second problem is that the ABA protocol uses a “weak random coin”: this is usuallyimplemented via a cryptographic protocol that requires trusted setup, which we do not have.However, there are some constructions that do not require setup. Alternatively, we can imple-ment the weak-random coin using the blockchain itself (unfortunately, our coin implementationhas a minimum time per coin flip, so each round of the ABA protocol has a minimum time aswell. However, the ABA protocol we chose needs a very small number of rounds in expectation,so with high probability the total time will still be less than one layer interval. We describeseveral ABA-Based Hare protocols in Chapter 5 (which trade increasing complexity for bettersecurity assumptions).

2.7. Communication/Storage Optimizations.

Note that the transmitted and stored transaction data does not need to grow linearly with thenumber of blocks, because the miners can store each transaction once, regardless of how manyblocks it appears in; the blocks themselves need only contain a transaction id (computed as acollision-resistant hash of the transaction data).

In Bitcoin, the average size of a transaction is about 525 bytes3 , while the transaction idhash is 32 bytes, so this reduces the data size needed by a factor of ≈ 16. Notice that thisoptimization reduces both the communication complexity and the computational complexity ofcomputing the hashes of blocks. Furthermore, miners can refer to transactions in their local

3The average size of a block is about 900 kilobytes and the average number of transactions in a block isabout 1700, see also https://tradeblock.com/blog/analysis-of-bitcoin-transaction-size-trends andhttp://p2sh.info/dashboard/db/non-standard-outputs-statistics.

22

storage according to their index among all the transactions that they maintain, so the localstorage complexity (not communication complexity) can be 64 times smaller than the worstcase if we assume that each index is 8 bytes.

Note that in the current Bitcoin blockchain, transactions are the dominating factor in termsof storage. By using this optimization, the communication overhead for a 100-fold increasein block rate (compared to Bitcoin) will be about 6 times greater, while the storage overheadfactor can be less than 2.

2.7.1. Efficient Verification Algorithm.

Since all blocks should gain an overwhelming voting margin after O(1) layers (except whenthe network is under an active attack), it is expected that irreversibility will take hold quickly.Therefore, miners can maintain a separate structure only for tentative past blocks, i.e., old datain the history can be pruned and nodes will record that the more recent blocks are valid withoutactually storing the older blocks. However, in order to make sure that the adversary cannotexploit the efficient verification algorithm, honest nodes need to be able detect that they prunedtoo much old data and thus request missing data from peers that do not prune (similarly toarchival nodes versus nodes that maintain only the UTXO set in Bitcoin).

23

3. Proof of Security

3.1. Notation

For the proofs and analysis we introduce some additional notation.

Tortoise Protocol Variables.

We define the following random variables:

• Yj : the number of maliciously-generated blocks in the interval [startj + δ, startj+1 + δ]

• Zcoinj : the number of non-abstaining blocks in layer j. this is at least the number of

honestly-generated blocks in the interval [startj + tcoinδ, startj+1] (for tcoin definition,see Section 2.4.4)

Tortoise Protocol Variables Bounds.

We also define the bounds on these variables, such that the following are guaranteed withoverwhelming probability (in Tmin):

• `∗ε: an upper bound on the duration of a layer. ∀j : startj+1 − startj ≤ `∗ε. We choose

`∗ε = (1+ε)· `1−q +2δ. We parameterize by ε; for every constant ε, Lemma 3.1.6 guarantees

that the probability of exceeding the bound is negligible. Note that using the assumptionsection above, `∗ε < (1 + ε)1410`

• Y ∗ε : an upper bound on the number of maliciously-generated blocks ∀j : Yj ≤ Y ∗ε exceptwith probability Pr

X∼Pois(q· `∗ε`·Tmin

) [X ≥ Y ∗ε ] (for this to be negligible, we take Y ∗ε ≥

(1 + ε)2 · q · ( 11−q + δ

` ) · Tmin ≥ (1 + ε)q · `∗ε` · Tmin for some constant ε).

• `−ε : a lower bound on the duration of a layer in which the adversary is in the future-reserve steady-state. ∀j s.t. the adversary is in its future-reserve steady-state, startj+1−startj ≥ `−ε (we choose `−ε ≤ (1− ε) · (Tmin−F ∗)

Tmin` and apply Lemma 3.3.4 here).

• Z∗ε : a bound on the number of honestly-generated blocks in interval [startj+δ, startj+1].

∀j s.t. the adversary is in its future-reserve steady-state, Zcoinj ≥ Z∗ε except with prob-

ability PrX∼Pois

((1−q) `

−ε −tcoinδ

`·Tmin

) [X ≤ Z∗ε ] (for this to be negligible, we take Z∗ε ≤

(1− ε)(1− q) `−ε −tcoinδ

` Tmin for some constant ε).

Tortoise Protocol Assumptions.

For our analysis, we assume the following:

• q < 1/15: a bound on the computational power of the adversary (the hash-rate of theadversary is at most a q fraction of the entire network’s hash rate). This is required toguarantee convergence by the tortoise protocol when the plugged-in hare protocol fails toreach consensus.

24

• ` > 4δ: a lower bound on the expected layer time w.r.t. the network delay. Even ifassuming a large network delay time (e.g. δ < 30 seconds) resulting in ` > 2 minutes, itstill allows a faster confirmation time compared to Bitcoin.

Definition 3.1.1 (Adversary’s Reserve). The adversary’s reserve at time τ is the set of syntac-tically valid blocks generated by the adversary that have not been published up to time τ . Theadversary’s reserve for a block A claiming to be in layer i is the subset of blocks in its reservewhose vote for A is not neutral (i.e., blocks in layers after i + t). For j > i, we denote Rj(i)the adversary’s reserve for blocks in layer i at time startj + δ (not including blocks that werepublished at time startj + δ).

Definition 3.1.2 (Adversary’s Future Reserve). The adversary’s future reserve at time startiis the subset of blocks in its reserve that claim to be in future layers (i or greater). We denoteFi the adversary’s future reserve at time starti.

Definition 3.1.3 (Adversary’s Late-Published Blocks). The adversary’s late-published blocks,∆j−1, is the number of blocks published by the adversary from its reserve at time startj + δ.

For any layer i < j, if the honest parties on layer j agree on a block A claiming to be inlayer i, the maximal number of blocks that can counter-vote their agreement on A is ∆j−1. Weassume w.l.o.g. that all of the adversary’s blocks are late-published.

Definition 3.1.4 (Visible Confirmation Margin). The ith (visible) confirmation margin for ablock A claiming to be in layer j < i is the sum of the votes for A from all syntactically valid

blocks in layers i′ ≥ j that were received by time starti + δ. We denote M(P )i (A) the ith

confirmation margin for block A as seen by party P (we may omit P when it is clear from thecontext).

Informally the confirmation margin for a block is how confident we are about the block’svalidity (or invalidity).

Definition 3.1.5 (Actual Confirmation Margin). Let Pmaxi denote P such that |M (P )

i (A)| is

maximized and M(max)i (A) = M

(Pmaxi )

i (A). The ith actual confirmation margin for a block A

claiming to be in layer j < i is M †i (A) = M(max)i (A)−∆i−1 − |Ri(j)|.

If the actual confirmation margin is large enough (greater than θ), it means all honest partiesagree on the validity of A, and the adversary does not have enough blocks in its reserve tochange this opinion. This is used to bound any future attempts by the adversary to change thevalidity of block A (see Theorem 3.3.2).

Lemma 3.1.6 states that with overwhelming probability in Tmin, we can bound the length ofany layer time interval by `∗ε = (1 + ε) · `

1−q + 2δ.

Lemma 3.1.6. For any layer i and ε > 0,

Pr[starti+1 − starti > `∗ε] ≤(

2(1+ε)−ln(1+ε)−1

ln 2

)−Tmin

(see Section 3.1 for `∗ε definition)

Proof. By definition,[starti, starti+1

]describes the time interval between any honest party

knowing Tmin blocks on layer i− 1 and any honest party knowing Tmin blocks on layer i.The honest parties must start generating layer i blocks before starti+δ. Since the adversary

cannot delay any honestly-generated block by more than δ, the best strategy it has for increasingthe layer interval is to refrain from publishing blocks. The difficulty adjustment for the protocolensures that the expected time for the entire network (including the adversary) to generate Tmin

blocks is `. Since the adversary controls at most a q fraction of the hash power, the honest

25

parties by themselves will generate at expected rate (1− q)Tmin per `, or Tmin in an interval oflength `

1−q . These Tmin blocks will be seen by the entire network at most δ time after generated.

Thus, the probability that any interval length is longer than `∗ε = (1 + ε) · `1−q + 2 · δ can be

tail-bounded. According to Poisson tail bounds (cf. Appendix A), for all c > 1,

PrX∼Pois(cλ)

[X ≤ λ] ≤ 2−λc−ln(c)−1

ln 2 =(

2c−ln(c)−1

ln 2

)−λ.

In particular, for c = (1 + ε), λ = Tmin

PrX∼Pois((1+ε)Tmin)

[X ≤ Tmin] ≤(

2(1+ε)−ln(1+ε)−1

ln 2

)−Tmin

.

3.2. Bounding the Layer Interval and the Size of the Future Reserve

Our tortoise consensus proof requires a bound on the size of the future reserve (otherwise theadversary effectively has unlimited computational power, since publishing blocks from the futurereserve is “free” for the adversary).

Definition 3.2.1 (Future reserve steady-state). We say the adversary is in a future reservesteady-state at time starti if |Fi| ≤ F ∗ = 3 · q

1−q · Tmin.

Lemma 3.2.2. For every ε > 0 and i > 0, if the adversary controls at most q-fraction of thecomputational power, then

Pr

[|Fi+1| > (1 + ε)

`∗ε`· qTmin

∣∣∣∣ Fi ∩ Fi+1 = ∅]< 2 ·

(2

(1+ε)−ln(1+ε)−1ln 2

)−min( 1q, 1+ε1−q+

2δ`)·qTmin

Proof. If Fi ∩ Fi+1 = ∅, the adversary cannot have any blocks of layer i + 1 in its reserve attime starti (otherwise they would be in Fi ∩ Fi+1). Thus, Fi+1 can only contain blocks thatwere generated in the interval [starti, starti+1].

We will bound Fi+1 by bounding the length of the layer interval, and then using a Poissontail bound to bound the number of blocks the adversary can generate in that interval. LetBadlong be the event that starti+1 − starti > `∗ε (i.e., the layer-interval is “too long”). ByLemma 3.1.6, Pr [Badlong] < neg(Tmin).

LetBadfast be the event that the adversary generated “too many” (more than (1+ε)· `∗ε` ·qTmin)

blocks’ in the interval [starti, starti + `∗ε]. Denote X the number of blocks generated by theadversary in the interval . Since the adversary’s block generation is bounded by a Poissonprocess with parameter `∗ε

` · qTmin for an interval of length `∗ε,

Pr [Badfast] = PrX∼Pois

(`∗ε`·qTmin

)[X > (1 + ε) · `

∗ε

`· qTmin

]

≤(

21+εln 2

( 11+ε

+ln (1+ε)−1))− `∗ε

`·qTmin

=(

21+εln 2

( 11+ε

+ln (1+ε)−1))−( 1+ε

1−q+2δ`

)·qTmin

(where the final identity follows from the definition `∗ε = (1 + ε) · `1−q + 2 · δ).

Since |Fi+1| is a subset of adversary blocks created during [starti, starti+1], we must have

|Fi+1| < |X| < (1 + ε) `∗ε` · qTmin unless either Badlong or Badfast occurred.

26

Thus, by the union bound,

Pr

[|Fi+1| > (1 + ε)

`∗ε`· qTmin

∣∣∣∣ Fi ∩ Fi+1 = ∅]≤ Pr [Badlong] + Pr [Badfast]

≤(

2(1+ε)−ln(1+ε)−1

ln 2

)−Tmin

+(

2(1+ε)+ln(1+ε)−1

ln 2

)−( 1+ε1−q+

2δ`

)·qTmin

≤ 2 ·(

2(1+ε)−ln(1+ε)−1

ln 2

)−min( 1q, 1+ε1−q+

2δ`)·qTmin

which is negligible in Tmin

Theorem 3.2.3. For every initial future reserve Fi0, the adversary will have no far-futureblocks after |Fi0 | ·

1−q(1−2q)Tmin

layers (in expectation).

Proof. First, note that since every syntactically valid block in layer j must point to Tmin syn-tactically valid blocks in layer j − 1, if Fi includes any blocks from layer j ≥ i + 1 then itmust include at least Tmin blocks in each of the layers i, . . . , j − 1. Thus, if the adversary has“far-future” blocks in Fi, its future reserve will shrink by at least Tmin blocks at every layerboundary (since Fj does not contain any blocks in layers less than j).

Even if the adversary uses all of its hash power to increase its reserve, the expected layer-interval length will be at most `

1−q ; thus, the adversary’s expected block-generation per layer-

interval is bounded by q1−q · Tmin < Tmin (this is a very loose bound that ignores difficulty

adjustment). If the adversary has far-future blocks in Fi, the size of Fi will decrease, in expec-tation, by at least Tmin − q

1−q · Tmin = 1−2q1−q · Tmin at every layer-interval, so the adversary will

be left with no far-future blocks in expectation, within |Fi0 | ·1−q

(1−2q)Tminlayers.

Corollary 3.2.4 states that for any initial reserve, the adversary’s future reserve will eventuallyshrink to the steady-state. The total number of layers until the adversary future-reserve isbounded depends only on the size of its initial reserve and fraction of the total hash power).

Corollary 3.2.4. For every initial future reserve Fi0, with probability 1 there will be somei∗ > i0 such that |Fi∗ | < F ∗.

Proof. By Theorem 3.2.3, (in expectation) the adversary will have no far-future blocks after|Fi0 | ·

1−q(1−2q)Tmin

layers. Let i′ be the layer in which the adversary no longer has far-futureblocks. By Lemma 3.2.2 with overwhelming probability:

|Fi′+1| ≤ (1 + ε)`∗ε`· qTmin

By definition, for any ε > 0, `∗ε = (1 + ε) · `1−q + 2 · δ. Therefore,

|Fi′+1| ≤ (1 + ε)

((1 + ε) · 1

1− q+

2δ

`

)· qTmin

≤(

(1 + ε)2 +(1 + ε) · (1− q) · 2δ

`

)·(

q

1− q

)Tmin

≤((1 + ε)2 + (1 + ε)

)·(

q

1− q

)Tmin

where the last bound is by Section 3.1 (δ < 4` and q < 115). By setting ε = 0.25 we get:

|Fi′+1| < 3

(q

1− q

)Tmin = F ∗

27

Corollary 3.2.4 proves that whatever the initial conditions, the adversary will eventually reachsteady state. Corollary 3.2.5 proves that once the adversary reaches steady-state, it will staythere except with negligible probability:

Corollary 3.2.5. For any layer i, if |Fi| < F ∗, then

Pr [|Fi+1| > F ∗] <(

2(1+ε)−ln(1+ε)−1

ln 2+1)−( 1+ε

1−q+2δ`

)·Tmin

Proof. If |Fi| < F ∗ < Tmin, the adversary cannot have far-future blocks (at least Tmin layeri blocks are required to generate layer i + 1 blocks). Since having no far-future blocks, byLemma 3.2.2

|Fi+1| ≤ (1 + ε)`∗ε`· qTmin

except with negligible probability. Using the same analysis as in Corollary 3.2.4, when ε = 0.25

|Fi+1| < 3

(q

1− q

)Tmin = F ∗

.

3.3. Consistency and Future Self-Consistence (Irreversibility)

Theorem 3.3.1. If

q ≤ min

(`

`∗ε· 2θ

Tmin· pcoin; 1− `

`−ε − tcoinδ· 4θ

Tmin

)then for every initial reserve Ri0(A) and every initial margin M

(max)i0+1 (A), and every k > 0 there

exists i∗ > i0 such that with probability 1 it holds that M †i∗(A) > θ + k.

Since the proof of Theorem 3.3.1 is involved, we defer its presentation to Chapter 4. We usethe following parameters’ values:

1. By Section 3.1, `∗ε < (1 + ε)1410`. Thus, by setting ε = 1/14 we achieve

`∗ε`≤ 2

3.

2. By setting pcoin = 16 and given our definition in Section 3.1, we get T > 6δ as a lower

bound on time for the weak coin protocol to terminate. Given q ≤ 115 , we can assume

θTmin≤ 1

12 , i.e. honest blocks will go to vote for a block A if there’s at least 1/12 of blocksdisagreeing on its validity. If ` > 24δ (roughly 10 minutes), then by expectation 3/4 ofhonest blocks will see the weak coin’s value after termination. Thus, we set:

2θ

Tmin· pcoin ≤

2

3· 1

6=

1

9

Therefore:

q ≤ 1

15< min

(2

3· 1

9, 1− 4

6

)= min

(2

27,1

3

).

Theorem 3.3.2 shows that if the actual margin for a block is positive at any point (by The-orem 3.3.1, this must eventually happen), then with high probability the block’s validity isirreversible.

28

Theorem 3.3.2. For i, i′ > i, k > 1 and every block A claiming to be in layer i, if M †i′(A) >θ + k then

Pr[∃j > i′ : sign

(Mj(A)

)6= sign (Mi′(A))

]<

(q

1− q

)k.

Proof. Since M †i′(A) > θ + k, all honest parties agree on A’s validity at time starti′ + δ, since

for any honest P , |M (P )i′ (A) −M (max)

i′ (A)| ≤ Xi′ + ∆i−1. Moreover, this would be true evenif the adversary published all the blocks in its reserve. Thus, we can reduce the probability ofthe adversary changing the validity of A to the Bitcoin analysis (cf. [31]): both the adversaryand the honest nodes generate blocks, with the honest nodes generating at rate (1− q) and theadversary at rate q.

Denoting az the probability that the adversary will ever catch up when the honest party hasa head start of z blocks, we have

az = min(q/(1− q), 1)max(z+1,0) .

In our case, z ≥ k and q < 1− q so az =(

q1−q

)k.

By Corollary 3.2.4, regardless of starting conditions, the adversary will eventually reach asteady-state in terms of its future reserve, in which the number of blocks it can pre-generate isbounded. When this occurs:

Corollary 3.3.3. If Π satisfies [t, s]-limited-consistency, and the adversary is in its future-reserve steady-state, then the combined tortoise/Π protocol satisfies consistency and future self-consistence.

Proof. First, since the all honest nodes agree on every block in layers (i − s, . . . , i − t), allhonestly-generated blocks in layer i will vote the same way for these blocks. With overwhelmingprobability (in Tmin), the actual margin (the difference between the number of honest blocksgenerated in these layers and the number of blocks generated by the adversary, together withits future reserve), will be more than θ, by Theorem 3.3.2, this guarantees irreversibility (self-consistency).

Lemma 3.3.4 states that no layer is “too short”. This will be used later to assure that in eachlayer there is an honest majority if the adversary is in a future-reserve steady-state.

Lemma 3.3.4. For `−ε ≤ (1 − ε) · (Tmin−F ∗)Tmin

`, if the |Fi| < F ∗ and q ≤ 1/10, then for everyε > 0

Pr[starti+1 − starti < `−ε

]≤(

2ε−ln(1+ε)

ln 2

)− 23Tmin

.

Proof. Let Li be actual length of layer i i.e.

Li = starti+1 − starti .

We wish to represent the expected layer time w.r.t Fi, the adversary future-reserve. Li is atleast the time it takes to generate and publish Tmin − Fi blocks so for any i

E [Li] ≤ `Tmin − FiTmin

.

According to its definition, starti+1 is set to the time in which the first honest node firstsees Tmin blocks on layer i. Thus, for any L′, the probability of layer i being shorter than L′

is the probability of generating more than Tmin − Fi blocks within time L′. Since the blockgeneration process is a Poisson process with expectation Tmin in time `, the number of blocks

29

generated during an interval of length L′ is distributed Poisson with parameter Tmin · L′

` . Thus,the probability that Li < L′ can be bounded by the probability that a Poisson process withparameter Tmin · L

′

` generates more than Tmin − Fi events. Taking L′ to be (1− ε)`Tmin−FiTmin

weget:

Pr

[Li ≤ (1− ε)`Tmin − Fi

Tmin

]= Pr

X∼Pois((1−ε)·(Tmin−Fi))[X ≥ Tmin − Fi]

≤(

2ε−ln(1+ε)

ln 2

)Fi−Tmin

and if the adversary is on future-reserve steady-state on starti then Fi ≤ F ∗, thus

Pr

[starti+1 − starti < (1− ε) · (Tmin − F ∗)

Tmin`

]≤(

2ε−ln(1+ε)

ln 2

)F ∗−Tmin

≤(

2ε−ln(1+ε)

ln 2

)− 23Tmin

where the last inequality is since F ∗ = 3(

q1−q

)Tmin ≤ 1

3Tmin if q < 1/10

Lemma 3.3.5. Except with negligible probability in Tmin, for every layer i if the adversary is infuture-reserve steady-state the difference between honest blocks and adversarial blocks in layer iis at least Tmin − 2F ∗

Proof. For any layer i, let Li be defined as the actual layer i time that is:

Li = starti+1 − starti .

Let Xi be the number of honest blocks in layer i created in [starti, starti+1]. As all honestnodes follow the protocol, the expected value of Xi w.r.t. Li is:

E[Xi] = (1− q)Tmin ·E [Li]

`.

Let Yi be the number of adversary blocks in layer i created in [starti, starti+1]. For any layeri, by starti+1, the adversary is expected to have at most:

1. E [|Fi|] (her future-reserve blocks); and

2. qTmin · E[Li]` blocks created during Li

that is

E[Yi] ≤ E [|Fi|] + qTmin ·E [Li]

`.

Due to linearity of expectation, the expected difference between honest and adversary blocksfor any layer i is:

E [Xi − Yi] = E [Xi]− E [Yi] ≥ Tmin ·E [Li]

`− E [|Fi|]

which is monotonic decreasing for E [Li], thus a shorter E [Li] allows a smaller expected differ-ence between honest and adversary blocks.

For any layer i,

E [Li] >Tmin − F ∗

Tmin`.

That is the expected number of honest blocks for any layer i has the following lower-bound:

E[Xi] ≥ (1− q)(Tmin − F ∗)

30

and if the adversary is in future-reserve steady-state, for any layer i it follows Fi ≤ F ∗

E[Yi] ≤ F ∗ + q(Tmin − F ∗) .

According to Lemma 3.3.4, Li > (1 + ε)Tmin−F ∗Tmin

` with overwhelming probability so:

1. Denote λX = (1− q)(Tmin−F ∗) per Tmin−F ∗Tmin

` as the rate of honest blocks generation. Byapplying a Poisson tail bound,

∀i : PrX∼Pois(λX)

[Xi ≤ (1− ε)λX ] ≤(

2ε−ln(1+ε)

ln 2

)−λX.

2. Denote λY = F ∗ + q(Tmin − F ∗) per Tmin−F ∗Tmin

` as the rate of adversary blocks generation.By applying a Poisson tail bound,

∀i : PrX∼Pois(λY )

[Yi ≥ (1 + ε)λY ] ≤(

2ε−ln(1+ε)

ln 2

)−λY.

Therefore, except with negligible probability in Tmin for any layer i:

Xi − Yi > Tmin ·Li`− F ∗

> (Tmin − 2 · F ∗)

= Tmin − 2 · 3 q

1− qTmin

since q ≤ 110 :

≥ Tmin − 2 · 3 · 1/10

9/10Tmin

=Tmin

3

Lemma 3.3.6. With overwhelming probability in Tmin, if

M †i (A) > θ + k

then for all i′ > i,

M †i′(A) > θ + k + (i′ − i) · θ3.

Proof. By Lemma 3.3.5, with overwhelming probability (in Tmin) any layer in which the ad-versary is in a future-reserve steady-state will have at least Tmin

3 ≥ θ3 more honest blocks than

adversary blocks (since trivially θ ≤ Tmin). Also, by Corollary 3.2.5 if the adversary is insteady-state when the actual margin exceeds θ + k, she will remain with overwhelming proba-bility. Thus except with negligible probability in each layer, the margin grows by at least thenumber of honest blocks minus the number of malicious blocks (which is at least θ/3).

Corollary 3.3.3 and Lemma 3.3.6 imply consistency:

Corollary 3.3.7 (Consistency). If |Fi| < F ∗, Z∗ε − (F ∗+Y ∗ε ) > θ and the requirements for thehare protocol’s [t, s]-limited-consistency are met, then for every block A generated in the interval[starti, starti+1), the probability that there exist two honest nodes who disagree on the validityof A at time starti+t is negligible in t.

Proof. If the hare protocol satisfies [t, s]-limited-consistency, there will be consensus on everyblock in the range of the tortoise protocol with probability that is negligible in the size of themargin. By Lemma 3.3.6, the size of the margin is linear in the number of layers, hence thedisagreement is negligible in the number of layers.

31

4. Proof of Theorem 3.3.1

4.1. Proof Overview

In order to bound the actual confirmation margin, it will be useful to look at the quantities

R∗i (j) = 2|Ri(j)| −∆i−1

andM∗i (A) = |M (max)

i (A)| −R∗i (j) .

If for any positive α, β we’ll be able to bound M∗i (A) s.t.

M∗i (A) =

i∑j=0

(M∗j+1(A)−M∗j (A)

)≥ i · α− β ,

then for any c exists a layer ic in which M∗ic(A) > c. We prove the following by exhaustive case

analysis over the value of ∆i−1 and |M (max)i (A)| in each layer between j to i.

We then show using a followup case analysis that by fixing c = θ+ k+ 4Y ∗ε either the reservedecreases or by Definition 3.1.5 :

M †i (A) = |M (max)i (A)| − |Ri(j)| −∆i−1

= M∗i (A) + |Ri(j)| − 2∆i−1

≥ θ + k .

As the reserve is discrete, it must follow that after at most |Ric(A)| layers, M †i (A) ≥ θ + k.

4.2. Bounding the quantity M ∗i (A)

We will use the identity:

R∗i+1(j)−R∗i (j) = 2(|Ri+1(j)| − |Ri(j)|) + ∆i−1 −∆i

= 2(Yi −∆i−1) + ∆i−1 −∆i

= 2Yi −∆i−1 −∆i .

For any j < i, instead of bounding the actual margin, we will bound

M∗i+1(A)−M∗i (A) = |M (max)i+1 (A)| − |M (max)

i (A)| − (R∗i+1(j)−R∗i (j))

= |M (max)i+1 (A)| − |M (max)

i (A)| − 2Yi + ∆i + ∆i−1 .

We partition the layers according to two things: ∆i−1 (see Definition 3.1.3), the number

of blocks from Ri−1(A) published by the adversary at time starti + δ and M(max)i (A) (see

Definition 3.1.4). As we show below, depending on the relation between these values and θ (seeSection 2.4.4), we can bound the difference M∗i+1(A) −M∗i (A). Below is an exhaustive caseanalysis:

32

Case 1: ∆i−1 < |M (max)i (A)| − θ. Honest blocks on starti + δ may disagree only on ∆i−1. There-

fore, in this case for every honest party P it holds that

|M (max)i (A)| − |M (P )

i (A)| ≤ ∆i−1 ,

implying that |M (P )i (A)| > θ for every honest P . Thus, the vote of every honestly gener-

ated block after the weak coin protocol completes is sign(M

(max)i (A)

). Thus, for every

non-abstaining honest P (of which there are, by definition, Zcoini ) and in particular for

Pmaxi+1 :

|M (Pmaxi+1 )

i+1 (A)| ≥ |M (Pmaxi )

i+1 (A)| ≥ |M (Pmaxi )

i (A)|+ Zcoini −∆i .

In this case

M∗i+1(A)−M∗i (A) ≥ Zcoini −∆i − 2Yi + ∆i + ∆i−1

≥ Zcoini − 2Yi

Case 2: |M (max)i (A)| < θ. In this case, for every honest party P generating a block after the weak

coin protocol completes it follows:

|M (P )i (A)| ≤ |M (max)

i (A)| < θ

that is every honest party will vote according to the result of the coin.

Case 2.1: (with probability at least pcoin): There is consensus on the weak coin for layer i and

it agrees with sign(M

(Pmaxi )

i (A))

so all honest parties will vote the same way on A.

Thus,

|M (Pmaxi+1 )

i+1 (A)| ≥ |M (Pmaxi )

i+1 (A)| ≥ |M (Pmaxi )

i (A)|+ Zcoini −∆i .

Therefore

|M (Pmaxi+1 )

i+1 (A)| − |M (Pmaxi )

i (A)| ≥ Zcoini −∆i .

In this case

M∗i+1(A)−M∗i (A) ≥ Zcoini −∆i − 2Yi + ∆i + ∆i−1

≥ Zcoini − 2Yi

Case 2.2: (with probability at most 1− pcoin): The adversary selects M(max)i+1 (A) arbitrarily. In

this case

M∗i+1(A)−M∗i (A) ≥ −|M (max)i (A)| − 2Yi

≥ −θ − 2Yi

Case 3: |M (max)i (A)|−θ ≤ ∆i−1 < 2θ (note that, together with the negation of case 2, this implies

θ ≤ |M (max)i (A)| < 3θ). In this case, every honest P must be on the “same side” of the

[θ,−θ] interval; that is, for every P it holds that

|M (P )i (A)| > θ ⇒ sign

(M

(P )i (A)

)= sign

(M

(max)i (A)

).

33

Case 3.1: (with probability at least pcoin): There is consensus on the weak coin for layer i and

it is equal to sign(M

(max)i (A)

), so all non-abstaining honest parties will vote the

same way on A. Thus,

|M (Pmaxi+1 )

i+1 (A)| ≥ |M (Pmaxi )

i+1 (A)|

≥ |M (Pmaxi )

i (A)|+ Zcoini −∆i

In this case

M∗i+1(A)−M∗i (A) ≥ Zcoini −∆i − 2Yi + ∆i + ∆i−1

≥ Zcoini − 2Yi

Case 3.2: (with probability at most 1− pcoin): The adversary selects M(max)i+1 (A) arbitrarily. In

this case

M∗i+1(A)−M∗i (A) ≥ −|M (max)i (A)| − 2Yi

≥ −3θ − 2Yi

Case 4: ∆i−1 ≥ max{|M (max)

i (A)| − θ, 2θ}

. The adversary chooses how each honest party will

vote, so can fix M(max)i+1 (A) arbitrarily. In this case,

M∗i+1(A)−M∗i (A) ≥ −|M (max)i (A)| − 2Yi + ∆i + ∆i−1

≥ −|M (max)i (A)| − 2Yi + max

{|M (max)

i (A)| − θ, 2θ}

= −θ − 2Yi

For j ∈ {1, 2.1, 2.2, 3.1, 3.2, 4}, let Cj denote the set of rounds that fall under case j. To

bound M∗i (A), we sum the(M∗j+1(A)−M∗j (A)

)differences from the layer in which block A

claims to be (w.l.o.g set to 0) up to current layer i.:

M∗i (A) =

i∑j=0

(M∗j+1(A)−M∗j (A)

)≥∑j∈C1

(Zcoinj − 2Yj

)+∑j∈C2.1

(Zcoinj − 2Yj

)+∑j∈C2.2

(−θ − 2Yj)

+∑j∈C3.1

(Zcoinj − 2Yj

)+∑j∈C3.2

(−3θ − 2Yj) +∑j∈C4

(−θ − 2Yj)

extracting 2Yj from all the sums:

=∑j∈C1

Zcoinj +

∑j∈C2.1

Zcoinj +

∑j∈C2.2

−θ

+∑j∈C3.1

Zcoinj +

∑j∈C3.2

−3θ +∑j∈C4

−θ

− 2 ·i∑

j=0

Yj

34

using our bounds on Zcoin:

≥ (|C1|+ |C2.1|+ |C3.1|) · Z∗ε

+ (|C2.2|+ |C3.2|) · (−3θ) + (|C4|) · (−θ)− 2 ·i∑

j=0

Yj

At this part, we wish to upper-bound the negative elements of the sum. Since∑i

j=0 Yj is a sum

of independent Yj ∼ Pois(λ), then∑i

j=0 Yj ∼ Pois(i · λ) and can be bounded using Poissontail bounds s.t.

Pr

i∑j=0

Yj > (1 + εY ) · i · q · `∗ε

`· Tmin

≤ (2εY −ln(1+εY )

ln 2

)−i·q· `∗ε`·Tmin

The success of the weak coin protocol is independent for all layers (see Section 2.3). Therefore,either case 2.2 or case 3.2 occur on any layer with probability at most 1−pcoin. Using Chernoff,we bound the number of layers in which the weak coin protocol fails for all εpcoin > 0:

Pr [|C2.2|+ |C3.2| ≥ i · ((1− pcoin) · (1 + εpcoin))] ≤ exp

(− εpcoin

2

2 + εpcoin· (1− pcoin)

).

As for case 4, in each round where it occurs the adversary “spends” at least 2θ blocks. GivenRi0(A), the adversary initial reserve and Y ∗ε , the bound for maliciously generated blocks in eachround,

|C4| ≤

Ri0(A) +i∑

j=0

Yj

· 1

2θ

Since i = |C1|+ |C2.1|+ |C2.2|+ |C3.1|+ |C3.2|+ |C4|,

|C1|+ |C2.1|+ |C3.1| ≥ i · (1 + εpcoin) · pcoin −

Ri0(A) +

i∑j=0

Yj

· 1

2θ

≥ i · pcoin −

Ri0(A) +

i∑j=0

Yj

· 1

2θ

Putting it all together,

M∗i (A) ≥

i · pcoin −Ri0(A) +

i∑j=0

Yj

· 1

2θ

· Z∗ε − 2 ·i∑

j=0

Yj

≥

(i · pcoin −

(Z∗ε − 4θ) ·∑i

j=0 Yj

Z∗ε · 2θ

)· Z∗ε −

Ri0(A) · Z∗ε2θ

≥

(i · pcoin −

(Z∗ε − 4θ)

Z∗ε·∑i

j=0 Yj

2θ

)· Z∗ε −

Ri0(A) · Z∗ε2θ

if q < 1− ``−ε −tcoinδ

· 4θTmin

, except with negligible probability Z∗ε > 4θ:

≥

(i · pcoin −

∑ij=0 Yj

2θ

)· Z∗ε −

Ri0(A) · Z∗ε2θ

35

with overwhelming probability∑i

j=0 Yj ≤ (1 + εY ) · i · q · `∗ε` · Tmin:

≥ i ·(pcoin −

(1 + εY ) · qTmin

2θ· `∗ε

`

)· Z∗ε −

Ri0(A) · Z∗ε2θ

Note that if

q ≤(

2θ

Tmin· ``∗ε· pcoin

)the expression in the parenthesis is a positive constant thus for any constant c

∃ic s.t. ∀i > ic : M∗i (A) > c .

4.3. Bounding the Actual Confirmation Margin

By fixing c = θ + k + 4Y ∗ε , for any i >= ic,

1. if ∆i−1 < 2Y ∗ε then

M †i (A) ≥M∗i (A) + |Ri(j)| − 2∆i−1 ≥ θ + k

and we are done;

2. otherwise, for every ∆i−1 s.t. ∆i−1 > 2Y ∗ε , w.h.p. |Ri+1(A)| < |Ri(A)| (adversary had touse blocks from her reserve).

As there are at most |Ric(A)| consecutive rounds at which the last case applies, there mustexists a layer i∗ > ic s.t.

M †i∗(A) ≥ θ + k .

36

5. Byzantine-Agreement-Based Hare Protocol

Our first ABA-based hare protocol uses a binary byzantine agreement protocol that must satisfysome specific properties:

1. Asynchronous Communication: the protocol should allow for messages to be arbitrarilydelayed (up to our communication latency bound)

2. Name-independence: The protocol should not rely on consistent names for parties. Thatis, it should allow each party to use its own labels for the other parties. Note that a partycan identify where a message originated; it just might not agree with other parties on theoriginators name.

Formally, we will describe the ABA protocol as an interactive program P implementing thefollowing interface:

• The party running P maintains an “event queue”, initialized to (init, n).

• It repeats the following loop until P outputs a bit b and halts:

1. Invoke P with the next event from the event queue (if there are no events, wait untilone occurs).

2. At every invocation of P , it may perform any of the following actions (possiblymultiple actions sequentially):

– Send a message to another party j ∈ [n] (the parties are referenced by index).

– Request a random coin bit i. In this case P will sleep until the bit i becomesavailable.

– Output a bit b and halt (this should be the consensus bit)

3. When a message m arrives from party j, add the event (msg, j,m) to the eventqueue (and invoke P if it was waiting)

5.1. The ABA Protocol’s Environment

The ABA protocol may make the following assumptions about its environment:

• Reliable, ordered, point-to-point channels. For all i ∈ [n], and every message m sent toP by party i (according to P ’s indexing), P it will (eventually) be invoked exactly oncewith (msg, i,m). Messages from a single party will be received in the order they weresent by that party. Moreover, only a message m sent by i will cause P to be invokedwith (msg, i,m) (i.e., the network does not duplicate, create or reorder, modify or deletemessages).

• Weak common coin (with parameter pcoin). The coin gives the following guarantees:

1. No corrupt party will receive coin i until at least one honest party requested coin i.

2. For all i, with probability at least pcoin, all honest parties will receive 0 in responseto a request for coin i.

3. For all i, with probability at least pcoin, all honest parties will receive 1 in responseto a request for coin i.

37

5.1.1. Implementing the Environment.

We will choose m∗ to be a bound on the number of blocks in a layer that satisfies, for everylayer i, two properties:

1. The probability that more than m∗ syntactically-valid layer-i blocks that were publishedbefore starti + δ is negligible.

2. The probability that the number of honestly-generated blocks in layer i is less than 56m∗

is negligible.

Note that if one of the two properties does not hold, the ABA protocol might fail, but theTortoise protocol will still guarantee eventual consensus.

Our hare protocol implements the environment expected by the ABA protocol in the followingway:

• Participating parties. For the hare protocol to work, every miner must add the followinginformation to their blocks:

– A verification key for a public-key signature scheme (this will be used to make ourcommunication channels reliable).

– (Optional) An address that allows direct point-to-point communication (e.g., an IPaddress). This can be used to make the point-to-point channels much more efficient.Alternatively, the parties can use the underlying gossip network to communicate.

Every party that generated a block in layer i participates in the ABA protocol for layeri (in fact, the parties will run multiple ABA protocols in parallel—one for each blockgenerated in layer i).

Let party P be one of the parties that generated a block in layer i. At time starti+1 + δ,P makes a list of all the (syntactically-valid) blocks it received in layer i. Let m be theactual number of blocks received. It orders them arbitrarily from 1 to m, then adds“placeholder” parties indexed m+ 1, . . . ,m∗. It then initializes an ABA protocol with m∗

parties. If it receives messages from parties that were not in the list, it treats them asfaulty parties (and ignores the messages).

• Point-to-point messages. If m is the kth message P sent to party j (who has verificationkey vkj), P signs the tuple (vkP , vkj , k,m) with P ’s signature key, and sends it to theaddress specified in j’s block. When receiving a message of the form (vki, vkP , k,m), Pverifies that the signature is valid, and that vki appears in one of the blocks generated inblock i. If there is some k′ < k such that a message of the form (vki, vkP , k

′,m) has notyet been received (i.e., messages were reordered), the message is held until all previousmessages have been delivered. Otherwise, this message is delivered to the queue (as theevent (msg, j,m)). Note the bound on network latency guarantees that all messages fromhonest parties will eventually be delivered.

• Weak coin. We can implement the weak coin as described in Section 2.3, based on theblockmesh itself. To satisfy the assumption that no corrupt party will receive coin iuntil at least one honest party requested coin i, we have to assume that the latency ofcommunications in the ABA protocol is small enough that the coins are requested byhonest parties before they actually become available (this is reasonable, since they canuse actual point-to-point connections).

Alternatively, we can use an off-chain coin based on unique signatures, such as the ideasuggested by Micali [23]. Micali’s construction gives a weak coin with pcoin = 1/3 thatdoes not require proof-of-work; briefly, the idea is that to generate coin i, for all j ∈ [m],party j will compute and publish σj = Signskj (vkj ||i). Each party sorts {H(σj)}mj=1 for

38

all valid messages, and takes the LSB of the first to be the coin value (this is similar towhat we do with the proof-of-work-based coin). If 2m∗/3 of the parties generating blocksare honest, there will be agreement on the value w.p. 2/3 (and hence pcoin = 1/3).

Because the ABA protocol does not rely on consistent naming, the fact that different partiessee a different set of blocks will not matter—the honestly generated blocks will be in the inter-section of all the honest parties’ lists, and so every honest party will be considered a participantby every other honest party. By our assumptions about m∗, there are more than 2m∗/3, soeven if we count the parties m+ 1, . . . ,m∗ as faulty the honest parties are still a 2/3 majority.

5.2. Using the ABA Protocol

We require the following guarantees from the ABA protocol:

• Consensus: All honest parties should agree on a bit b for every execution of the ABAprotocol. If all honest parties have the same input b′, then b = b′.

• Termination: The ABA protocol should terminate in a small (constant) number of rounds(we count rounds as the number of weak coin flips) except with negligible probability.

Our ABA-hare protocol executes an instance of the ABA protocol for every block generatedin layer i.

Block Propagation.

For party P , denote G = (vk1, . . . , vkm) the ids of the parties(blocks) that P received beforestarti + δ.

1: Initialize SP = {vk1, . . . , vkm} // the set of blocks to validate2: for all j ∈ [m] do // Update round 13: Send SP to j4: Receive Sj from j5: Update SP ← SP ∪ Sj6: end for

ABA Execution.

1: for all vkj ∈ SP do // In parallel2: if vkj ∈ G then // We received the block before starti + δ3: b′ = 14: else5: b′ = 06: end if7: Execute the ABA protocol with input b′. Let b be the output of the protocol.8: if b = 1 then // Consensus on the block being included9: Sign vkj using skP and publish the signature to the blockmesh.

10: end if11: end for

ABA Hare Protocol Consensus.

The hare protocol specifies that a block in layer i is valid iff it has 56m∗ signatures from parties

that generated a layer-i block.

Claim 5.2.1. Every honestly-generated block is considered valid by the ABA hare protocol.

39

Proof. Every honestly-generated block will be received by every honest party before starti+δ.Thus, all honest parties will participate in the ABA for confirmation of this block, and theywill all agree that the block is valid. By the consensus guarantee of the ABA protocol, theconsensus outcome will be that the block is valid, so all honest parties will sign it. Since thenumber of honest parties is more than 5

6m∗, the hare protocol will consider this block valid.

Claim 5.2.2. Every block that was not received by any honest party before starti + δ will beconsidered invalid by the ABA hare protocol.

Proof. No honest party will initiate an ABA protocol to validate such blocks. However, the ma-licious parties may send such a block to a subset of the honest parties in the Block Propagationphase. If the block is sent to less than 2

3m∗ honest parties, even the outcome of the consensus is

that the block is valid, there will not be enough signatures to make it valid (since the maliciousparties have at less than 1

6m∗ blocks). If the block is sent to more than 2

3m∗ honest parties, the

honest parties will have a 2/3 majority in the ABA protocol and they all agree that the blockis invalid, hence the consensus result will be that the block is invalid.

Lemma 5.2.3. The hare protocol will reach consensus on every block.

Proof. By Claim 5.2.2, there will be consensus on every block that was not received by anyhonest party before starti + δ. If a block was received by at least one honest party, then allhonest parties will receive the block in the Block Propagation phase, so they will all participatein the ABA protocol for that block. Since there is a 2/3 majority of honest blocks, the ABAprotocol will reach consensus on that block. If the consensus is valid, all honest parties will signthe block, so it will be considered valid by the hare protocol. Otherwise, no honest party willsign the block, so it will be considered invalid by the hare protocol.

5.3. Improving the Hare-Protocol Parameters using MultivaluedABA

In order to guarantee consensus using the binary ABA protocol, we need the number of honestly-generated blocks to be at least 5

6 of the maximum number of blocks generated in a layer interval.This implies that the fraction of the hashpower controlled by the adversary cannot be more thanq < 1/6. If a 1/2 majority (rather than 2/3) suffices for the ABA protocol, we can relax theassumption to q < 1/4 (this might be possible with cryptographic assumptions). However, ifwe are willing to use a more “heavy-duty” protocol that guarantees consensus on strings ratherthan bits, we can use it to improve parameters. Due to space restrictions, we describe thedetailed algorithm in Chapter 6.

5.4. Additional Potential Improvements

Our ABA and Multivalued-ABA Hare protocols solve the “participant consensus” problem (i.e.,agreeing on who is participating in the protocols) by using a preset bound m∗ on the numberof blocks in a layer. However, the adversary can influence the number of blocks in a layer (e.g.,by withholding generated blocks until honest parties already generate the minimum number).This leads to restrictions on the adversary’s hashpower that are not optimal (e.g., we cannotsupport an adversary with 1/3 the hashpower).

However, it may be possible to use the underlying ABA protocols more efficiently: insteadof using a bound on the number of parties, each honest party will just run the ABA protocolwith the parties it sees. Note that if all the honest parties see the same number of blocks, evenif disagree on which blocks, this will already work with our existing analysis. The reason isthat all honest parties see each other—the only blocks they can disagree on are the malicious

40

blocks—but the ABA protocols already allow arbitrary malicious behaviour for corrupt parties,so we can treat two different malicious parties as a single party sending different messages tothe honest parties.

Unfortunately, the honest parties may not agree on the number of blocks. However, forspecific ABA protocols this can still be secure. In particular, a close look at the analysis of theABA protocols of Mostefaoui et al. [25, 26] shows that they use the total number of parties forachieving properties such as “if a message m was received from t + 1 different parties, it musthave been sent by at least one honest party” and “if a message was received from n−2 differentparties, it must have been sent by at least t+ 1 honest parties”—these statements still hold inour setting even when there is disagreement on n and t (as long all the honest parties see eachother, and in the local execution of each honest party there is a 2/3 honest majority).

41

6. Improving the Hare-Protocol Parametersusing Multivalued ABA: Details

We will require a multivalued ABA protocol with the same properties as the binary ABA pro-tocol (asynchronous, name-independent), that is also intrusion-tolerant. That is, it guaranteesthat if all honest parties have v as their input, the consensus value output by honest parties atthe end of the protocol must be v. We note that Mostefaoui and Raynal show how to constructa multivalued ABA protocol with the desired propeties based on any binary ABA protocol [26].Their multivalued protocol has a constant number of rounds and is secure when less than 1/3of the parties are malicious.

Let ABA(v) denote an execution of the multivalued ABA protocol with input v, and BBA(b)denote an execution of the binary ABA with input b.

For party P , denote G = (vk1, . . . , vkm) the ids of the parties(blocks) that P received beforestarti + δ. Our Multivalued ABA Hare protocol can be described in two parts. A main loop,that runs until agreement is reached to terminate, and a message-processing procedure thathandles incoming messages (the protocol is asynchronous, so does not wait for messages toarrive unless such a message is guaranteed to arrive). Think of the process as single-threaded(i.e., if a message arrives, it finishes executing the current line in the main loop, executes theProcessMessage procedure and then returns to the next line in the main loop).

1: procedure MainLoop2: Initialize SP ← G, sorted lexicographically3: Initialize V alid← ∅.4: loop // Main Loop5: Let vk be the first (smallest) element in SP6: Let vk∗ ← ABA(vk)7: if vk∗ 6= ⊥ then8: Let V alid← V alid ∪ {vk∗} // Add vk∗ to valid block set9: SP = SP \ {vk∗} // Remove vk∗ from SP

10: if vk < vk∗ then11: Send vk to all parties12: end if13: else // Some party proposed to terminate14: Set b = 1 iff SP 6= ∅.15: Let b∗ ← BBA(b)16: if b∗ = 0 then // At least one honest party agreed to terminate17: return V alid and terminate18: else // At least one honest party does not want to terminate19: if SP 6= ∅ then20: Send the first element in SP to all parties21: else22: Wait until SP 6= ∅23: end if24: end if25: end if26: end loop27: end procedure

42

28: procedure ProcessMessage(vk)// Called whenever a message vk is received if the party has not yet terminated

29: if vk /∈ V alid then30: Set SP = SP ∪ vk31: end if32: end procedure

Lemma 6.0.1. An honest party running the protocol will always terminate

Proof. Let Tr = bigcupiSi be the set of blocks in the union all honest parties’ sets Si at thestart of iteration r of the main loop . Let Qr be the set of blocks that are not in I ∪ V alid atthe start of iteration r of the main loop. Note that |Q1| ≤ m∗/3 (since all honest blocks are inI1).

Consider iteration r of the main loop for an honest party P .

Case 1: The outcome of the ABA protocol was vk. Then vk is added to V alid, so |Tr+1∪Qr+1| <|Tr ∪Qr|.

Case 2: The outcome of the ABA protocol was ⊥Case 2.1: The outcome of the BBA protocol was 0. In this case the party terminates and we

are done.

Case 2.2: The outcome of the BBA protocol was 1. In this case for at least one honest partySi 6= ∅ (otherwise all honest parties would have input 0 to the BBA protocol). Letvk∗ be the minimal element in Tr. In this case, vk∗ will be the minimal for anyhonest party that has it, Since each honest party for which SP 6= ∅ sends its minimalelement, it will be sent in Line 20 by some honest party. Since all messages sentby honest parties are eventually received by all honest parties, it will eventually bereceived by all honest parties. Let r′ be the first round at which it was received byall honest parties.

Case 2.2.1: If vk∗ ∈ V alidr′ then |Tr′ ∪Qr′ | < |Tr ∪Qr|Case 2.2.2: Otherwise, if there exists vk† ∈ Tr′ such that and vk† < v∗, then Qr′ < Qr (since

vk† could only have come from Qr).

Case 2.2.3: Otherwise, vk∗ must be minimal in Tr′ , so all honest parties will use it as inputto the ABA in call. By the intrusion-tolerance property of the ABA, the outputmust be vk∗ 6= ⊥, hence |Tr′+1 ∪Qr′+1| < |Tr′ ∪Qr′ |

We showed that in every iteration, either |Tr ∪Qr| decreases, or |Qr| decreases, or there will bea future round r′ in which one of those occurs. Since they are both non-increasing, eventually|Tr ∪Qr| must reach 0. When that happens, every honest party will have Si = ∅, so all honestparties will use input ⊥ to the ABA, guaranteeing the output will be ⊥. All honest parties willthen use input 0 to the BBA, guaranteeing output 0, so they will all terminate.

Claim 6.0.2. All honest parties will terminate in the same iteration of the main loop.

Proof. The parties terminate only if the ABA protocol returns ⊥ and then the BBA protocolreturns 0. Since all honest parties agree on the outputs of the ABA and BBA protocols, theywill all terminate at the same iteration.

Lemma 6.0.3. Every honest party will agree on the value of V alid after termination.

Proof. The only blocks added to V alid are output from the ABA protocol. Since all honestparties agree on the outputs of the ABA protocol and terminate at the same time, they willagree on the sequence of blocks added.

43

Lemma 6.0.4. Every honestly-generated block will be included in V alid

Proof. All Honestly-generated blocks appear in I = bigcapiGi, the intersection of all honestparties’ “good sets”, and hence appear in the intersection of the sets Si. Blocks are removedfrom the set Si only if they enter V alid. For the protocol to terminate, at least one honestparty must have an empty Si, therefore all honest blocks must have been added to V alid.

44

7. Incentive-Compatibility of Race-FreeProtocols

7.1. Generalized Blockchain Mining Games

In this section, we extend the Blockchain Mining Game described in [12] to allow for analysis ofprotocols based on blockDAGs in addition to blockchains. The Generalized Blockchain MiningGame is a stochastic game of complete information played among n players called miners.

Public State.

The public state of the game is a layered DAG rather than a rooted tree as in [12]. A predefinedinitial set of nodes in the DAG is called the root. The nodes of the DAG represent mined blocksand each node is labeled by a miner who mined it and a number of layer it belongs to.

Private State.

Similar to the public state but may contain more blocks (private blocks). The private andpublic states must share the same root. Since the game is played with complete information,the private state of all miners is visible. However, a player cannot mine on blocks not containedin its private state.

Stages.

The game proceeds in stages. At each stage, some player mines a block, i.e., a new blockis created such that its label is i with probability pi (it holds that

∑ni=1 pi = 1 and each pi

corresponds to the computational power of player i). The miners then decide whether theywish to release any subset of their private states into the public state.

Strategies.

The strategy of player i consists of two functions (µi, ρi):

1. Mining function µi: selects a subset of the private state to mine on and a layer numberj. If the player succeeds in mining a block then the newly mined block has directed edgesto all the blocks selected by µi and is labeled by layer j.

2. Release function ρi: selects when to move parts of the private state to the public state.

Block Validity.

The validity is decided by a function f of the state that outputs the public state restricted toaccepted blocks.

Utility.

The utility of each miner is the fraction of its valid blocks in the blockDAG.

45

Immediate vs. Strategic Release.

Similarly to [12], we consider the immediate release model in which the players release theirnewly mined blocks into the public state right after mining them (i.e., the release function isfixed for all the players). We also consider the strategic release model, where the parties candecide on when their blocks become part of the public state.

7.2. Race-Free Games

In this section, we introduce the game-theoretic definition of race-free strategy profiles and gamesand show how race-freeness relates to incentive compatibility in blockchain mining games.

Definition 7.2.1 ((ε, q)-Race-free strategy profile). Let σ = (σ1, . . . , σn) be a strategy profilein a blockchain mining game. We say that σ is (ε, q)-race-free if for every player i, and for everyC ⊆ [n] \ {i} such that

∑j∈C pj ≤ q, it holds that

∀σC : ui(σ[n]\C , σC) ≥ ui(σ) · (1− ε) .

That is, the strategy σi of player i guarantees, up to a multiplicative factor, at least thepayoff achieved in σ irrespective of the actions of any coalition of other players controlling atmost a q-fraction of computational power. We say that a strategy profile is q-race-free if it is(ε, q)-race-free for ε = 0.

Definition 7.2.2 (Race-free game). A blockchain mining game is race-free if it has a race-freestrategy profile.

7.2.1. Properties of Race-Free Games.

We prove that following a race-free strategy is not only a low-risk behavior but it is also incentive-compatible. In particular, any (ε, q)-race-free strategy is also an ε-Nash equilibrium equilibriumif every player controls at most a q-fraction of the computational power.

Theorem 7.2.3. For all ε ≥ 0. If σ is an (ε, q)-race-free strategy profile in a blockchain mininggame and pi ≤ q for every i then σ is an ε-Nash equilibrium.

Proof. Let σi be any strategy of player i ∈ [n]. Since pi ≤ q, it follows from the (ε, q)-race-freeproperty of σ and the fact that any blockchain mining game is a constant-sum game that:

ui(σi, σ−i) ≤ 1−∑

j∈[n]\{i}

uj(σ)(1− ε)

=∑k∈[n]

uk(σ)−∑

j∈[n]\{i}

uj(σ)(1− ε)

= ui(σ) +∑

j∈[n]\{i}

uj(σ)ε

≤ ui(σ) + ε .

Where the first and last inequalities follow, since all utilities in the game are non-negative andtheir sum is equal to 1.

7.2.2. Race-Free Blockchain Protocols.

We now formally define the race-free property of a blockchain protocol. Our definition is basedon the blockchain mining game as described in Section 7.1.

46

Definition 7.2.4 (ε-Race-free blockchain protocols). A blockchain protocol is ε-race-free if inthe corresponding blockchain mining game, the strategy profile in which all the players followthe protocol is ε-race-free. A blockchain protocol is race-free if it is an ε-race-free blockchainprotocol for ε = 0.

7.3. Meshcash is Race-Free

We show that in the setting with constant rewards per block, the Meshcash protocol is race-free.We need to specify the blockchain mining game corresponding to Meshcash, and in particularthe validity function. Recall, that a block in layer j is considered valid if it has at least Tmin

outgoing edges to blocks in layer j. The utility function is then simply the fraction of player’svalid blocks in the valid blockDAG.

Immediate Release Model.

In the immediate release model, the players’ strategies are restricted to publishing newly minedblocks at the stage of their creation. The players can only select the subset of the public stateto mine on. Any block of player i in layer j must have at least Tmin outgoing edges to blocksin layer j − 1 for it to be considered valid. Hence, rational players are restricted to strategiesthat correspond to the honest behavior. Note that in the model of blockchain mining games,there are no delays and all the players see published blocks immediately, and the players are inconsensus about the contents of the layers of the public state at every stage. Also, no coalitionof players can invalidate blocks of any player by not pointing to them. Thus, the honest strategyprofile is race-free.

Although the immediate release model is rather restrictive, we stress that it allows to captureinteresting strategies of players. In particular, Kiayias et al. [12] demonstrated that for playerscontrolling at least 41.8% of the computational power in the system, the honest behavior inBitcoin is not incentive-compatible even with immediate release (cf. Section 3.2 in [12]).

Strategic Release Model.

In the strategic release model, the players can withhold their blocks from the public state. Thisallows them to create valid blocks in layers ahead of the layer corresponding to the contents ofthe public state (in case player’s private state contains at least Tmin blocks in the current layer).

Proposition 7.3.1. Meshcash is a race-free protocol with respect to coalitions controlling up to1/3 of the computational power.

Proof. It follows from the future self-consistence of the protocol that the blocks of every honestparty cannot be with overwhelming probability invalidated by an adversary controlling up to1/3 of the computational power. Thus, the fraction of the valid blocks of any honest partycannot be decreased and the utility remains at least the same irrespective of the actions of theother players (controlling at most 1/3 of the computational power).

7.4. When Fees Dominate Coinbase

In the previous section, we used the model of [12] to analyze the properties of Meshcash in thesetting where the coinbase reward dominates over the reward gained from the transaction fees.However, the major strategic considerations in Meshcash seem to be in place when the systemreaches the steady-state and no new coins are created, i.e., when the real incentive for minerscomes from the transaction fees.

47

For example in Bitcoin, when the miners can include transactions in their blocks dependingon the fees, it is possible to mount the following “bribery” attack. When the last publishedblock contains many transactions with high fees, an attacker can try to extend the second lastblock instead of the last one. If he succeeds in mining a block and includes in it only a fewof the transactions with high fees, then he creates a situation in which it is advantageous forthe rest of the network to mine on his block. In particular, the other parties can now includethe remaining transactions with heavy fees that would have otherwise been already claimed bythe original block. The adversary “bribes” the rest of the network to prioritize his block bysplitting some of the transaction fees with them.

Reward Allocation.

We suggest a reward allocation scheme where the transaction fees collected in layer i are dividedamong the last k layers (i.e., layers i − k, . . . , i) proportionally to the actual number of blocksin each layer. Formally, let πi denote the transaction fees collected in layer i, and for m ≤ n,let χm,n be the total number of blocks mined in layers m, . . . , n. The reward for block A blockin layer i is:

ri = coinbasei + c∗A ·i+k∑j=i

πjχj−k,j

,

where c∗A ∈ [0, 1] is the fraction of included transactions in A compared to the adjustabletransaction cap.

When coinbasei = 0, a player might have an incentive to deviate from the protocol speci-fications in order to increase the amount of transaction fees split among layers containing hisblocks. We discuss in particular the following Temporal Robin Hood attack.

The “Temporal Robin Hood” attack.

The name of the attack comes from the fact that an adversary can “steal” transaction feesfrom a future layer and split them among the blocks in the past layers. Assuming a constantrate of fees over time, on each layer i, the attacker continues mining on the layer until timestarti+1 + δ. By doing so, a miner risks not finding a block but if he does, he manages tosteal rewards from the next layer and splits the rewards between the past layers. Note thatthe expected stolen reward is at most a δ

k·` -fraction of fees accumulated over the expected layertime `.

48

Bibliography

[1] I. Abraham, D. Malkhi, K. Nayak, L. Ren, and A. Spiegelman, “Solidus: Anincentive-compatible cryptocurrency based on permissionless byzantine consensus,” 2016.[Online]. Available: http://arxiv.org/abs/1612.02916

[2] M. Babaioff, S. Dobzinski, S. Oren, and A. Zohar, “On Bitcoin and red balloons,” in ACMConference on Electronic Commerce, 2012, pp. 56–73.

[3] B. Barak, R. Canetti, Y. Lindell, R. Pass, and T. Rabin, “Secure computation withoutauthentication,” in CRYPTO, 2005.

[4] J. Bonneau, “Why buy when you can rent? - bribery attacks on bitcoin-style consensus,”in Financial Cryptography Bitcoin Workshop, 2016.

[5] X. Boyen, C. Carr, and T. Haines, “Blockchain-free cryptocurrencies. a rational frameworkfor truly decentralised fast transactions,” Cryptology ePrint Archive, Report 2016/871,2016, http://eprint.iacr.org/2016/871.

[6] M. Castro and B. Liskov, “Practical byzantine fault tolerance,” OSDI, 1999.

[7] K. Croman, C. Decker, I. Eyal, A. E. Gencer, A. Juels, A. Kosba, A. Miller, P. Saxena,E. Shi, E. G. Sirer, D. Song, and R. Wattenhofer, “On scaling decentralized blockchains,”in Financial Cryptography 3rd Bitcoin Workshop, 2016.

[8] I. Eyal, “The miner’s dilemma.” in IEEE S&P, 2015.

[9] I. Eyal, A. E. Gencer, E. G. Sirer, and R. van Renesse, “Bitcoin-NG: A scalable blockchainprotocol,” in NSDI, 2016.

[10] I. Eyal and E. Sirer, “Majority is not enough: Bitcoin mining is vulnerable.” in FinancialCryptography, 2014.

[11] J. Garay, A. Kiayias, and N. Leonardos, “The Bitcoin backbone protocol: Analysis andapplications,” in Eurocrypt, 2015, http://eprint.iacr.org/2014/765.

[12] A. Kiayias, E. Koutsoupias, M. Kyropoulou, and Y. Tselekounis, “Blockchain mininggames,” in Proceedings of the 2016 ACM Conference on Economics and Computation,EC ’16, Maastricht, The Netherlands, July 24-28, 2016, 2016, pp. 365–382.

[13] A. Kiayias and G. Panagiotakos, “On trees, chains and fast transactions in theblockchain,” p. 545, 2016. [Online]. Available: http://eprint.iacr.org/2016/545

[14] E. Kokoris-Kogias, P. Jovanovic, N. Gailly, I. Khoffi, L. Gasser, and B. Ford, “Enhancingbitcoin security and performance with strong consistency via collective signing,” in USENIXSecurity Symposium, 2016.

[15] S. D. Lerner, “Dagcoin: a cryptocurrency without blocks,” 2015, https://bitslog.wordpress.

com/2015/09/11/dagcoin/.

[16] Y. Lewenberg, Y. Sompolinsky, and A. Zohar, “Inclusive block chain protocols,” in Finan-cial Cryptography and Data Security, 2015, pp. 528–547.

49

[17] K. Liao and J. Katz, “Incentivizing double-spend collusion in bitcoin,” in Financial Cryp-tography Bitcoin Workshop, 2017.

[18] L. Luu, V. Narayanan, K. Baweja, C. Zheng, S. Gilbert, and P. Saxena, “SCP: Acomputationally-scalable byzantine consensus protocol for blockchains,” in CCS, 2016.

[19] L. Luu, J. Teutsch, R. Kulkarni, and P. Saxena, “Demystifying incentives in the consensuscomputer,” in 22nd ACM CCS, 2015.

[20] “Maged”(pseudonym), “Re: Unfreezable blockchain,” 2012, https://bitcointalk.org/index.

php?topic=57647.msg686497#msg686497.

[21] G. Maxwell, 2015, https://bitcointalk.org/index.php?topic=1108304.msg11786046#

msg11786046.

[22] B. McElrath, “Braiding the blockchain,” 2015, https://scalingbitcoin.org/hongkong2015/

presentations/DAY2/2 breaking the chain 1 mcelrath.pdf.

[23] S. Micali, “Byzantine agreement made trivial,” 2016, https://people.csail.mit.edu/silvio/Selected%20Scientific%20Papers/Distributed%20Computation/BYZANTINE%20AGREEMENT%20MADE%20TRIVIAL.pdf.

[24] A. Miller, A. E. Kosba, J. Katz, and E. Shi, “Nonoutsourceable scratch-off puzzles todiscourage bitcoin mining coalitions,” in 22nd ACM CCS, 2015.

[25] A. Mostefaoui, H. Moumen, and M. Raynal, “Signature-free asynchronous binarybyzantine consensus with t < n/3, O(n2) messages, and O(1) expected time,” J.ACM, vol. 62, no. 4, p. 31, 2015. [Online]. Available: https://hal.archives-ouvertes.fr/hal-01176110/file/JACM.pdf

[26] A. Mostefaoui and M. Raynal, “Signature-free asynchronous byzantine systems: Frommultivalued to binary consensus with t < n/3, o(n2) messages, and constant time,” inStructural Information and Communication Complexity - 22nd International Colloquium,SIROCCO 2015, Montserrat, Spain, July 14-16, 2015, Post-Proceedings, 2015, pp.194–208. [Online]. Available: http://dx.doi.org/10.1007/978-3-319-25258-2 14

[27] S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,” Bitcoin.org, 2008.[Online]. Available: http://www.bitcoin.org/bitcoin.pdf

[28] R. Pass, L. Seeman, and abhi shelat, “Analysis of the blockchain protocol in asynchronousnetworks,” Eurocrypt, 2017, http://eprint.iacr.org/2016/454.

[29] R. Pass and E. Shi, “Fruitchains: A fair blockchain,” Cryptology ePrint Archive, Report2016/916, 2016, http://eprint.iacr.org/2016/916.

[30] ——, “Hybrid consensus: Efficient consensus in the permissionless model,” CryptologyePrint Archive, Report 2016/917, 2016, http://eprint.iacr.org/2016/917.

[31] M. Rosenfeld, “Analysis of hashrate-based double spending,” http://arxiv.org/abs/1402.2009,2014.

[32] A. Sapirshtein, Y. Sompolinsky, and A. Zohar, “Optimal selfish mining strategies in Bit-coin,” in Financial Cryptography, 2016.

[33] Y. Sompolinsky, Y. Lewenberg, and A. Zohar, “Spectre: A fast and scalable cryptocurrencyprotocol,” 2016, https://eprint.iacr.org/2016/1159.

[34] Y. Sompolinsky and A. Zohar, “Secure high-rate transaction processing in bitcoin,” in 19thFinancial Cryptography and Data Security, 2015.

50

A. Some standard tail bounds for the Poissondistribution

We will use the following standard tail bounds on the Poisson distribution:

PrX∼Pois(λ)

[X ≤ x] ≤ e−λ (eλ)x

xx, for x < λ (A.0.1)

PrX∼Pois(λ)

[X ≥ x] ≤ e−λ (eλ)x

xx, for x > λ (A.0.2)

These imply for c > 1:

PrX∼Pois(λ)

[X ≤ λ/c] ≤ e−λc(c−ln c−1) = 2−λ

c−ln c−1c ln 2 (A.0.3)

PrX∼Pois(λ)

[X ≥ cλ] ≤ e−cλ(1c+ln c−1) ≤ 2−λ

cln 2

( 1c+ln c−1) (A.0.4)

or equivalently

PrX∼Pois(cλ)

[X ≤ λ] ≤ 2−λ(c−ln c−1)/ ln 2 (A.0.5)

PrX∼Pois(λc )

[X ≥ λ] ≤ 2−λ(1c+ln c−1)/ ln 2 (A.0.6)

For c = 2 the approximations are:

PrX∼Pois(λ)

[X ≤ 1

2λ

]≤ 2−

15λ (A.0.7)

PrX∼Pois(2λ)

[X ≤ λ] ≤ 2−25λ (A.0.8)

PrX∼Pois(λ)

[X ≥ 2λ] ≤ 2−12λ (A.0.9)

PrX∼Pois(λ/2)

[X ≥ λ] ≤ 2−14λ (A.0.10)

51

Nomenclature

M †i (A) The ith actual confirmation margin for a block A claiming to be in layer j < i, page 25

δ A bound on the combined network propagation time/local clock differences betweenhonest nodes, page 19

∆j−1 the number of blocks published by the adversary from its reserve at time startj + δ,page 25

Rj(i) the adversary’s reserve for blocks in layer i at time startj + δ (not including blocks thatwere published at time startj + δ), page 25

θ If the vote margin (sum of the votes) for a block is less than θ (in absolute value) nodeswill vote according to the output of the weak coin (instead of using the majority), page 19

Fi the adversary’s future reserve, subset of blocks in its reserve that claim to be in futurelayers (i or greater), at time starti, page 25

` The average length of a layer interval, page 18

`∗ε an upper bound on the duration of a layer, page 24

`−ε a lower bound on the duration of a layer in which the adversary is in the future-reservesteady-state, page 24

M(P )i (A) the ith confirmation margin for block A as seen by party P , page 25

tcoin Time for weak coin protocol (in multiples of δ), page 19

Tmin The minimum number of blocks in a layer, page 18

Yj the number of maliciously-generated blocks in the interval [startj + δ, startj+1 + δ],page 24

Y ∗ε an upper bound on the number of maliciously-generated blocks, page 24

Z∗ε a bound on the number of honestly-generated blocks in interval [startj + δ, startj+1],page 24

Zcoinj the number of non-abstaining blocks in layer j, page 24

52