Bitcoin Poker Protocol Revisits Early Code Without a Network Upgrade

Bitcoin (BTC) poker protocol revisits an early Bitcoin source-code concept by using private card generation and presigned transactions to support two-player Texas Hold’em without a network upgrade.

Robin Linus, a Stanford Ph.D. candidate focused on Bitcoin scalability, privacy and usability, designed the system for heads-up limit poker. Each player receives two private cards, while five community cards are shared. The design uses adaptor signatures, joint encryption, zero-knowledge-style proofs and prepared transaction paths to represent legal moves and enforce payouts.

The intended gameplay occurs off-chain. Players exchange witnesses privately during a cooperative hand, while a prepared transaction tree provides a fallback if one player stops cooperating. Bitcoin’s blockchain is used mainly for dispute resolution rather than for every move.

The system does not shuffle a complete 52-card deck. It generates nine distinct cards: four private cards and five community cards. Duplicate deals are rejected privately. A randomly generated nine-card deal contains no duplicates about 48.025% of the time, requiring an expected 2.08223 attempts.

The design supports only two players because multiple opponents could collude by sharing information about their cards. Its reference configuration uses 100 big blinds per player and four bets per street. The resulting game tree contains 56,132 logical nodes and can extend to 33 gameplay transitions, including 54,855 ordinary signatures and 1,306 reveal packages with 52 adaptor signatures each.

The reference preparation snapshot is 8,416,186 bytes. Three four-worker desktop-browser trials prepared and saved the tree in 26.39 to 27.26 seconds, excluding relay latency and funding confirmation.

Timeout transactions use relative block delays measured from confirmation of the relevant Bitcoin output, rather than a local clock or relay message. “The protocol can force settlement, but it cannot force someone to reveal a card,” Linus said.

Privacy depends on how the hand ends. Cooperative play keeps cards and transaction witnesses off-chain. A public showdown reveals both hands, while an on-chain dispute reveals the played path. Failed dealing attempts can also expose relationships between cards involved in a collision.

The design uses Bitcoin’s existing transaction, Taproot, signature and timelock mechanisms. It is conceptually related to Linus’ earlier BitVM work, which listed poker as a possible application but did not constitute this protocol.

Bitcoin’s early source code included interface classes and controls for dealing, folding, calling and raising. “These interface fragments were not a complete poker protocol,” Linus said.

The security construction requires independent review and does not provide a formal proof of the complete malicious-party protocol. “Test coverage is not a security proof,” Linus said.