pith. sign in

arxiv: 1906.11011 · v1 · pith:FQPEPOQUnew · submitted 2019-06-26 · 💻 cs.CR

Cryptocurrency Smart Contracts for Distributed Consensus of Public Randomness

Peter Mell , John Kelsey , James Shook This is my paper

Pith reviewed 2026-05-25 15:47 UTC · model grok-4.3

classification 💻 cs.CR
keywords smart contractsrandom number generationcryptocurrencypublic randomnessdistributed consensusblockchaincollusion
0
0 comments X

The pith

Smart contracts on a cryptocurrency can generate a public stream of random numbers that no provider can predict or control.

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

The paper demonstrates a method for generating public random numbers using smart contracts that accept inputs from multiple potentially malicious providers. The contract combines these inputs so that no single provider can foresee or alter the result, and the stored history remains equally uncontrollable. A second, more elaborate contract is introduced to reduce risks from collusion between providers and the miners who validate transactions. If the approach holds, applications that require unbiased public randomness can operate without depending on any trusted party. The design rests on the public and immutable execution of the contracts themselves.

Core claim

We use public and immutable cryptocurrency smart contracts, along with a set of potentially malicious randomness providers, to produce a trustworthy stream of timestamped public random numbers. Our contract eliminates the ability of a producer to predict or control the generated random numbers, including the stored history of random numbers. We consider and mitigate the threat of collusion between the randomness providers and miners in a second, more complex contract.

What carries the argument

The smart contract that accepts random inputs from multiple providers and combines them into an output value whose predictability is removed by the inclusion of all contributions.

If this is right

  • A continuous, timestamped stream of public random numbers becomes available without any single entity controlling the outcome.
  • The history of generated numbers cannot be retroactively altered by a provider.
  • Collusion between randomness providers and transaction miners can be addressed by an extended version of the contract.
  • Applications needing public randomness can draw from the contract output instead of trusting individual hardware sources.

Where Pith is reading between the lines

These are editorial extensions of the paper, not claims the author makes directly.

  • The same contract pattern might be adapted for other blockchain tasks that require distributed, unbiased selection.
  • Deployment on different cryptocurrencies could reveal whether the mitigation of miner collusion scales with network size.
  • The approach suggests a way to replace centralized random beacons with a publicly verifiable alternative.

Load-bearing premise

The cryptocurrency platform's smart contracts execute correctly and immutably, and the second contract successfully mitigates collusion between randomness providers and miners without introducing new attack vectors.

What would settle it

A concrete case in which one provider can compute the eventual output before all other inputs are submitted, or in which collusion with miners produces a biased or predictable result, would falsify the central claim.

Figures

Figures reproduced from arXiv: 1906.11011 by James Shook, John Kelsey, Peter Mell.

Figure 5
Figure 5. Figure 5: provides an example of two valid messages arriving to the contract [PITH_FULL_IMAGE:figures/full_fig_p010_5.png] view at source ↗
Figure 1
Figure 1. Figure 1: Fig.1 [PITH_FULL_IMAGE:figures/full_fig_p011_1.png] view at source ↗
read the original abstract

Most modern electronic devices can produce a random number. However, it is difficult to see how a group of mutually distrusting entities can have confidence in any such hardware-produced stream of random numbers, since the producer could control the output to their gain. In this work, we use public and immutable cryptocurrency smart contracts, along with a set of potentially malicious randomness providers, to produce a trustworthy stream of timestamped public random numbers. Our contract eliminates the ability of a producer to predict or control the generated random numbers, including the stored history of random numbers. We consider and mitigate the threat of collusion between the randomness providers and miners in a second, more complex contract.

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, simulated authors' rebuttal, and a circularity audit. Tearing a paper down is the easy half of reading it; the pith above is the substance, this is the friction.

Referee Report

2 major / 2 minor

Summary. The paper proposes using public and immutable cryptocurrency smart contracts together with a set of potentially malicious randomness providers to generate a trustworthy stream of timestamped public random numbers. It claims that the basic contract prevents any producer from predicting or controlling the output (including stored history), and introduces a second, more complex contract to mitigate collusion between randomness providers and miners.

Significance. If the contracts were shown to achieve the stated properties under standard blockchain assumptions, the work would supply a concrete, on-chain mechanism for decentralized public randomness that could be used in lotteries, cryptographic sortition, and other blockchain protocols. The design choice to separate a basic contract from a collusion-mitigation contract is a useful architectural distinction. However, the absence of any formal analysis, proofs, or threat-model evaluation substantially limits the significance of the current manuscript.

