A scalable verification solution for blockchains

Christian Reitwie{\ss}ner; Jason Teutsch

REVIEW 3 major objections 4 minor 1 cited by

A scalable verification solution for blockchains

T0 review · 3 major / 4 minor · reviewed 2026-08-14 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read The paper claims that TrueBit, by pairing an interactive verification game with a financial incentive layer, lets Ethereum smart contracts securely perform computation tasks of arbitrary size without trusting any single party.

desk verdict Clever incentive design and honest about attacks, but the 'any computation' claim depends on an equilibrium the paper admits it cannot pin down. read the letter →

arxiv 1908.04756 v1 pith:PGT4FKQA submitted 2019-08-12 cs.CR econ.TH

Jason Teutsch , Christian Reitwie{ss}ner This is my paper · ORCID

classification cs.CRecon.TH

keywords TrueBitverificationgameblockchainscalabilityoutsourcedcomputationsmartcontractsrationalincentivesEthereumVerifier'sDilemma

verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

TrueBit is a proposed Ethereum-based system that claims to let smart contracts securely perform arbitrary computational tasks, overcoming the severe limit that currently makes Ethereum's collective power comparable to a smartphone. The paper's key move is to separate the job of verifying computation from the job of maintaining the blockchain: a verification game shrinks any dispute to a single machine step, while forced errors, jackpots, and deposits make it rational for at least one anonymous Verifier to check every task. This matters because, if the system works, Ethereum contracts could call subroutines far beyond the gas limit, with applications ranging from trustless mining pools to cross-currency bridges. The paper also makes explicit which parameters must be set correctly, and which assumptions about rational behavior, for the security argument to hold.

What carries the argument

The central mechanism is the verification game, an interactive dispute-resolution protocol in which a Solver and Challenger repeatedly split the contested computation into chunks and commit to each chunk's machine state via Merkle roots; after about $\log t/\log c$ rounds only one machine step remains, and Ethereum miners acting as Judges check that single step directly. This makes the Judges' work logarithmic in the runtime $t$ and polylogarithmic in the space $s$, so the network never re-executes the task. Around this game sits the incentive layer: forced errors occur randomly about once per thousand tasks, a jackpot funded by a 500–5000% tax pays Verifiers who catch them, deposits must exceed expected jackpot plus game costs, and a challenge payout of $J/2^{k-1}$ prevents collusion pools from flooding challenges. Together these pieces are what the paper claims converts Ethereum's small trusted kernel into a universal outsourced computer.

What would settle it

Run a small, public TrueBit-style market with the paper's stated parameters (forced-error rate 1/1000, 500–5000% tax, deposits above expected jackpot) and post a deliberately wrong but unforced solution to a near-maximum-difficulty task, after setting the reward from the paper's cash-equivalent price feed; if no unaffiliated Verifier challenges it within the timeout, the economic guarantee that at least one Verifier checks every task is empirically false.

Watch

Extended reading notes

Core claim

The paper's central claim is that a financial incentive layer atop an interactive verification game lets a blockchain like Ethereum securely execute arbitrary computations without expanding what miners must verify. Correctness does not come from redundancy or from heavy cryptography such as SNARKs; it comes from economics. TrueBit forces errors to occur unpredictably by having Solvers commit both a correct and an incorrect answer and then use post-commitment randomness to decide which one to reveal, so Verifiers cannot know which tasks are safe to skip. The verification game then guarantees that any disputed answer can be settled by having the Judges check just one computational step. The paper argues that, under its rationality and trusted-network assumptions, at least one Verifier will always find it profitable to check any given task, and therefore smart contracts can in theory outsource any computation task while keeping universal validity.

Load-bearing premise

The promise holds only if at least one profit-seeking Verifier can always be induced to check each task; that requires a reliable real-world price for computational work in the cryptocurrency's own currency, and the paper admits the tax rate and price feed are not set by the protocol itself.

Editorial extensions

If this is right

