FanDuel and WagerKings have run into trouble due to insider trading. This same problem has plagued online stock trading with high-frequency traders using information fractions of a second in advance of others to trade ahead. Strobe provides a cryptographically secure method to protect these transactions against insider abuse. Contact me for additional details and full presentation notes.

1. Protecting Fantasy Sports Wagering
and High-Frequency Stock Trading
with Strobe
Protecting transactions against insiders
Design by:
Steven B. Davis
steve@free2secure.com
+1.650.278.7416

2. Problem
• Online fantasy sports wagering is vulnerable to insiders using player
wager information as an “expert system” to make better bets at other
fantasy sports sites
• High-frequency traders can use time differentials to gain knowledge
of orders and trades in advance of other participants to have a
strategic advantage.
• This is a draft concept /proposal and is still under development –
feedback welcome

3. Approach: Strobe – logically simultaneous
transaction system
• Both high-frequency trading and fantasy sports wagering systems rely on a
trusted clearing house for the transactions.
• But, as we’ve seen, what if you can’t trust the insiders?
• Or if a participant can get the information “faster” than others?
• This problem has existed in online games for a long time… it is a real issue
in First Person Shooters (see “lagging” and other network manipulation
attacks).
The Strobe approach – create a series of “secure ticks” that occur “logically
simultaneously” for all parties.
• No trusted clearing house
• No usable time advantage

4. What is a Logically Simultaneous Transaction?
Using paper and pencil:
1. Write down your bet/order/transaction on a piece of paper
2. Flip it over so no one can see it
3. Put it in the middle of the table
4. Wait for everyone else to do the same.
5. No peeking.
6. Once all bets have been made, flip them all over
7. Resolve appropriately
8. Repeat as required
(Details after overall architecture discussion)

5. 3 Sample Strobe
Architectures

6. Architecture 1 –
Simple Strobe Client-
Server Overview
A group of clients and a server are trying to
complete some sort of transaction with
inputs from each participant.
Each determines their respective action.
Computes a hash / transform of that action.
Posts the transform to the server.
Once all transforms have been posted…
Everyone posts their action.
And the results are determined.
Client
Client
Client
Client
1. Action
1. Action
1. Action
1. Action
2. Hash
2. Hash
2. Hash
2. Hash
3. Post
3. Post
3. Post
3. Post
4. Post
4. Post
4. Post
4. Post
S
e
r
v
e
r
5. Results

7. Architecture 1 – Simple Strobe Client-Server
Details
• Clients create Transaction/Wager/Order
• Clients each create their transaction (in no particular
order or relationship to each other)
• Clients each create a hash of their transaction (as
above)
• Clients send their transaction hashes to the central
server (as above)
• The server sends verification that it received the hash
of the transaction to each client, respectively
• Server closes the transaction window
• (Optional) The server sends the transaction hash list to
all of the clients.
• (Optional) The server sends the hash of the transaction
hash list to all of the clients with notification that the
transaction window has closed.
• The server notifies the clients to post their transactions
• Post Transactions
• Each client posts their transaction to the server
• The server stores the transactions
• The server verifies that it has received each transaction
• The server verifies that transactions are valid
• The server handles non-communication of transactions
by clients
• The server resolves the transactions/wagers/orders
• The server sends the resolution to all of the clients
• The server makes the transactions available for review
by all clients and other parties for independent
verification
• Client Verification
• If a client is suspicious, she can download the complete
transaction hash list
• And download the complete transaction list
• And verify each transaction on the list
• Then use those transactions to determine and verify
the net outcome of the transaction set

8. Architecture 2 – Peer Strobe Overview
• A group of clients are trying to complete
some sort of transaction with inputs from
each participant.
• Each determines their respective action.
• Computes a hash / transform of that
action.
• Shares the hash with the others.
• Once all transforms have been posted…
• Everyone posts their action.
• And the results are determined.
Client
1. Action
2. Hash 3. Post
4. Post
5. Results
Client
1. Action
2. Hash3. Post
4. Post
Client
1. Action
2. Hash 3. Post
4. Post
Client
1. Action
2. Hash3. Post
4. Post

9. Architecture 2 – Peer Strobe Details
• Clients create Transaction/Wager/Order
• Clients each create their transaction (in no particular order or
relationship to each other)
• Clients each create a hash of their transaction (as above)
• Clients send their transaction hashes to each other (as above)
• (various options) Each client sends verification that it received
the hash of each other client’s transaction to each other client
• The transaction window is closed
• (Optional) One or more client may send out a claim that the
transaction is ready to move forward
• (Optional) Each client may send a transaction hash list to all of
the other clients.
• (Optional) Each client sends the hash of the transaction hash
list to all of the clients with notification that the transaction
window has closed.
• Depending on the rules, transaction model, business case, and
number of participants, there may be other communications to
move the system forward to the next stage.
• Post Transactions
• Each client posts their transaction to the other clients
• Each client stores the transactions from the other clients
• (Optional) Each client verifies to the sending client that it has
received its respective transaction
• Each client verifies that each transaction by each client is valid
• The clients mutually handle non-communication of transactions
by other clients
• Each client resolves the transactions/wagers/orders
• Each client takes action or does (whatever) based on the
resolution rules.
• Each client has the transactions available for review by all other
clients and other parties for independent verification
• Independent Verification
• If a anyone is suspicious, she can request or be provided the
complete transaction hash list
• And the complete transaction list
• And verify each transaction on the list
• Then use those transactions to determine and verify the net
outcome of the transaction set

