Shuffling the Deck Without a Dealer
Forty-five years of mental-poker cryptography finally lands on Bitcoin — and it had to wait for the UTXO
In 1979, Adi Shamir, Ron Rivest, and Leonard Adleman — the same three who had given the world RSA two years earlier — published a short paper on how two parties could play a game of poker over the telephone without trusting each other. They called the problem mental poker, which is a better name than it has any right to be: every player keeps the state of the game in mind, and the cards themselves are held in a shared cryptographic object that nobody in particular owns. The paper is three pages long. It is mostly about commutative encryption. It is, by any honest accounting, the first serious attempt at trustless multi-party computation in the modern cryptographic literature.
It also did not work.
Goldwasser and Micali, in 1984, pointed out that commutative encryption based on quadratic residuosity leaks the residuosity class of the plaintext. This is not a small leak. For a standard French deck, it distinguishes red suits from black suits without any decryption at all, because thirteen cards in each suit share a residuosity class. The “mental” part of mental poker turned out to be rather more visible than anticipated. This is what cryptographers mean when they say a scheme has partial information leakage: the adversary cannot decrypt the cards, but the adversary can tell something about them, and in a game where knowing black-from-red reverses the outcome, partial leakage is total defeat.
Crépeau fixed this in 1986 and 1987. Barnett and Smart consolidated the line in 2003. ElGamal encryption replaced commutative encryption; zero-knowledge proofs of correct shuffling replaced the bare exchange; security reduced to the Decisional Diffie-Hellman assumption on a suitable elliptic curve. This is where the mental-poker literature sat for the next two decades. Wei (2012), Castellà-Roca (2006), David and his collaborators (2017, 2018) added refinements, improved computational efficiency, and coupled the protocol to on-chain payment rails. The cryptography was, by 2018, substantially solved at the protocol layer.
What was not solved — and what nobody in the cryptographic literature has been especially keen to dwell on — is that a zero-knowledge cryptographic protocol produces a card whose face value must eventually be rendered on somebody’s screen. And a screen, unlike a mathematical abstraction, is a pile of pixels sitting in a shared display buffer accessible to every process on the device with the right permission. A perfect protocol over a compromised display is equivalent, in its attack surface, to a broadcast of the card face. This is not a minor operational footnote. It is the whole problem, once you have decided that the cryptography works.
The second thing that was not solved — and I say this with some feeling — is that every serious mental-poker paper since 2003 has implicitly assumed that the reveal mechanism operates over trusted channels between parties whose identity is somehow pre-established. Real-money card games are not played that way. Real-money card games are played by strangers who met on an app yesterday, across unreliable mobile networks, with devices running operating systems owned by vendors who do not particularly care about the game, under legal regimes that vary by jurisdiction. The classical literature gestures at this and moves on. Until you have built the thing, you do not appreciate how much of the work is in the gesturing and moving on.
What the present paper does
A short summary, because everything that follows is the long version.
The paper composes three things. The first is a multi-party elliptic-curve set-shuffling protocol due to Burns and Wright (UK patent GB 2616862 B, granted 2025-08-27), which replaces the ElGamal re-encryption of the Barnett-Smart line with a direct operation on shuffle-key points. The second is a BSV-resident Bitcoin Script covenant-chained UTXO state machine that carries the per-card lifecycle — minted, drawn, revealed, discarded — on Bitcoin SV Layer 1. The third is a device-rooted key custody stack using consumer Trusted Execution Environments (Apple Secure Enclave, ARM TrustZone, Intel SGX) together with operating-system-level screen-capture prevention on Android and iOS. The composition produces what the paper calls an encrypted NFT: a token held as a single BSV UTXO whose face value is computationally inaccessible to any coalition of fewer than N parties, and whose transfer is enacted by a threshold ECDSA spend of the combined-public-key UTXO.
That is the thing. What follows is why it matters, how it actually works, what it does not do, and what the honest limitations are — because if you cannot enumerate the limitations, you have not specified the system.
The first thing Bitcoin gives you that no other chain does
It is worth being direct about this. Bitcoin — the design in the 2008 paper, maintained on BSV — is a UTXO system, not an account system. The difference matters more than almost anyone who writes about this subject seems to think.
In an account system, selection is a lookup: you identify the asset by its address in a global state table, and the act of using it is mechanically the act of changing a row in a database. In a UTXO system, selection is a spend: you identify the asset by the unspent output it lives in, and the act of using it is mechanically the act of consuming that output and producing one or more new outputs. The UTXO ceases to exist when spent. There is no database row to look up because there is no database in the relevant sense — there is a set of outputs, each of which either exists or has been consumed.
This matters for card games because a card is, semantically, a thing that gets dealt once and then belongs to whoever it was dealt to. A card is not an account. A card is not a ledger entry. A card is a one-shot object: it exists in the deck, it gets drawn, it gets revealed, it is discarded, and it does not come back. The BSV UTXO model is the cleanest expression in any deployed system of exactly that life-cycle. Each card is a UTXO. Drawing the card is spending the UTXO. The state machine — minted, drawn, revealed, discarded — is a covenant chain in which each state transition is a spend that produces the successor-state UTXO. The single-use property of each draw follows, without any additional machinery, from the basic consensus invariant that a UTXO can be spent at most once.
Account-model chains can simulate this. They simulate it badly, at considerable cost, because they must introduce replay-protection machinery, burn flags, state-dependent guard clauses, and so on, for an object that is naturally one-shot and whose one-shot-ness is already available for free at the consensus layer of a UTXO system. If you have ever wondered why every generation of NFT standard on account-model chains has had re-entrancy problems, mint-twice problems, phantom-ownership problems, and a long list of attack classes with silly names, this is largely why: the substrate is wrong for the object. A card is not an entry in an ERC-721 mapping. A card is a spent or unspent output.
The set-shuffling protocol, in detail
Let G denote the generator of secp256k1 and n its (prime) order. The deck consists of D data items — typically D = 52 for a standard French deck, but the protocol is deck-size-agnostic. N players participate, indexed 1 through N.
Each player p generates an ordered set of per-card private keys (v_{p,1}, ..., v_{p,D}) with each v_{p,j} uniform on ℤ*n, together with the corresponding per-card public keys P{p,j} = v_{p,j}·G on secp256k1. Each v_{p,j} stays inside the player’s device TEE for the duration of the game. The derivation is deterministic from a TEE-resident long-term ECDH private key sk_p via HKDF with the game identifier and card index as the context string; the player’s device therefore holds only one long-term key, not fifty-two, and the mapping from the long-term key to the per-card scalars is auditable given the inputs.
For each card j, the combined public key is the pointwise elliptic-curve sum across all players:
Q_j = P_{1,j} + P_{2,j} + ... + P_{N,j}
The combined private key is the scalar sum modulo n:
w_j = (v_{1,j} + v_{2,j} + ... + v_{N,j}) mod n
The arithmetic fact is trivial: because EC point addition is a group operation and the discrete-log map is a group homomorphism from ℤ_n to the curve, the sum-of-points equals the point-of-sum. The cryptographic fact is not trivial: no single player knows w_j, because w_j depends on the scalars of every other player, and those scalars are held inside the other players’ TEEs. No single player knows any other player’s v_{p,j}. No player ever reconstructs w_j in memory, even when the card is eventually spent, because the spending signature is produced by the threshold-ECDSA protocol of Savanah and Wright (published as WO 2019/034951 A1) without any participant ever holding the combined private key.
Q_j locks a single BSV UTXO on Layer 1, under a standard P2PK-style locking script. Selecting card j is mechanically spending that UTXO. Doing so requires a signature that verifies under Q_j at OP_CHECKSIG, which in turn requires the cooperation of all N players (or whatever threshold the deployment chooses — the protocol generalises to k-of-N using Pedersen-style verifiable secret sharing, at the cost that any k players can coalition to learn any card).
Now the shuffle itself. The deck after stage 0 is the initial state S_0 — a mapping from card-index j to the tuple of per-party public keys (P_{1,j}, ..., P_{N,j}) and the combined Q_j. Each player, in turn, applies their shuffle to the deck. Player p‘s shuffle has two operations. First, player p samples a fresh scalar α_p uniform on ℤ*n and applies it to every inner element of the state: each P{q,j} becomes α_p·P_{q,j}. Second, player p samples a permutation π_p uniform on the symmetric group S_D and reorders the deck positions according to π_p. The scalar multiplication re-randomises the public keys; the permutation re-orders them. The composition of these two operations, applied in sequence by all N players, produces a state S_N in which every card has been re-randomised N times and permuted N times.
Indistinguishability follows from the Decisional Diffie-Hellman assumption on secp256k1. The argument: given the on-chain commitments {P_{p,j}} and the re-randomised point α_p·P_{p,j}, any distinguisher that tells the real shuffled position from a uniform random position yields a DDH distinguisher (P, αP, β, γ) → bit. Apply the hybrid argument across the D·N inner elements; the total distinguishing advantage is at most D·N times the per-step DDH advantage, which is negligible under DDH on secp256k1. The paper gives the full reduction with explicit simulator construction, because you cannot call yourself a cryptographic paper if your security proofs are sketches.
Commitment on-chain is what binds the off-chain shuffle to BSV. At each stage, player p publishes a SHA-256 commitment c_p = H(S_p || α_p || π_p) to the state transition, recorded as an OP_RETURN or data-push in a BSV transaction. The actual values of α_p and π_p remain secret until the game closes. The commitment achieves computational hiding under the random-oracle model of SHA-256 and binding under collision-resistance. If player p tries to cheat — emits a commitment that is inconsistent with the state they actually produced — the cheating is detectable at close-out when α_p and π_p are revealed, and the aborting player’s collateral is forfeit. There is no way to bias the shuffle after the commitment is posted on BSV; the block confirms, the commitment is immutable, and the player is bound.
The encrypted NFT
Here is where the construction earns its name.
An encrypted NFT for card j is the tuple (Q_j, P_{1,j}, ..., P_{N,j}, E_j, c_j), where:-
Q_j is the combined public key, locking the BSV UTXO on Layer 1;
-
each P_{p,j} is the per-party public key, published at stage 0 as a commitment to v_{p,j};
-
E_j is an authenticated-encryption ciphertext of the card’s face value, encrypted under the symmetric key K(w_j) = HKDF-SHA256(w_j·G), where w_j·G is the public form of the combined private key;
-
c_j is a SHA-256 commitment binding the issuer to the face-value assignment at mint time.
The key property: the face value of the card is computationally inaccessible to any coalition of fewer than N parties, because the AEAD key K(w_j) is a function of w_j·G, which is a function of w_j, which nobody holds. Under DDH on secp256k1, w_j·G is indistinguishable from a uniform random curve point for any party lacking the scalar w_j, and therefore K(w_j) is indistinguishable from a uniform AEAD key, and therefore E_j is indistinguishable from a ciphertext of a random plaintext. The card’s face value is, for all practical purposes, sealed.
The reveal only becomes possible when the threshold of players cooperates to produce a signature under Q_j. At that moment, and only at that moment, the spending transaction is confirmed on BSV, the UTXO is consumed, and the mechanism by which the face value becomes derivable kicks in.
The applications of this primitive go well beyond card games. A sealed-bid auction becomes a set of encrypted NFTs, each bid a card, all revealed simultaneously at auction close. A random licence assignment becomes a deck of licences, drawn at random without any party learning which licence is theirs until draw time. An encrypted collectible with an unlockable trait becomes a token whose rare trait is itself encrypted, decryptable only by a cooperating committee. A commitment-based reputation system becomes a set of sealed claims that can be revealed at dispute time under cryptographically-enforceable conditions. None of this is available, in any clean form, on account-model chains; all of it composes naturally with the BSV UTXO.
The reveal — where most mental-poker papers wave their hands
Here is where the literature has been quietly failing for forty-five years, and where the present paper actually does the work.
The naïve reveal — player p sends player r the value v_{p,j} so that r can contribute to decrypting card j — has three separate problems. First, v_{p,j} is a reusable secret: once r has it, r can use it to decrypt other cards that share that same v_{p,j} (which is why v_{p,j} is per-card and not per-game, but the principle generalises). Second, v_{p,j} is a long-term key in the sense that it is bound to player p‘s identity and game session; leaking it leaks p‘s game-specific key material. Third, there is no built-in binding between the act of revealing and the specific card, position, block height, and recipient; a revealed v_{p,j} can be replayed across contexts that the protocol did not intend.
The paper fixes all three problems at once with a single-use ECDH reveal-token mechanism bound to the context tuple (gid, j, ℓ, h_ℓ, E_r), where gid is the game identifier, j is the card index, ℓ is the draw position, h_ℓ is the block height at which the draw was made, and E_r is the recipient’s fresh ephemeral public key. The recipient generates a one-shot ECDH keypair (e_r, E_r = e_r·G) at draw time. The player p who is revealing to r computes:
Z_{p,j,r} = v_{p,j} · E_r = v_{p,j} · e_r · G
and derives the reveal token:
τ_{p,j,ℓ,h_ℓ,r} = HKDF-Expand(Z_{p,j,r}, (gid, j, ℓ, h_ℓ, E_r), L)
The recipient, knowing e_r and the public P_{p,j} committed at stage 0, can recompute Z by the symmetric operation Z = e_r·P_{p,j} = e_r·v_{p,j}·G, and therefore can recompute τ and verify it matches what p sent. A party that does not hold v_{p,j} cannot compute Z without solving Computational Diffie-Hellman on secp256k1, which is at least as hard as DDH.
The critical properties: τ is derived from a one-shot ephemeral key E_r, so it is valid exactly once; it is bound to (gid, j, ℓ, h_ℓ, E_r), so replay across cards, positions, block heights, or recipients is cryptographically prevented; and the long-term secret v_{p,j} is never disclosed in the clear — only the hash output τ is, and τ reveals nothing about v_{p,j} under the HKDF-SHA256 extractor properties of Krawczyk (CRYPTO 2010). The reveal is, in the cryptographic sense, secure.
The threshold signing — no single party ever holds the combined private key
When the card is finally spent on BSV, the spending transaction needs a signature under Q_j that verifies at OP_CHECKSIG. Naïvely, one of the players would assemble w_j = Σ_p v_{p,j} and sign with it. This would be a catastrophic design error, because any player who ever holds w_j even momentarily has learned every other player’s scalar and can compute the combined private keys for every other card in the deck, retroactively.
The protocol uses the threshold-ECDSA construction of Savanah and Wright. The critical invariant is that w_j is never assembled in any participant’s memory. Each v_{p,j} is represented as a Shamir secret share on a polynomial of degree k−1 with constant term w_j, via joint random secret sharing (JRSS). The ephemeral signing nonce D_k is also generated jointly via JRSS, without any party holding D_k. Partial signatures are computed by each participant against their share; these are combined via Berlekamp-Welch decoding over a threshold of partial signatures, yielding the standard ECDSA s component s = D_k^{-1}(H(m) + r·w_j) mod n — without anyone ever computing D_k or w_j.
The output is a single (r, s) pair that is binary-indistinguishable from a single-party ECDSA signature and verifies under Q_j at the standard OP_CHECKSIG opcode. The BSV miners see an ordinary signature on an ordinary transaction; no protocol change is required; no new opcode; no multi-signature script. The threshold structure is entirely off-chain.
Berlekamp-Welch decoding also provides error-correction for malicious partial signatures up to the bound ⌊(partials − k)/2⌋. A participant who emits a corrupted partial is identified post-hoc by the discrepancy between their emitted partial and the value Berlekamp-Welch would have expected at their canonical index; slashing follows. The aggregate signature is either correct (and verifies) or wrong (and fails at OP_CHECKSIG); no signature on a spoofed message is ever produced.
The screen-capture problem nobody wanted to talk about
Now the visual layer, which is where the mental-poker literature has been hiding for four and a half decades.
After the cryptographic reveal, the face value of the card exists as plaintext inside the player’s device. To be useful, it must be rendered on the display. The display buffer is a shared resource on every consumer operating system: screenshot utilities, screen-recording applications, accessibility services, remote-support tools, screen-casting frameworks — all of these have access to the pixels being rendered, by design, because they provide user-facing features that require it.
On Android, the defence is FLAG_SECURE, a window-level flag that tells the system compositor to blank the window during screenshot or screen-recording operations. It has existed since Android 3.0. Its enforcement is at the composition level: when FLAG_SECURE is set on an activity’s window, the system compositor produces a black frame in screenshots rather than the window’s actual pixels. This blocks the MediaProjection API (which underlies most screen-recording apps), the standard screenshot path, and the accessibility-service screen-capture path. It does not block the compromised-OS case — an attacker with root can bypass anything — and it does not block someone pointing a second camera at the screen, because no software can.
Android 14 adds a post-hoc detection mechanism via the ScreenCaptureCallback, which fires when a screenshot is taken. This does not prevent the capture but allows the application to respond — pause the game, invalidate the reveal, notify other participants — when a capture occurs. On iOS, the corresponding primitive is UIScreen.isCaptured, which the application polls; detection is pre-emptive in the sense that the app can delay rendering the card face until it confirms the display is not being mirrored or recorded.
None of this is bulletproof. The honest admission in the paper is that physical photography of the screen — pointing a second phone at the first — is not defeated by any software mechanism. What these protections do is raise the attack cost from “run the built-in screenshot utility” to “procure a second device, frame the shot, align the photograph.” This is a meaningful increase in operational friction for the casual cheater and a complete non-defence against a determined adversary. The protocol is honest about this. The protocol does not claim to be video-capture-proof, because it is not.
The architectural point is that the visual layer is now a first-class component of the design, with explicit threat modelling and OS-level mitigations, rather than a footnote. Every mental-poker paper prior to this one has treated the visual layer as out of scope. That is no longer an acceptable answer for a practical deployment.
Device-rooted trust: where the keys actually live
The per-card private scalars v_{p,j} cannot sit in application memory. Application memory is a shared resource; any compromise of the rich OS — malicious app, overlay attack, debugger attachment, root exploit — exposes the scalars. The industrial-strength answer is to put the secrets in a hardware Trusted Execution Environment that is architecturally isolated from the rich OS.
Three commercial TEEs dominate consumer deployments. Apple’s Secure Enclave is a dedicated secure coprocessor present in every iPhone since the 5s and every Mac with Apple silicon. It holds keys, performs cryptographic operations, and never exposes the keys themselves to the Application Processor; the Application Processor can request signatures, HMACs, or key-derivation outputs, but cannot read the underlying scalars. Apple’s SecKey API provides the application interface.
ARM’s TrustZone splits every ARMv7-A, ARMv8-A, and ARMv9-A processor into two worlds: the Normal World, which runs the ordinary OS (Android, Linux, etc.), and the Secure World, which runs a smaller Trusted Execution Environment OS. The application in the Normal World requests cryptographic operations via a Secure Monitor Call that traps into the Secure World; the Secure World does the crypto with keys that never leave its memory domain. Android Keystore with StrongBox backing provides the developer-facing API on supported Android devices.
Intel’s SGX provides process-level enclaves on supported server and (previously) consumer hardware. It has had a more chequered history: Intel deprecated SGX on consumer processors after a series of well-publicised side-channel attacks (Foreshadow, CacheOut, ZombieLoad, RIDL). It remains available on Xeon for enterprise deployments and has published literature on remote attestation for auditing purposes.
There is a gap the paper confronts honestly. Apple’s SecKey API on iOS natively supports NIST P-256, not secp256k1. A pure Secure Enclave deployment on iOS requires either a secondary-curve key hierarchy (use P-256 in the Enclave, derive secp256k1 scalars from P-256 outputs via a separate KDF) or software-only secp256k1 custody outside the Enclave (which loses the hardware-rooted property). On Android, secp256k1 in TEE-backed Keystore is available on some devices and not others, so deployment must either detect and restrict device models or fall back to software custody with reduced assurance. These are real operational constraints, not talking points. The paper specifies three deployment tiers with explicit assumptions at each tier so that operators know what they are getting.
The Foreshadow family of attacks, and its successors, deserves explicit mention. No consumer TEE is invulnerable. Each has had vulnerabilities disclosed; each has had mitigations deployed; each will have further vulnerabilities disclosed in the future. The paper’s treatment is to require tracking of CVE advisories from Apple, ARM, and Intel, enforce minimum silicon-stepping and firmware-version requirements for participating devices, refresh per-game participant keys via ECDH+HKDF so that long-lived compromise is bounded to specific games, and use proactive share refresh between games to further bound blast radius. None of this makes TEEs invulnerable. It makes compromise expensive, local in scope, and recoverable.
Why BSV makes this economically viable
Here is where the economics matters, because cryptography that cannot be deployed is cryptography that does not exist in practice.
A complete 4-player 52-card Texas Hold’em-style hand, under the byte-cost accounting derived in the paper from transaction-byte analysis at BSV’s 0.5 sat/byte reference fee rate, settles on BSV Layer 1 for approximately 4,062 satoshis — roughly 0.12 US cents at BSV of USD 30 per coin. The per-game bytes are approximately 8,124: setup of the deck (2,200 bytes for 52 cards and 4 players), four shuffle-stage commitments (256 bytes), thirteen draw operations (2,080 bytes), thirteen reveal operations (2,340 bytes), thirty-nine expire operations for unused cards (1,248 bytes). These numbers are engineering estimates, not measured benchmarks, and the paper is honest about that distinction.
Published per-game costs for comparable workflows on Ethereum Layer 1 at typical gas prices and on representative Ethereum Layer 2s fall in the USD 0.50 to USD 50 range. This is not because Ethereum is badly engineered — it is because Ethereum’s gas-pricing model charges for computation and state writes independently of transaction bytes, and it runs a congestion-driven fee market that spikes when demand rises. BSV’s byte-fee pricing charges for data-on-chain at a stable rate, and BSV’s post-Genesis unbounded block-size removes the structural block-space scarcity that creates the fee-spiking dynamic. A card-game deployment on BSV has predictable costs. A card-game deployment on Ethereum has costs that vary over time by factors of 10 or more, with the operator carrying the variance.
This is not a speculative point about which chain is “better.” It is a direct technical consequence of the two chains’ fee-market structures. BSV’s fee market is structurally non-congestive. Ethereum’s fee market is structurally congestive. For a deployment that needs predictable per-game economics — which every commercial gaming operator does — the difference is dispositive.
The limitations, stated plainly
A paper that does not state its limitations has not specified its system. Here are the limitations of this one, in the order they matter.
The cost figures are engineering estimates, not measured benchmarks. Every satoshi figure in the paper is derived from transaction-byte accounting against the BSV reference fee schedule. A deployed instance on BSV mainnet will produce measured figures that differ — probably by single-digit percentage points, possibly more for edge cases like network-wide fee-rate excursions. The figures are good enough to decide whether to build the thing. They are not good enough to use in a regulatory filing.
The cryptographic security depends on the DDH assumption on secp256k1. This is a well-studied assumption that has held up for two and a half decades. It is not a proof. A future advance in discrete-log algorithms on secp256k1 would break the scheme, as it would break every other ECC-based protocol on every deployed chain. The protocol is in good company here, which is cold comfort if the cryptography breaks, but is the honest position.
The device-layer security depends on the vendor-supplied guarantees of Apple, ARM, and Intel at the deployment tier actually used. A TEE compromise — a Foreshadow-class attack, a firmware bug, a side-channel that survives mitigation — exposes the secrets held by that TEE. Per-game key refresh bounds the exposure to specific games. Proactive share refresh further bounds it. Neither eliminates it. Operators of high-value deployments should assume that TEE compromise is a tail event they must plan for, not a contingency they can ignore.
The UI-layer protection is partial. FLAG_SECURE defeats casual screenshot attacks on approximately 70% of Android devices pre-Android 12 and near-universally on Android 12 and later. It does not defeat physical photography of the screen. It does not defeat a compromised OS. What it defeats is the casual attacker — the overwhelming majority of real-world attackers, but not the entire population. Operators of tournament-grade deployments should pair the software protections with supervised-play protocols in physical settings where it matters.
The protocol is patent-licensed. The Burns-Wright set-shuffling primitive is covered by GB 2616862 B, which is held by nChain Licensing AG. The threshold-signing primitive is covered by WO 2019/034951 A1. Anyone deploying the system commercially requires a licence. This is stated explicitly in the paper’s Limitations section and is a material consideration for anyone evaluating the construction as a commercial building block.
The protocol is not a voting system. Voting requires coercion-resistance, universal verifiability, and receipt-freeness — properties that the present encrypted-NFT primitive does not provide. A voter whose shuffle-key share is observed under coercion has disclosed their vote. Do not deploy this as a voting protocol without adding the additional machinery (blind signatures, mixnets, homomorphic tallying) standard in the electronic-voting literature.
The protocol is not “trustless” in the broader sense. It is non-custodial at reveal, in that no single dealer exists and no individual party can unilaterally produce any card’s face value before the threshold cooperates. This is a specific cryptographic property, not a general claim that no trust is required anywhere. Participants must trust their own device’s TEE vendor. They must trust the BSV consensus layer (which is to say, they must trust that a majority of BSV hashpower is honest). They must trust the off-chain signalling layer to deliver messages. These are real trust assumptions, explicitly stated.
Why this matters
The headline claim I would make is this. For the first time in the history of this literature, there is a mental-poker construction that is cryptographically sound, economically feasible, device-rooted against practical adversaries, and UI-layer protected. That is, it is a construction you can actually deploy rather than a construction you can publish a paper about.
The reason it took forty-five years is that four separate prerequisites had to converge. The cryptographic prerequisite was the elliptic-curve set-shuffle, which replaces ElGamal re-encryption with combined-public-key UTXO locks — this is Burns and Wright (2022, granted 2025). The blockchain prerequisite was a UTXO chain with cheap, predictable, unbounded-block-size transaction pricing — this is BSV post-Genesis. The device-security prerequisite was consumer hardware TEEs shipping at scale — this is Apple Secure Enclave since 2013, ARM TrustZone since the mid-2000s, Intel SGX since 2015 (though deprecated on consumer silicon). The UI-security prerequisite was OS-level screen-capture primitives — this is FLAG_SECURE since Android 3.0 (2011), UIScreen.isCaptured on iOS (iOS 11, 2017), and ScreenCaptureCallback on Android 14 (2023).
No chain other than BSV has the right fee-market structure. No cryptographic primitive other than combined-public-key UTXO selection gives you single-use at the consensus layer without additional machinery. No device-security architecture other than hardware TEEs gives you practical key-custody against a rich-OS attacker. No UI-security layer other than OS-integrated screen-capture prevention gives you defence-in-depth against the visual exfiltration vector.
The system sits at the intersection of these four prerequisites. It is what you get when each of them has matured independently, for reasons unrelated to this specific use case, and someone finally composes them with the right engineering discipline. The specific contribution of the paper is not that any of the primitives is novel — every one of them has a prior-art citation in the references — but that the composition is correct, the edge cases are handled, the limitations are stated honestly, and the whole system is specified at a level where an engineering team can implement it.
The broader point — and this is where I will stop being polite — is that the crypto industry has spent fifteen years producing account-model chains that simulate, badly, the one-shot object semantics that BSV gives you for free at the consensus layer. NFT standards on account-model chains are a pile of workarounds for a substrate that was never designed to host one-shot objects. Mental-poker deployments on account-model chains require complex contract machinery to enforce single-use of each card, and they pay for that machinery in per-game costs that are one to two orders of magnitude higher than what the BSV byte-cost accounting produces.
This is not a close call. The UTXO model is the right substrate for one-shot objects. Cards are one-shot objects. Mental poker is, at its core, a protocol over one-shot objects. That the literature took forty-five years to arrive at this construction is an indictment of the industry’s substrate choices, not of the literature’s intelligence. The cryptographic talent has been there. The substrate has not been there. Now it is.
What needs to happen next is deployment, measurement, and hardening. The paper’s engineering estimates need to be replaced with measured benchmarks from a running BSV deployment. The TEE-compromise recovery paths need to be exercised against real CVE disclosures. The UI-layer protections need to be audited against updated threat models as new Android and iOS versions ship. The threshold-signing implementation needs side-channel hardening against the attacks that will, inevitably, be published against it in the coming years.
None of this is a reason not to deploy now. All of it is a reason to deploy now, carefully, with the operational-security posture the paper spells out, and with an honest accounting of what the system does and does not do. The alternative — waiting for a perfect construction — is the alternative that has produced forty-five years of papers and zero deployments. At some point you have to build the thing. The cryptography is in the 1979 Shamir-Rivest-Adleman paper. The substrate is in the 2008 Bitcoin paper. The TEE is in the device on your desk. The composition is the present paper. The deployment is whoever is willing to do the work.
That is who this paper is written for.