Smart contracts could call subroutines far beyond Ethereum's gas limit, so tasks like checking a Zcash proof-of-work become executable on-chain.
Miners would no longer have to re-execute every contract; only a small dispute-resolution transcript reaches the chain, reducing redundant work across the network.
The same machinery yields trustless pooled mining for any Nakamoto-consensus cryptocurrency, a Dogecoin–Ethereum two-way peg, and higher transaction throughput by decoupling transaction selection from verification.
Because forced errors are unpredictable and jackpots scale with task difficulty, Verifiers have a standing financial reason to check every task, making correctness independent of any single honest party's goodwill.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

If the price-feed fragility turns out to be real, the natural fix is to let the protocol adjust tax and deposit parameters dynamically from observed Verifier participation, rather than fixing them as constants; the paper only hints at experimental tuning.
The same interactive game could be reused outside blockchains wherever a cheap, trusted arbiter can check a single step of a computation, such as cloud-service audits, though deposits would have to be replaced by another penalty mechanism.
The guarantee is statistical rather than cryptographic: forced errors are rare and hidden, so a future formal treatment would need to bound the Verifier's expected payoff under adversarial scheduling of tasks, going beyond the paper's default random task-selection strategy.
A testable consequence of the jackpot-sharing rule is that total payout decays as $J/2^{k-1}$; one could measure whether Verifier participation actually drops as challenge counts rise, as the rule predicts.

Share X Bluesky LinkedIn Reddit HN

Signed reviews

No signed human review yet.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Desk Editor's Note

read the letter

Colleague,

The takeaway: TrueBit is the paper that made off-chain verification with economic incentives concrete for Ethereum, and it still rewards a careful read. The verification game is not new — the authors credit Canetti, Riva, and Rothblum — but the forced-error mechanism, where a Solver is occasionally required to submit a wrong answer so that Verifiers have a real chance to find bugs, is a genuinely new idea and is the part worth studying.

What the paper does well: it explains the two-layer design clearly, gives honest complexity numbers for the dispute-resolution game (log_t/log_c rounds, small on-chain footprint), and explicitly builds on prior work rather than hiding it. The addendum is unusually candid: several real attacks — premature random-bit disclosure, incorrect secondary solution, jackpot ballooning, incentivized block withholding — are described and patched. That is more honesty than most whitepapers show.

The soft spot is exactly what the stress-test note says. Section 5 opens by stating that security relies on at least one Verifier checking every task, and then argues incentives suffice. But the argument is heuristic. Section 4.2 fixes the tax rate at 500–5000% by estimate and says the optimal rate must be determined experimentally. Section 5.5 says the 'cash equivalent of a CPU cycle' will initially be maintained by manual price-feed updates. The 99% catch probability in the 'trifecta' section is conditional on the tax rate supporting six Verifiers per task, which is exactly the unproven assumption. The addendum's attacks show the original protocol had holes that were not anticipated. None of this means the design is worthless; it means the load-bearing claim — 'trustless smart contracts can securely perform any computation' — is not established. The paper says 'in theory,' and that caveat is doing real work.

Who should read it: anyone designing blockchain computation markets, verifying-computation protocols, or incentive layers for decentralized systems. It is an important design document, not a formal security proof.

My recommendation: send it to peer review, not desk reject. The ideas are significant and the authors are honest about limitations. But a serious referee should demand either a formal game-theoretic analysis of the incentive equilibrium or a working implementation with resolved parameters before the central claim is accepted.

Referee Report

3 major / 4 minor

Summary. The paper presents TrueBit, a two-layer protocol for scalable, trustless outsourced computation on Ethereum. The dispute resolution layer is an interactive verification game, based on prior work of Canetti, Riva, and Rothblum, in which a Solver and a Challenger narrow a dispute to a single computational step that Ethereum miners ('Judges') verify; Section 3.4 gives an O((log t / log c)(cσ + log c) + 2((2σ+1)log s + 5 + p)) bound on the judges' verification work. The incentive layer uses a jackpot funded by taxes, security deposits, and randomly inserted 'forced errors' so that rational Verifiers have reason to check every task; the full protocol is summarized in Section 4.6. Section 5 argues that pairwise Sybil attacks, collusion pools, and shortcut attacks are unprofitable, and Section 7 sketches applications including decentralized pooled mining, a dogecoin–Ethereum bridge, and scalable transaction throughput. An addendum records several discovered attacks and proposed patches.