10. Architecture 3 –
Escrowed Strobe
Client-Server Overview
A group of clients and a server are trying to
complete some sort of transaction with
inputs from each participant.
Each determines their respective action.
Computes a hash / transform of that action.
Posts the transform to the server.
In parallel, splits their actions and posts the
splits to multiple escrow servers.
Once all transforms have been posted…
The escrow servers post their action split
sets.
The actions are recovered from the splits.
And the results are determined.
Client
Client
Client
1. Action
1. Action
1. Action
2. Hash
2. Hash
2. Hash
3. Post
3. Post
3. Post
S
e
r
v
e
r
8. Results
5.PostActionSplits
5.PostActionSplits
Action
Action Split Action Split Escrow Servers 6. Post Action Splits
4. Split Actions
7. Reconstitute Actions

11. Architecture 3 – Escrowed Strobe Client-
Server Details
• Clients create Transaction/Wager/Order
• Clients each create their transaction (in no particular order or
relationship to each other)
• Clients each create a hash of their transaction (as above)
• Clients send their transaction hashes to the central server (as
above)
• The server sends verification that it received the hash of the
transaction to each client, respectively
• Clients escrow transactions
• Clients “split” their transactions and send the splits to several
escrow servers
• Each escrow server confirms that they’ve received the splits
• Note: the clients do not need to send splits to all of the escrow
servers
• Server closes the transaction window
• (Optional) The server sends the transaction hash list to all of
the clients.
• (Optional) The server sends the hash of the transaction hash list
to all of the clients with notification that the transaction
window has closed.
• The server notifies the escrow agents to post their transactions
• Post Transactions
• Each escrow server posts their transaction splits to the server
• The server stores the transaction splits
• The server verifies that it has received each transaction split
• The server reconstitutes the transactions from the splits
• The server verifies that transactions are valid
• The server handles non-communication of transactions by
clients
• The server resolves the transactions/wagers/orders
• The server sends the resolution to all of the clients
• The server makes the transactions available for review by all
clients and other parties for independent verification
• Client Verification
• If a client is suspicious, she can download the complete
transaction hash list
• And download the complete transaction list
• And verify each transaction on the list
• Then use those transactions to determine and verify the net
outcome of the transaction set

12. Inside a logically
simultaneous transaction
Background of the cryptography from SecurePlay

13. Guessing Games - 3-Card Monte
• Guessing Game (Find the
Queen)
• Games using similar principles
include Stratego™ and
Battleship™ and card games
like “Go Fish”
• Typically Turn-based games
• Guessing location or value of
hidden assets
• SecurePlay Integration
• Secret Transaction for Hidden,
Non-Repudiable* Actions or
Choices
• Other Transactions may be
used to complete the game* Cannot be later refuted by the transaction participants

14. Alleged Alleged
Secret Transaction 1
• At its core, this is a two-step
transaction.
• A Secret is identified
• The “Hidden Secret” is sent to the
other participants using Irreversible
Transforms
• Random data is appended to
prevent Dictionary Attacks
• At the appropriate time, the Hidden
Secret and appended Random data
is revealed and Verified
• For 3-Card Monte:
• (Secret) Set Queen Location
• (Secret) Send Transform of Secret
• (Multi-Part) Bet on Queen Location
• (Secret) Reveal Secret
• (Multi-Part) Resolve Bet
Secret
Secret
Secret
Random
Random
Hash Function
Hash Function
Transform
Store
Transform
Send
Send
Transform
Validate
Receivers
Sender
Alleged

15. Verification –
Instant vs. Deferred
• Verification can be inherent in the completion of transaction or
deferred until a later time.
• Verification can also be deferred from a game rules perspective.
• As long as every transaction and rule can eventually be verified, the
game is fair.
• Certain transactions and rules can allow intermediate verification in
case of player complaint, though not always – again this depends on
the nature of the specific game.

16. Rock-Paper-Scissors
• Simplest example of a
simultaneous game
• Cheating is a “timing” attack
by waiting to see what the
other player will do
• SecurePlay Integration
• Direct use of Simultaneous
Transaction