major comments (2)
  1. [Abstract] Abstract: the central claim that the contract 'eliminates the ability of a producer to predict or control the generated random numbers, including the stored history' is asserted without any accompanying security definition, threat model, game-theoretic argument, or reduction to blockchain assumptions.
  2. [Abstract] Abstract: the statement that the second contract 'successfully mitigates collusion between the randomness providers and miners' is presented as a solved problem, yet no description of the contract logic, no argument that it introduces no new attack vectors, and no analysis of reentrancy, ordering, or gas-related exploits is supplied.
minor comments (2)
  1. The manuscript would be strengthened by the inclusion of pseudocode or Solidity-style contract outlines for both the basic and collusion-mitigating contracts.
  2. A brief comparison to prior decentralized randomness beacons (e.g., RandHerd, Drand, or Ethereum 2.0 beacon chain) would help situate the contribution.

Simulated Author's Rebuttal

2 responses · 0 unresolved

We thank the referee for their comments, which highlight the need for clearer security arguments. We address each major comment below and indicate planned revisions to strengthen the manuscript.

read point-by-point responses

  1. Referee: [Abstract] Abstract: the central claim that the contract 'eliminates the ability of a producer to predict or control the generated random numbers, including the stored history' is asserted without any accompanying security definition, threat model, game-theoretic argument, or reduction to blockchain assumptions.

    Authors: The manuscript grounds its claim in the immutability and public verifiability of the underlying blockchain, which we argue prevents any single producer from altering past or future outputs once committed. We acknowledge that an explicit threat model and structured argument would improve clarity. We will add a dedicated section outlining the threat model and an informal reduction to standard blockchain assumptions (honest majority of miners, no reorgs beyond a given depth). revision: partial

  2. Referee: [Abstract] Abstract: the statement that the second contract 'successfully mitigates collusion between the randomness providers and miners' is presented as a solved problem, yet no description of the contract logic, no argument that it introduces no new attack vectors, and no analysis of reentrancy, ordering, or gas-related exploits is supplied.

    Authors: The full manuscript describes the second contract's logic (additional commitment rounds and miner-inclusion checks) in Section 4. We agree that the current text lacks explicit discussion of reentrancy, transaction ordering, and gas-related vectors. We will expand the section with a short analysis of these issues under the Ethereum model and argue that the design does not introduce new exploitable surfaces beyond those already present in standard contracts. revision: partial

Circularity Check

0 steps flagged

No circularity: protocol design without derivation chain

full rationale

The paper describes a smart-contract protocol for generating public randomness and mitigating collusion. No equations, fitted parameters, predictions, or self-citations appear in the abstract or described content. The central claims rest on the assumed correct execution of the contracts rather than any reduction of a result to its own inputs by construction. This is a standard non-finding for a design paper with no mathematical derivation.

Axiom & Free-Parameter Ledger

0 free parameters · 2 axioms · 0 invented entities

The design rests on the assumption that the underlying cryptocurrency platform provides immutable, correctly executing smart contracts and that the second contract variant adequately handles provider-miner collusion. No free parameters or invented entities are introduced in the abstract.

axioms (2)
  • domain assumption Cryptocurrency smart contracts execute as written and their state is immutable once deployed.
    This is required for the contract to eliminate control by any producer.
  • ad hoc to paper The second contract successfully mitigates collusion between randomness providers and miners.
    Stated as a consideration in the abstract but not detailed.

pith-pipeline@v0.9.0 · 5630 in / 1241 out tokens · 18038 ms · 2026-05-25T15:47:45.889861+00:00 · methodology

discussion (0)

Sign in with ORCID, Apple, or X to comment. Anyone can read and Pith papers without signing in.

Lean theorems connected to this paper

Citations machine-checked in the Pith Canon. Every link opens the source theorem in the public Lean library.

What do these tags mean?
matches
The paper's claim is directly supported by a theorem in the formal canon.
supports
The theorem supports part of the paper's argument, but the paper may add assumptions or extra steps.
extends
The paper goes beyond the formal theorem; the theorem is a base layer rather than the whole result.
uses
The paper appears to rely on the theorem as machinery.
contradicts
The paper's claim conflicts with a theorem or certificate in the canon.
unclear
Pith found a possible connection, but the passage is too broad, indirect, or ambiguous to say the theorem truly supports the claim.

Reference graph

Works this paper leans on