Significance. If the security claims held, TrueBit would be a practically significant extension of Ethereum's computational capacity and a rare non-PCP, incentive-based alternative to verifiable computing. The paper's strengths are its clean modular separation of dispute resolution from incentives, a concrete and checkable complexity estimate for the verification game, and an unusually candid addendum that documents real attacks and patch ideas rather than presenting the protocol as complete. However, the claimed security guarantee is not proven: the central equilibrium assumption is stated rather than derived, and the addendum shows that the main-text protocol already had exploitable vulnerabilities. The paper would be a useful system description for a workshop, but for a journal it needs a formal security model and a proof or precise calibration argument for the incentive equilibrium.

major comments (3)

[§5, §5.2, §5.5] The central security guarantee is assumed, not derived. Section 5 opens with 'TrueBit's security relies on the presence of at least one Verifier to check each task performed,' but no theorem or model establishes that the chosen parameters ensure such a Verifier exists. Section 4.2 fixes the verification tax at 500%–5000% and concedes that the optimal rate 'must, at least in part, be determined experimentally'; Section 5.5 states that the 'cash equivalent of a CPU cycle' is initially updated manually. Section 5.2's quantitative catch probability (>99%) explicitly assumes 'the tax rate ... supports at least 6 Verifiers per task' and that the adversary controls at most 1/6 of Verifier deposits. These are exactly the facts that need proof. Without an equilibrium existence argument or a rational-security model, the scenario of Section 5.5—a minimal-reward hard task that no Verifier checks—remains a live counterexample to the paper's headline claim.
[§A.1] The addendum reports five attacks against the protocol as described in the main text: premature disclosure of random bits, incorrect secondary solution, program abort, jackpot balloon attack, and incentivizing block withholding. The first two directly negate the 'at least one Verifier' guarantee used in Section 5 and the randomness properties claimed in Section 4.4. The main text, including the protocol overview in Section 4.6, the parameter table in Section 4.7, and the defenses in Section 5, is never revised to incorporate the patches; the paper even uses the unpatched protocol in the prose after the addendum. The authors should integrate the patches into the main protocol and re-state the security analysis against the patched protocol, or explicitly label which version is analyzed. As written, the reader cannot verify whether the promised security properties hold for the protocol actually described in the body.
[§3.4, §2] The claim that TrueBit 'enables trustless smart contracts, in theory, to securely perform any computation task' is stronger than what the dispute-resolution analysis supports. Section 3.4 acknowledges that Merkle-root hash collisions bound the maximum secure task size, stating that 'the choice of σ bounds the maximum complexity of secure computations in TrueBit,' and Section 4.1 adds that the jackpot size imposes another capacity bound. This is not intrinsically wrong, but it should be formalized as a size-bounded soundness statement for the verification game, with explicit collision probabilities and matching jackpot constraints, rather than left as an informal remark. The abstract and Section 2 should correspondingly qualify 'any computation task.'

minor comments (4)

[§4.4] The text contains a typo, 'a prioiri', for 'a priori'; the same section claims Verifiers do not know the random bits until after deciding whether to challenge, but the addendum's 'premature disclosure of random bits' attack shows this property fails for a malicious Solver unless the patch is integrated.
[§4.6] There are several small typos in Step 4(b)ii: 'Verifer' should be 'Verifier', and 'solution solution' should be 'solution'. In §3.2, 'challengers' should be 'challenges'.
[§4.7] The parameter table lists the tax rate as a 'fixed constant (500% – 5000%)', but §4.2 says the optimal tax rate 'must, at least in part, be determined experimentally.' These statements should be reconciled.
[§6, §A.2] Section 6 commits to the Google Lanai architecture, while Addendum A.2 states that the project has migrated away from Lanai to a WebAssembly-based TrueBit Virtual Machine. The main text should be updated to describe the actually implemented architecture.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the verification game is credited to independent prior work, and the incentive parameters are openly estimated rather than fitted-then-predicted.

full rationale