17. Simultaneous Transaction 1
• The Simultaneous Transaction
essentially is the Secret Transaction
with multiple parties involved.
• Each party sends the Transform of
their contribution, just as with
the Secret Transaction.
• After each party receives all of
the other participants
contributions, they reveal their
contribution
• Random Numbers are created by
the contribution consisting of an
arbitrary random number chosen
by each Participant (for
Backgammon, 2 random numbers
between 1 and 6)
• The Results are then added
together and reduced to a value
between 1 and 6
Secret 2 Random 2
Hash Function
Transform 2
Secret 1 Random 1
Hash Function
Transform 1
Transform 2 Transform 1
Secret 2 Random 2 Secret 1 Random 1
Secret 1 Secret 2
1. Exchange
2. Reveal
Player 1 Player 2
Result Result
3. Combine
3. Combine

18. Simultaneous Transaction 2 • Transaction
process is the
same as
previously
described
• Resolution is
handled purely in
Game Rules code
Secret 2 Random 2
Hash Function
Transform 2
Secret 1 Random 1
Hash Function
Transform 1
Transform 2 Transform 1
Secret 2 Random 2 Secret 1 Random 1
1. Exchange
2. Reveal
Player 1 Player 2
3. Resolve
Players
<Simultaneous> make choices
<Simultaneous> send choice transforms
<Simultaneous> reveal choices
<Simultaneous> verify choices
Rules – resolve Choices
Where <> denotes the SecurePlay protocol to use

19. Strobe Transaction 1
• Strobe is a sequence of
Simultaneous Transactions
• Strobe automatically
moves from one
Simultaneous Transaction
to the next
• Reading data out of the
previous transaction
• Writing data to the current
transaction
Exchange
Reveal
Exchange
Reveal
Exchange
Reveal
Exchange
Reveal
Read
Read
Read
Read
Time

20. Fighting Game
• Basic “Real-Time”
Game
• Attack/Defend/React
• Most games with
“Tactics” use this basic
model
• SecurePlay Integration
• Use of Strobe
Transaction for
Interaction
• Use of Rules to Provide
“Real-Time”ness
• Randomization
Embedded in Strobe
• Like Dice in
Backgammon
Player 1
<Simultaneous> Tactic 1
<Simultaneous> send transform
<Simultaneous> reveal Tactic
<Simultaneous> verify Tactic 2
Player 2
<Simultaneous> Tactic 2
<Simultaneous> send transform
<Simultaneous> reveal Tactic
<Simultaneous> verify Tactic 1
Resolve
Where <> denotes the SecurePlay protocol to use

21. Strobe Transaction 2
• Strobe can be used to chain
together a sequence of
actions over time.
• Time does not have to be
uniform and can be Event-
Driven or Interval Driven
• Payloads of Strobe
Transactions can contain any
sort of information, Actions,
Results, and State updates
as well as ancillary data such
as random event generators
Exchange
Reveal
Exchange
Reveal
Exchange
Reveal
Exchange
Reveal
Read
Read
Read
Read
Time

22. Event-based Time vs.
Interval Time
• Strobe simply sequences
events in time,it does not
force events to be uniform
• A key concept, whether
Strobe is used or not, is some
notion of minimal time and
non-interference
• The minimal time interval
between actions by a Player
• Choices that occur during a
minimal time interval should
not “break” each other.
• These intervals are driven by
game rules and network lag
Exchange
Reveal
Exchange
Reveal
Exchange
Reveal
Exchange
Reveal
Time Exchange
Reveal
Exchange
Reveal
Exchange
Reveal
Exchange
Reveal
Exchange
Reveal
Exchange
Reveal
Exchange
Reveal

23. Rally Cars
• Racing Games use simplified
interfaces to simulate car racing.
• Similar mechanisms are used for
Sports games and Action Games
where continuous time and action
are perceived
• SecurePlay Integration
• Use Strobe Transaction to Post
Actions or State Updates
• Use Multi-Step or Blast
Transactions as an alternative
• Physics Engine Provides
Continuity

24. Physics is just another Set of Rules
• Physics Engines can be event driven or interval driven
for game play
• Engine “runs” between Player Actions
• No different than the table lookup done for fighting game or Rock-
Paper-Scissors
• Always have synchronization issue over a network
• Always have a display issue over a network
Steer Left 20o Steer Right 5o Steer Right 8o
Accelerate 48% Brakes 5% Brakes 55%Accelerate 88%
Time = 18
Time = 23
Time = 41
Time = 30 Time = 48
Time = 43
Time = 65

25. Next steps
• Does this make sense (any questions)?
• Does this address an interesting problem?
• Are there other applications?
• Are there system constraints that may invalidate or limit the
effectiveness of this approach?

26. Who am I?
• Steven Davis
• Worked in high-end security design and analysis since 1987
• Current focus on “business security” – linking business and security together beyond IT
• History:
• Design and analyze custom cryptography and security architectures
• … and lots of other security work
• Several security patents:
• Anti-cheating cryptography for games
• “Manual” digital signature to improve credit card security
• Book “Protecting Games”
• Numerous papers and conferences
• Blog: free2secure.com
• Defunct blog: playnoevil.com – 2006 to 2012
• https://www.linkedin.com/in/free2secure
• steve@free2secure.com
• +1.650.278.7416