22 extracted references · 22 canonical work pages

  1. [1]

    Ethereumprice, https://ethereumprice.org/, accessed: 2017-06-27

    work page 2017

  2. [2]

    Litecoin, https://litecoin.org/, accessed: 2017-06-16

    work page 2017

  3. [3]

    National Institute of Standards and Technology Beacon Program, https://beacon.nist.gov/home, accessed: 2017-06-16

    work page 2017

  4. [4]

    Randao, https://github.com/randao/randao, accessed: 2017-07-10

    work page 2017

  5. [5]

    Solidity language, https://solidity.readthedocs.io/en/develop/, accessed: 2017-0616

    work page 2017

  6. [6]

    www.random.org, https://www.random.org/, accessed: 2017-07-10

    work page 2017

  7. [7]

    IACR Cryptology ePrint Archive 2015, 1249 (2015)

    Baign`eres, T., Delerabl´ee, C., Finiasz, M., Goubin, L., Lepoint, T., Rivain, M.: Trap me if you can - million dollar curve. IACR Cryptology ePrint Archive 2015, 1249 (2015)

    work page 2015

  8. [8]

    IACR Cryptology ePrint Archive 2015, 1015 (2015)

    Bonneau, J., C lark, J., Goldfeder, S.: On bitcoin as a public randomness source. IACR Cryptology ePrint Archive 2015, 1015 (2015)

    work page 2015

  9. [9]

    IEEE Security & Privacy on the Blockchain (2017), http://www.jbonneau.com/publications.html

    Bunz, Goldfeder, B.: Proofs -of-delay and randomness beacons in ethereum. IEEE Security & Privacy on the Blockchain (2017), http://www.jbonneau.com/publications.html

    work page 2017

  10. [10]

    IACR Cryptology ePrint Archive 2010, 361 (2010), http://eprint.iacr.org/2010/361

    Clark, J., Hengartner, U.: On the use of financial data as a random beacon. IACR Cryptology ePrint Archive 2010, 361 (2010), http://eprint.iacr.org/2010/361

    work page 2010

  11. [11]

    In: Se curity and Cryptography (SECRYPT), 2011 Proceedings of the International Conference on

    Fischer, M.J., Iorga, M., Peralta, R.: A public randomness service. In: Se curity and Cryptography (SECRYPT), 2011 Proceedings of the International Conference on. pp. 434–438. IEEE (2011)

    work page 2011

  12. [12]

    Kelsey, J.: The new nist beacon protocol and combining beacons (2017)

    work page 2017

  13. [13]

    IAC R Cryptology ePrint Archive 2015, 366 (2015)

    Lenstra, A.K., Wesolowski, B.: A random zoo: sloth, unicorn, and trx. IAC R Cryptology ePrint Archive 2015, 366 (2015)

    work page 2015

  14. [14]

    Internet Engineering Task Force (IETF), 2010

    Mills, D., Martin, J., Burbank, J., Kasch, W.: RFC 5905: Network Time Protocol Version 4: Protocol and Algorithms Specification. Internet Engineering Task Force (IETF), 2010. tools. ietf. org/html/rfc5905

    work page 2010

  15. [15]

    Nakamoto, S.: Bitcoin: A peer-to-peer electronic cash system (2008)

    work page 2008

  16. [16]

    Journal of Computer and System Sciences 27(2), 256–267 (1983)

    Rabin, M.O.: Transaction protection by beacons. Journal of Computer and System Sciences 27(2), 256–267 (1983)

    work page 1983

  17. [17]

    Rivest, R.L., Shamir, A., Wagner, D.A.: Time -lock puzzles and timed -release crypto (1996)

    work page 1996

  18. [18]

    Oxford University Press (1960)

    Schelling, T.C.: The Strategy of Conflict. Oxford University Press (1960)

    work page 1960

  19. [19]

    In: 2017 IEEE Symposium on Security and Privacy, SP 2017, San Jose, CA, USA, May 22-26, 2017

    Syta, E., Jovanovic, P., Kokoris -Kogias, E., Gailly, N., Gasser, L., Khoffi, I., Fischer, M.J., Ford, B.: Scalable bias-resistant distributed randomness. In: 2017 IEEE Symposium on Security and Privacy, SP 2017, San Jose, CA, USA, May 22-26, 2017. pp. 444–460 (2017), https://doi.org/10.1109/SP.2017.45

    work page doi:10.1109/sp.2017.45 2017

  20. [20]

    Proceedings of the London mathematical soci ety 2(1), 230 – 265 (1937)

    Turing, A.M.: On computable numbers, with an application to the entscheidungsproblem. Proceedings of the London mathematical soci ety 2(1), 230 – 265 (1937)

    work page 1937

  21. [21]

    Ace Books (1987)

    White, T.H.: The Once and Future King. Ace Books (1987)

    work page 1987

  22. [22]

    Ethereum Project Yellow Paper 151 (2014)

    Wood, G.: Ethereum: A secure decentralised generalised transaction ledger. Ethereum Project Yellow Paper 151 (2014)

    work page 2014