The paper's central claim is a construction: a financial incentive layer on top of an interactive verification game. The verification game itself is explicitly attributed to Canetti, Riva and Rothblum [39,40], with the authors' own [46,58] described as an independent rediscovery used for concrete parameters; the security of that game is analyzed in Section 3.4 from hash sizes, round counts, and Turing-machine configurations rather than assumed. The incentive layer's key parameters, including the forced-error rate of 1/1000, the tax rate of 500%-5000%, the maximum jackpot of one-third of the repository, and deposits exceeding expected jackpot payouts, are presented as chosen constants or as estimates; Section 4.2 expressly states that the optimal tax rate 'must, at least in part, be determined experimentally,' and Section 5.5 says the CPU-cycle cash equivalent will initially be manually updated. No quantity is fitted to a data subset and then renamed a prediction. The only self-citations ([46], [50], [58], [51], [62]) support background assumptions or parallel work; in particular [50] is used to justify the stated assumption that Ethereum correctly performs small computations, and the paper explicitly says the Judges could be replaced by 'any other universally trusted computing mechanism.' The Section 5.2 >99% catch calculation is conditional on the asserted tax rate supporting at least six verifiers; that rate is an openly acknowledged design and heuristic parameter, not an output smuggled from the same equation. The addendum patches identified vulnerabilities, but acknowledging and fixing attacks is not circularity. Therefore no derivation step reduces by construction or by self-citation to its own inputs.

Assumptions & free parameters 4 free parameters · 7 assumptions · 1 invented entities

The central claim rests on a set of economic and network assumptions that the paper explicitly states. The free parameters are hand-chosen or left to participants, and the paper admits that key values like the tax rate require experimental determination. The TVM is an invented architectural entity without independent verification.

free parameters (4)

forced_error_rate = 1/1000 tasks
Chosen by hand in Section 4.1 to balance Verifier participation against Referee bias. The security analysis assumes this rate without deriving it.
verification_tax_rate = 500% - 5000% of task cost
Estimated in Section 4.2 to fund jackpots and ensure at least one Verifier per task; paper says it must be determined experimentally.
maximum_jackpot_payout_fraction = 1/3 of repository
Set in Section 4.2 to ensure the jackpot repository never disappears; arbitrary cap.
minDeposit = set by Task Giver
Protocol requires deposits larger than expected jackpot payout plus verification game cost (Section 4.3), but the value is an input not derived by the paper.

assumptions (7)

domain assumption Ethereum correctly performs very small computation tasks
Assumption (i) in Section 2.2; the Judges in the verification game always adjudicate correctly.
domain assumption Participants are rational and act to maximize individual profit
Assumption (ii) in Section 2.2; the entire incentive layer depends on this behavioral model.
domain assumption Censorship of individual transactions does not happen on Ethereum
Stated in Section 2.2; if miners censor challenges, bogus solutions can be accepted.
domain assumption Attackers cannot subvert the underlying consensus computer
Attacker model assumption (i) in Section 2.3; removes 51% attacks from scope.
domain assumption Attackers have limited financial resources
Attacker model assumption (ii) in Section 2.3; used in Section 5.2 to bound the scare-off attack.
standard math Hash functions used in Merkle trees are collision resistant
Relied on in Section 3.4; hash collisions could allow substitution of computation tableaus.
domain assumption A reliable cash equivalent of a CPU cycle can be established
Section 5.5 admits this is unsolved; the tax rate and minimum reward depend on it.

invented entities (1)

TrueBit Virtual Machine (TVM)
purpose: A WebAssembly-based deterministic architecture so Solvers, Verifiers, and Judges agree on single computation steps in the verification game
Described in Addendum A.2 as a replacement for Google Lanai; no formal specification or implementation is provided in the paper, so there is no independent testable handle.

how reviews work

0 comments

Cite this review

Pith. "Pith review of A scalable verification solution for blockchains." pith.science (2026). https://pith.science/paper/PGT4FKQA

@misc{pith2026190804756,
  author       = {Pith},
  title        = {Pith review of: A scalable verification solution for blockchains},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/PGT4FKQA}},
  note         = {Machine review of arXiv:1908.04756}
}

read the original abstract

