Distrib. Random Process for a large-scale P2P Lottery

Robert Riemann with supervision of Stéphane Grumbach

image: DPA

Lottery Business

Security of the Lottery

To ensure fair-play and trust of the players:

  • strict legal regulations (State Lottery only)
  • technical procedure, the Lottery protocol
The Lottery Protocol shall provide legitimacy for the lottery outcome.

Lottery Protocol Properties

  • Correctness of the Random Process
  • Verifiability of the Random Process
  • Privacy of the Player
  • Eligibility of the Ticket
  • Confidentiality of the Number
  • Completeness of the Reward

A Secure Lottery

  • players buy tickets from Authority in person
  • player verify random nature of drawing setup
  • winning tickets are drawn from urn under public supervision of all players
  • all other tickets are drawn to convince the loosers of the correctness
  • random process cannot be repeated

NOT CONVENIENT
NOT SCALABLE

Recent Lottery History

  • pre-emptive ticket sale at public retail stores
  • few individuals supervise random process &
    majority learns result from public live broadcast
  • online ticket sale requiring authentication
  • live internet show (Youtube) instead of Radio/TV
  • Lotto numbers generated automatically online

Der Aufsichtsbeamte hat sich vor dieser Sendung von dem ordnungsgemäßen Zustand des Ziehungsgerätes und der 49 Kugeln überzeugt.

Für mich macht es keinen Unterschied ob die Ausstrahlung im Internet oder im TV erfolgt.

The public servant convinced himself before this emission of the proper state of the drawing apparatus and the 49 balls.

For me, it does not make a difference if the emission is broadcasted in the internet or on TV.

Encountered Issues

  • correctness not verifiable (trust assumed),
  • no privacy of the player
  • no confidentiality of the number
  • completeness of reward not verifiable
  • not robust (single point of failure)

Promises of Distributed Random Process

  • balance of power (equipotent players)
    • no single point of failure
    • interruption-resistant
  • balance of trust (no lottery officials)

Naive P2P Lottery

  • n players choose number 
  • each player reveals number on Public Bulletin Board
  • players compute sum mod n to find winner

Properties:

  • verifiable, complete
  • not scalable
  • not correct (last player determines winner)
  • not robust (last player may not reveal)

(one winner out of n peers)

Less Naive P2P Lottery

  • n players choose number 
  • each player commits publicly on number,
    e.g. posts hash(number) on Public Bulletin Board
  • only afterwards, all players reveal their numbers
  • players compute sum mod n to find winner

Properties:

  • correct, verifiable, confidential, complete
  • not scalable, not robust (last player may not reveal)

(one winner out of n peers)

P2P Lottery based on Aggregation ADVOKAT

Concepts

Tree Overlay
(Peers = Leafs)

Merkle
Tree

Aggregation Algorithm

ADVOKAT provides Confidential Commitment on
sort of Distributed Public Bulletin Board

Tree Overlay Network

based on the Kademlia DHT

Maymounkov, P., & Mazieres, D. (2002). Kademlia: A peer-to-peer information system based on the xor metric

image/svg+xml

Tree for:

  • finding peers
  • guiding aggregation

Kademlia used in:

peer

Merkle Tree

Aggregation Algorithm

  1. peers connect (with a Tracker) to the DHT with KID
  2. peers update their k-Buckets with peers in sibling subtrees
  3. peers request aggregates (here: hashes) of sibling subtrees
    to compute aggregate (here: hash) of common parent node
x_i
xix_i

P2P Lottery Protocol

  1. Ticket Purchase
    1. Each player generates key pair                    and picks any
    2. Each players acquires signature     on        of Authority
    3. Player joins ADVOKAT aggregation with 
  2. Distributed Random Process
    1. Peers compute jointly Merkle Root        of all  
  3. Winner Identification
    1. Authority learns       by sampling
    2. Winners from list ordered by                     
(pk_i,sk_i)
(pki,ski)(pk_i,sk_i)
t_i
tit_i
pk_i
pkipk_i
x_i = \text{hash}(t_i)
xi=hash(ti)x_i = \text{hash}(t_i)

(version reduced to core concepts)

a_i = \text{hash}(r_i)
ai=hash(ri)a_i = \text{hash}(r_i)
r_i
rir_i
a_R
aRa_R
a_R
aRa_R
x_i \texttt{ XOR } a_R
xi XOR aRx_i \texttt{ XOR } a_R

Protocol Properties

  • correct: no peeking
  • verifiable: players contribute to randomness
  • complete: player number verifiable with aggregation
  • eligibility: signatures and matching total number
  • confidentiality: player number protected by hash
  • privacy: player identities only revealed to authority
  • scalable: message complexity per peer 

Assumption: honest majority of players

\mathcal{O}(\log n)
O(logn)\mathcal{O}(\log n)

Questions?

Contact: http://riemann.cc/about

Slides: http://slides.com/rriemann/p2p-lottery

Backup

Robust Aggregation I

Eligibility:

  • peers create key pair
  • authorization token       (signature on        )
  • KID                           hence determined by peer and authority

Verifiability:

  • Merkle Tree of hashes ensures immutability of descendant hashes
(pk_i,sk_i)
(pki,ski)(pk_i,sk_i)
x_i = \text{sha3}(t_i)
xi=sha3(ti)x_i = \text{sha3}(t_i)
t_i
tit_i
pk_i
pkipk_i

Robust Aggregation II

Correctness and Completeness (probabilistic):

  • signatures on computed hashes express consensus
  • redundantant requests; find majority consens
  • ban of Byzantine peers signing conflicting hashes

Protocol Outlook

Efficiency

  • dynamically adapt №
    of confirmations to
    tree configuration

Dishonest Peers

Colluding

  • analyse limits of
    potential manipulations 

Applications

  • distributed lottery
  • distributed auction

Peer Churn

  • deal with peers arriving late
  • deal with peers leaving early

✓

Made with Slides.com