Bitcoin and Ethereum, whose miners arguably collectively comprise the most powerful computational resource in the history of mankind, offer no more power for processing and verifying transactions than a typical smart phone. The system described herein bypasses this bottleneck and brings scalable computation to Ethereum. Our new system consists of a financial incentive layer atop a dispute resolution layer where the latter takes form of a versatile "verification game." In addition to secure outsourced computation, immediate applications include decentralized mining pools whose operator is an Ethereum smart contract, a cryptocurrency with scalable transaction throughput, and a trustless means for transferring currency between disjoint cryptocurrency systems.

Discussion (0). Continue with ORCID to comment.

Forward citations

Cited by 1 Pith paper

Reviewed papers in the Pith corpus that reference this work. Sorted by Pith novelty score. Full citation record

Chainless Apps: A Modular Framework for Building Apps with Web2 Capability and Web3 Trust
cs.CR 2025-05 conditional novelty 4.0 of 10

A framework for blockchain apps that separates off-chain execution, verification, cross-chain messaging, and on-chain settlement, designed to combine Web2 speed with Web3 verifiability.

Reference graph

Works this paper leans on

65 extracted references · 64 canonical work pages · cited by 1 Pith paper

[1]

http://1protocol.com

1protocol. http://1protocol.com

work page
[2]

https://www.augur.net/

Augur. https://www.augur.net/

work page
[3]

http://www.newsbtc.com/2016/11/ 04/bitmain-response-new-mining-center/

Bitmain responds to controversy surrounding its upcomi ng 140,000 kw mining center. http://www.newsbtc.com/2016/11/ 04/bitmain-response-new-mining-center/

work page 2016
[4]

http://coinmarketcap

Crypto-currency market capitalizations. http://coinmarketcap. com/

work page
[5]

https://www

The Doge connection Bounty Dao is live and working. https://www. reddit.com/r/ethereum/comments/41ohhr/the_doge_connection_ bounty_dao_is_live_and_working/

work page
[6]

http://dogecoin.com/

Dogecoin. http://dogecoin.com/

work page
[7]

https://etherscan.io/ address/0xdbf03b407c01e7cd3cbea99509d93f8dddc8c6fb

Dogecoin–Ethereum bounty smart contract. https://etherscan.io/ address/0xdbf03b407c01e7cd3cbea99509d93f8dddc8c6fb

work page
[8]

https://www.reddit.com/r/dogethereum/

Dogethereum. https://www.reddit.com/r/dogethereum/. 45

work page

Show all 65 references

[9]

http://forum.ethereum.org/discussion/ 5244/dwarfpool-is-now-50-5

Dwarfpool is now 50.5%. http://forum.ethereum.org/discussion/ 5244/dwarfpool-is-now-50-5
[10]

https://github.com/ethereum/ wiki/wiki/Ethash#defining-the-seed-hash

Ethash: deﬁning the seed hash. https://github.com/ethereum/ wiki/wiki/Ethash#defining-the-seed-hash
[11]

http://ethereum.org/

Ethereum. http://ethereum.org/
[12]

http://www

Ethereum Computation Market. http://www. ethereum-computation-market.com/
[13]

http://github.com/imapp-pl/golem/wiki/FAQ

Golem. http://github.com/imapp-pl/golem/wiki/FAQ
[14]

https://golem

The Golem Project: crowdfunding whitepaper. https://golem. network/doc/Golemwhitepaper.pdf
[15]

http://llvm.org/docs/CompilerWriterInfo.html# lanai

Google Lanai. http://llvm.org/docs/CompilerWriterInfo.html# lanai
[16]

https:// www.reddit.com/r/ethereum/comments/55xh2w/i_thikn_the_ attacker_is_this_miner_today_he_made/

I thikn the attacker is this miner—today he made over $50 k. https:// www.reddit.com/r/ethereum/comments/55xh2w/i_thikn_the_ attacker_is_this_miner_today_he_made/
[17]

https://z.cash/blog/ project-alchemy.html

Introducing Project Alchemy. https://z.cash/blog/ project-alchemy.html
[18]

https://livepeer.org/

Livepeer. https://livepeer.org/
[19]

https://numer.ai

Numerai. https://numer.ai
[20]

https://oceanprotocol.com/

Ocean Protocol. https://oceanprotocol.com/
[21]

https://openmined.org/

Open Mined. https://openmined.org/
[22]

https://github.com/TrueBitFoundation/ Developer-Resources/wiki/Open-Problems

Open problems. https://github.com/TrueBitFoundation/ Developer-Resources/wiki/Open-Problems
[23]

http://www.oraclize.it/

Oraclize. http://www.oraclize.it/
[24]

http://p2pool.org/

P2Pool. http://p2pool.org/
[25]

https://github.com/randao/randao

RANDAO. https://github.com/randao/randao
[26]

https://www.realitykeys.com/

Reality Keys. https://www.realitykeys.com/
[27]

http://smartpool.io

SmartPool. http://smartpool.io. 46
[28]

http://swarm-gateways.net/

Swarm. http://swarm-gateways.net/
[29]

http://daohub.org/

The DAO. http://daohub.org/
[30]

http://www.cryptocoinsnews.com/ warning-ghash-io-nearing-51-leave-pool/

Warning: Ghash.io is nearing 51% – leave the pool. http://www.cryptocoinsnews.com/ warning-ghash-io-nearing-51-leave-pool/
[31]

http://webassembly.org/

WebAssembly. http://webassembly.org/
[32]

https://github.com/ethereum/wiki/wiki/ White-Paper

White paper. https://github.com/ethereum/wiki/wiki/ White-Paper
[33]

Why Equihash? https://z.cash/blog/why-equihash.html
[34]

https://z.cash/

Zcash. https://z.cash/
[35]

https://bitcoin.org/en/ alert/2015-07-04-spv-mining , July 2015

Some miners generating invalid blocks. https://bitcoin.org/en/ alert/2015-07-04-spv-mining , July 2015

2015
[36]

Solidus: An incentive-compatible cryptocurr ency based on permissionless Byzantine consensus

Ittai Abraham, Dahlia Malkhi, Kartik Nayak, Ling Ren, a nd Alexander Spiegelman. Solidus: An incentive-compatible cryptocurr ency based on permissionless Byzantine consensus. https://arxiv.org/abs/1612. 02916, 2016

2016
[37]

SNARKs for C: Verifying program executions su ccinctly and in zero knowledge

Eli Ben-Sasson, Alessandro Chiesa, Daniel Genkin, Era n Tromer, and Madars Virza. SNARKs for C: Verifying program executions su ccinctly and in zero knowledge. In Ran Canetti and Juan A. Garay, edito rs, Advances in Cryptology – CRYPTO 2013: 33rd Annual Cryptology Conference, ...

2013
[38]

Indistin- guishability obfuscation vs

Nir Bitansky, Ran Canetti, Omer Paneth, and Alon Rosen. Indistin- guishability obfuscation vs. auxiliary-input extractabl e functions: One must fall. https://eprint.iacr.org/2013/468.pdf

2013
[39]

Rothblum

Ran Canetti, Ben Riva, and Guy N. Rothblum. Practical de legation of computation using multiple servers. In Proceedings of the 18th ACM Conference on Computer and Communications Security, CCS ’11, pages 445–454, New York, NY, USA, 2011. ACM

2011
[40]

Rothblum

Ran Canetti, Ben Riva, and Guy N. Rothblum. Refereed del egation of computation. Information and Computation , 226:16 – 36, 2013. Special Issue: Information Security as a Resource. 47

2013
[41]

On scaling dec en- tralized blockchains (a position paper)

Kyle Croman, Christian Decker, Ittay Eyal, Adem Efe Gen cer, Ari Juels, Ahmed Kosba, Andrew Miller, Prateek Saxena, Elaine S hi, Emin G¨ un Sirer, Dawn Song, and Roger Wattenhofer. On scaling dec en- tralized blockchains (a position paper). In Financial Cryptography and Data S...

2016
[42]

Bitcoin meets strong consistency

Christian Decker, Jochen Seidel, and Roger Wattenhofe r. Bitcoin meets strong consistency. In Proceedings of the 17th International Conference on Distributed Computing and Networking , ICDCN ’16, pages 13:1– 13:10, New York, NY, USA, 2016. ACM

2016
[43]

Bitcoin-NG: A scalable blockchain protocol

Ittay Eyal, Adem Efe Gencer, Emin Gun Sirer, and Robbert Van Re- nesse. Bitcoin-NG: A scalable blockchain protocol. In 13th USENIX Symposium on Networked Systems Design and Implementation (N SDI 16), pages 45–59, Santa Clara, CA, March 2016. USENIX Associati on

2016
[44]

AdversariallyVeriﬁableMachine

Tim Goddard. AdversariallyVeriﬁableMachine. https://www.reddit. com/r/ethereum/comments/51qjz6/interactive_verification_ of_c_programs/d7ey41n/
[45]

Schuﬀ, Ben L

Andreas Haas, Andreas Rossberg, Derek L. Schuﬀ, Ben L. Ti tzer, Michael Holman, Dan Gohman, Luke Wagner, Alon Zakai, and JF Bastien. Bringing the web up to speed with WebAssembly. In Proceedings of the 38th ACM SIGPLAN Conference on Programming Language Design and Implementati...

2017
[46]

How to verify computation with a rational network

Sanjay Jain, Prateek Saxena, Frank Stephan, and Jason T eutsch. How to verify computation with a rational network. https://arxiv.org/ abs/1606.05917, June 2016

2016 arXiv
[47]

Enhancing Bitcoin secur ity and performance with strong consistency via collective signin g

Eleftherios Kokoris Kogias, Philipp Jovanovic, Nicol as Gailly, Ismail Khoﬃ, Linus Gasser, and Bryan Ford. Enhancing Bitcoin secur ity and performance with strong consistency via collective signin g. In 25th USENIX Security Symposium (USENIX Security 16) , pages 279–296, Austi...

2016
[48]

Kroll, Ian C

Joshua A. Kroll, Ian C. Davey, and Edward W. Felten. The economics of Bitcoin mining, or Bitcoin in the presence of ad ver- saries. http://www.econinfosec.org/archive/weis2013/papers/ KrollDaveyFeltenWEIS2013.pdf, June 2013. 48

2013
[49]

A secure sharding protocol for open blockchains

Loi Luu, Viswesh Narayanan, Chaodong Zheng, Kunal Bawe ja, Seth Gilbert, and Prateek Saxena. A secure sharding protocol for open blockchains. In Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security , CCS ’16, pages 17–30, New York, NY, USA, 2016. ACM

2016
[50]

Demys- tifying incentives in the consensus computer

Loi Luu, Jason Teutsch, Raghav Kulkarni, and Prateek Sa xena. Demys- tifying incentives in the consensus computer. In Proceedings of the 22nd ACM SIGSAC Conference on Computer and Communications Security (CCS 2015) , pages 706–719, New York, NY, USA, 2015. ACM

2015
[51]

Smart- Pool: Practical decentralized pooled mining

Loi Luu, Yaron Welner, Jason Teutsch, and Prateek Saxen a. Smart- Pool: Practical decentralized pooled mining. http://smartpool.io/ docs/smartpool.pdf
[52]

Wild, wooly AI DAOs

Trent McConaghy. Wild, wooly AI DAOs. https://blog.bigchaindb. com/wild-wooly-ai-daos-d1719e040956
[53]

ALGORAND: the eﬃcient and democratic le dger

Silvio Micali. ALGORAND: the eﬃcient and democratic le dger. http://arxiv.org/abs/1607.01341, 2016

2016 arXiv
[54]

Nonout- sourceable scratch-oﬀ puzzles to discourage Bitcoin minin g coalitions

Andrew Miller, Ahmed Kosba, Jonathan Katz, and Elaine S hi. Nonout- sourceable scratch-oﬀ puzzles to discourage Bitcoin minin g coalitions. In Proceedings of the 22Nd ACM SIGSAC Conference on Computer and Communications Security , CCS ’15, pages 680–691, New York, NY, USA, 2015. ACM

2015
[55]

The honey badger of BFT protocols

Andrew Miller, Yu Xia, Kyle Croman, Elaine Shi, and Dawn Song. The honey badger of BFT protocols. In Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security , CCS ’16, pages 31–42, New York, NY, USA, 2016. ACM

2016
[56]

Bitcoin P2P e-cash paper

Satoshi Nakamoto. Bitcoin P2P e-cash paper. http://www. mail-archive.com/cryptography@metzdowd.com/msg09959 .html, November 2008

2008
[57]

Hybrid consensus: Eﬃcient c onsensus in the permissionless model

Rafael Pass and Elaine Shi. Hybrid consensus: Eﬃcient c onsensus in the permissionless model. https://eprint.iacr.org/2016/917.pdf, 2016

2016
[58]

From smart contracts to court s with not so smart judges

Christian Reitwiessner. From smart contracts to court s with not so smart judges. https://blog.ethereum.org/2016/02/17/ smart-contracts-courts-not-smart-judges/ . 49

2016
[59]

zkSNARKs in a nutshell

Christian Reitwiessner. zkSNARKs in a nutshell. https://blog. ethereum.org/2016/12/05/zksnarks-in-a-nutshell/ , Dececmber 2016

2016
[60]

S PECTRE: A fast and scalable cryptocurrency protocol

Yonatan Sompolinsky, Yoad Lewenberg, and Aviv Zohar. S PECTRE: A fast and scalable cryptocurrency protocol. https://eprint.iacr. org/2016/1159.pdf, 2016

2016
[61]

The idea of smart contracts

Nick Szabo. The idea of smart contracts. http://szabo.best.vwh. net/smart_contracts_idea.html, 1997

1997
[62]

When cr yptocur- rencies mine their own business

Jason Teutsch, Sanjay Jain, and Prateek Saxena. When cr yptocur- rencies mine their own business. In Financial Cryptography and Data Security: 20th International Conference (FC 2016) Christ Churc h, Bar- bados, pages 499–514. Springer Berlin / Heidelberg, 2017

2016
[63]

Frans Kaashoek, and Nickolai Zeldo vich

Jelle van den Hooﬀ, M. Frans Kaashoek, and Nickolai Zeldo vich. Ver- sum: Veriﬁable computations over large public logs. In Proceedings of the 2014 ACM SIGSAC Conference on Computer and Communications Security, CCS ’14, pages 1304–1316, New York, NY, USA, 2014. ACM

2014
[64]

Smart contrac ts make Bit- coin mining pools vulnerable

Yaron Velner, Jason Teutsch, and Loi Luu. Smart contrac ts make Bit- coin mining pools vulnerable. To appear in 4th Workshop on Bitcoin and Blockchain Research (BITCOIN 2017)

2017
[65]

Blumberg

Michael Walﬁsh and Andrew J. Blumberg. Verifying compu tations without reexecuting them. Communications of the ACM , 58(2):74–84, January 2015. 50

2015

Pith tools

Reviewed August 14, 2026 · model on record in the stance chip above.

[1] [1]

http://1protocol.com

1protocol. http://1protocol.com

work page

[2] [2]

https://www.augur.net/

Augur. https://www.augur.net/

work page

[3] [3]

http://www.newsbtc.com/2016/11/ 04/bitmain-response-new-mining-center/

Bitmain responds to controversy surrounding its upcomi ng 140,000 kw mining center. http://www.newsbtc.com/2016/11/ 04/bitmain-response-new-mining-center/

work page 2016

[4] [4]

http://coinmarketcap

Crypto-currency market capitalizations. http://coinmarketcap. com/

work page

[5] [5]

https://www

The Doge connection Bounty Dao is live and working. https://www. reddit.com/r/ethereum/comments/41ohhr/the_doge_connection_ bounty_dao_is_live_and_working/

work page

[6] [6]

http://dogecoin.com/

Dogecoin. http://dogecoin.com/

work page

[7] [7]

https://etherscan.io/ address/0xdbf03b407c01e7cd3cbea99509d93f8dddc8c6fb

Dogecoin–Ethereum bounty smart contract. https://etherscan.io/ address/0xdbf03b407c01e7cd3cbea99509d93f8dddc8c6fb

work page

[8] [8]

https://www.reddit.com/r/dogethereum/

Dogethereum. https://www.reddit.com/r/dogethereum/. 45

work page