The Book You Sold
On the difference between owning a digital thing and merely having seen it
Keywords: revocable encryption, NFT, threshold cryptography, trusted execution environment, ownership, digital sovereignty, BSV, oracles, ECDH, hierarchical secret sharing
There is a particular variety of foolishness that the digital age has elevated into a philosophy, and it is the foolishness of believing that one can sell what one has read. The medieval bookseller knew better. He sold you a codex; you took it home; if you sold it again to your neighbour, you ceased to possess it. The book left your shelves and arrived on his. The transaction was clean because the object was tangible, and tangible objects obey a law older than property: they cannot be in two places at once.
The digital age forgot this law and, in forgetting it, made every transfer a fraud. When you sell a digital photograph, an electronic novel, a piece of music encoded as bits, you do not part with it. You give a copy to someone else and retain the original yourself. The buyer is not buying possession; he is buying the fiction of possession. He pays you for a ceremony, not a thing. The bits remain on your drive. The encryption key remains in your keychain. You promise, with the solemnity of a man who has not understood what he has sold, that you will not use what you still possess. You ask the buyer to trust you. He has no choice. The architecture of the medium provides no other option.
This is what the NFT was supposed to fix, and this is what the NFT, in its present form, has not fixed at all.
The NFT, as it has been deployed in fashionable corners of the internet over the past several years, is a token that points at a thing. The token can be transferred. The thing typically cannot. If the thing is a piece of digital art stored on a server somewhere, the buyer of the NFT receives a record on a public ledger asserting that he is the owner; the seller receives a payment; and the file itself sits placidly on whatever server it has always sat on, accessible to anyone with the URL, including the man who just sold it. The token has changed hands; the asset has not. We have invented a deed of title for a house that has no walls.
Defenders of this arrangement will tell you that ownership of digital things is social — that what matters is the public recognition of who holds the deed, not who holds the keys to the door. This is the same argument by which courtiers convinced themselves that the emperor’s new clothes were a triumph of tailoring. With sufficient social agreement, the deed alone can carry meaning. In the absence of social agreement, the deed becomes a kind of high-priced postcard.
The harder question, and the one which no amount of social agreement can dissolve, is this: how do we make a digital asset behave the way the medieval codex behaved? How do we make selling it actually part with it? How do we ensure that when Alice transfers her e-book to Bob, Alice loses her ability to read the e-book?
This is not a question about politics or economics. It is a question about cryptography and architecture. And it has an answer.
Begin with the obvious failed approach: give the buyer the decryption key. Alice owns an encrypted e-book; the key is in her wallet; she can decrypt and read whenever she wishes. She sells to Bob. She hands Bob the key. Now Bob can decrypt and read. So can Alice, who has the key written down in seventeen places, three of them in the cloud. The transaction was a transfer of capability in the same sense that telling someone your password is a transfer of capability: the new party gains it, the old party retains it. Nothing has been parted with except an obligation.
The second failed approach is to entrust the key to a single server. The seller’s key is forgotten; the buyer is enrolled with the server; the server now decrypts on behalf of the new owner. This works, in the narrow sense that revocation is achieved. It also concentrates every digital asset into the custodianship of a single party — typically a corporation — who can read every book, watch every film, deny service to any user, and be subpoenaed, hacked, bribed, or destroyed. The cure is worse than the disease.
There is a third path, and it requires that we abandon the notion that the decryption key must be held by anyone in particular. The key, properly speaking, must not exist anywhere as a single object. It must exist only as a relationship — a mathematical relationship — between several parties, no one of whom can perform decryption alone, and all of whom together can be reorganised when ownership changes hands.
Imagine that the key to the e-book has been broken into seven pieces, in such a way that any five of them, combined according to a particular procedure, reconstitute the key, but any four are useless. This is an old idea. Adi Shamir wrote it down in 1979, and the cryptographers have been refining it ever since. What is new is what we do with the seven pieces.
Three of them go into a small sealed box that lives on Alice’s computer. The box is what the engineers call a trusted execution environment — a piece of silicon that performs computations but refuses to disclose, even to Alice, the values it computes upon. The box can use the three pieces. The box cannot give Alice the three pieces. Alice can interrogate the box, can ask it to perform decryptions on her behalf, can receive the resulting plaintext for her enjoyment. She cannot reach inside and pull out the keys.
The other four pieces are scattered across an open pool of strangers — call them oracles, after the cryptographic literature, though the word is grander than the office. These oracles do not know each other. They have no telephone numbers, no email addresses, no shared chat room. They communicate, when they communicate at all, by posting transactions on a public ledger. They are pseudonymous. Their reputation, such as they have, is the cumulative honesty of the public key under which they have signed their past responses.
When Alice wishes to read her book, the box on her computer composes a request. The request says, in effect: I require two further pieces; here is a temporary public key for this session; respond on the ledger with my pieces, encrypted to my temporary key, and I shall pay you. The request is broadcast to the world.
Two oracles, somewhere, receive it. They cannot see each other; they do not know how many other oracles will respond. Each performs a small calculation involving its own private key and Alice’s temporary public key — the elliptic-curve mathematics that has secured Bitcoin since 2009. The product is a shared secret known only to the responding oracle and Alice’s box. Each uses this shared secret to encrypt its piece. Each posts the encrypted piece on the ledger, alongside a claim against the small payment Alice has reserved.
Alice’s box reads the ledger. It performs the same elliptic-curve calculation in reverse, recovering the shared secrets, decrypting the pieces. It now has five — its own three, and the two newly received. It performs the reconstruction, recovers the key, decrypts the next chapter of Alice’s book, displays it on her screen, and wipes the key from its memory. Alice never sees the key. The oracles never see each other. The world sees only encrypted noise on the ledger.
Now consider what happens when Alice sells the book to Bob.
The sale is recorded on the ledger as a simple transaction: Alice’s signature spends the token; the token is reissued under Bob’s public key. Standard fare. But the cryptographic layer is doing something quieter, more interesting, beneath the surface.
The oracle pool watches the ledger. When the transfer transaction confirms, the oracles execute a small ritual. They generate fresh pieces of the same key — different polynomial points, the same secret — and arrange for three of these new pieces to be sealed-delivered into a fresh box on Bob’s computer. The old pieces, the ones in Alice’s box, are abandoned. Alice’s box, which is incapable of giving Alice the old pieces in any case, now refuses to engage with them at all because the ledger says Alice is not the owner.
Could Alice, in principle, ask the oracles for two further pieces under her old session key? She could. The oracles will refuse. They have read the ledger; they have seen the transfer; their policy is to encrypt their responses to whoever currently holds the token. Any responses are encrypted to Bob’s session keys, not Alice’s.
What if an oracle is corrupt? What if Alice has bribed one to encrypt a response to her old session key after the transfer? The transaction is on the public ledger. Anyone can post a challenge — a small follow-up transaction that says, here is the transfer to Bob; here is the oracle’s misdirected response; both are on the chain at the cited heights; therefore the oracle has cheated, and his payment is forfeit. The oracle’s escrow is slashed. The economics, not the morality, of the situation have aligned against his cheating.
Could Alice corrupt enough oracles? The oracles are an open pool, and the subset that responds to any given request is determined by an unpredictable selection on the ledger, drawing on the hash of a future block that does not yet exist when she might wish to bribe. She does not know whom to bribe. She cannot prearrange her conspirators. She would have to bribe at least two and have all survive the challenge window without a single honest soul noticing. The challenge mechanism does not require a majority of honest oracles. It requires a single honest watcher anywhere in the world.
This is what we mean when we say the system has no trusted authority. The trust is distributed across so many small economic decisions, each anchored in the public visibility of the ledger, that no single failure can compromise the whole.
There is an objection that any honest reader will have raised by now, and it deserves a frank answer rather than a sleight of hand.
What if Alice, during her ownership, copied the plaintext of the book into a text file and saved it on her hard drive? What if she read the book and remembers it? What if she gave a copy to a friend?
The construction does not, and cannot, revoke any of these things. Alice’s local files remain her local files. Her memories remain her memories. Her friend’s copy remains her friend’s copy. The cryptography revokes her ability to perform new decryption operations against the ciphertext stored at the storage layer. It does not revoke what she already knows.
This is not a defect of the construction; it is a defect of the universe. Bits, once observed, cannot be unobserved. Memories, once formed, cannot be erased. Any system promising to revoke historical reads is selling a metaphysical impossibility. The medieval codex has the same property: a man who reads a book and then sells it remembers the contents. The seller of the codex does not become illiterate. He merely loses the object and, with it, the ability to re-read.
What the construction provides is precisely the digital analogue of losing the object. After transfer, Alice cannot re-fetch fresh state. She cannot decrypt new chapters released after the sale. She cannot continue to consume an evolving service. If the asset is a static, finite, fully-revealed thing she has already consumed in its entirety, the construction provides no marginal protection beyond what physical theft would provide for a paper book. If the asset is anything dynamic — a streaming service, an evolving game state, a software licence whose validity must be re-established per session, a model that updates, a feed that flows — then the construction restores to digital ownership the property that physical ownership has always had: that selling means parting with.
There are also the inevitable side-channel anxieties. Could Alice extract her three pieces from the trusted execution environment by some clever attack on the silicon? Possibly. But the layered architecture earns its keep. Even if Alice extracts her three pieces, she still needs two more from the oracles to reconstruct the key, and the oracles, after the transfer, will not encrypt to her any longer. The TEE is not a single point of failure because it is not the single point of trust.
The reader who has stayed this long deserves to be told, plainly, why this matters beyond the cinematic example of a sold book.
Consider the licensing of professional software. At present, the seller of a CAD package or a video editor or a statistical engine ships you a binary and a key. Your ownership of the software is asserted by your possession of the key. If you sell the licence to a colleague, the seller ceremoniously revokes your old key on his licence-server. The transaction is mediated by a corporation whose continued operation is required for the integrity of every sale on its platform. When the corporation goes bankrupt, your software stops working.
Consider the secondary market for digital media. At present, there is none. Steam will not let you sell your library. Audible will not let you transfer an audiobook. The Kindle will not let you give away a novel. The reason offered is technical — the medium does not support transfer — but the reason is dishonest. The medium has not been built to support transfer because the parties profiting from the medium prefer that you cannot. Your purchases are not yours; they are leases dressed up as purchases.
Consider the management of confidential data within an enterprise. At present, access is mediated by an identity-management system that can be queried, hacked, or subpoenaed. When an employee leaves the company, the company’s protection against that employee’s continued access is the goodwill of the administrator. The construction described above does not require an administrator. The employee’s TEE binding to the assets is severed by the on-chain change of ownership; the oracle pool refuses to issue fresh pieces under the departed employee’s session keys; the contestation mechanism enforces the policy.
Consider, finally, the long arc of digital identity. Every piece of digital infrastructure that has ever held your data has, at some point in its history, suffered a breach. The breaches will continue. The question is not whether your data will be exfiltrated but whether, at the moment of exfiltration, the exfiltrated data is still useful. A construction that ties decryption to ongoing ownership turns the exfiltrated dump into a snapshot of historical state. The exfiltrator finds that the bytes mean nothing because the keys to interpret them are bound to the trusted execution environments and oracle pools that he could not exfiltrate.
Let me restate the construction, briefly, in the form of an equation that anyone with elementary algebra can read. The decryption key K for the asset is reconstructed from a set of pieces s_1, s_2, ..., s_n, each piece a number, combined by a procedure (Tassa’s hierarchical scheme) that requires all of the owner-tier pieces and at least a threshold count from the oracle-tier pieces. Schematically:
K = combine(s_owner_1, s_owner_2, s_owner_3, s_oracle_i, s_oracle_j)
where the s_owner_ live in the owner’s TEE and the s_oracle_ are delivered on demand by oracles, encrypted to the owner’s per-session key.
The encryption of an oracle’s piece in transit is
E_j = AEAD(HKDF(z_j), s_j)
where z_j = sk_oracle_j × P_session, the elliptic-curve product of the oracle’s private key and the owner’s session public key. Anyone observing the ledger sees E_j and the oracle’s public key but cannot recover z_j without one of the two private keys.
When ownership changes, the oracle pool re-runs the share generation under the new session structure. The owner_-tier pieces in Alice’s TEE are abandoned; new owner_-tier pieces are sealed into Bob’s TEE. The oracle-tier pieces, when next requested, are encrypted to Bob’s session key:
E_j_new = AEAD(HKDF(sk_oracle_j × P_Bob_session), s_j_new)
Alice has neither sk_oracle_j nor sk_Bob_session, and so even if she somehow held one of her old pieces in her hand, she could not reconstitute the key from new oracle responses. Her revocation is not a matter of her promising not to read; it is a matter of the cryptography, by construction, denying her the necessary pieces.
The economic security comes from the contestation:
Pr(false attestation survives W blocks) ≤ W × p_no_watcher
and the expected loss to a colluding oracle is at least b_min, the per-response escrow. The honest watcher need not be a designated guardian; anyone running open-source verification software is a watcher, and a single one suffices.
These are not merely diagrams; they are the architecture itself. The mathematics carries the weight that contracts and compliance officers cannot.
I do not, as a rule, write to celebrate machinery for its own sake. There is too much of that already in our age, and most of it is the celebration of toys by people who have mistaken complexity for civilisation. But the present construction is not complexity for its own sake. It restores a property that the digital revolution had stolen, and that no amount of legal contortion or platform mediation has been able to give back. It says: what you sell, you part with; what you keep, you keep; the difference between the two is mathematical, not contractual; and no party stands between you and that difference except the public ledger that anyone may read and that no-one can rewrite.
The medieval bookseller would have understood. The mathematician will recognise the proof. The philosopher of property will see in it the recovery of a category that the computer scientists, in their early enthusiasm, accidentally abolished.
There is a further point worth making, because it is invariably missed by commentators who confuse cryptography with surveillance and revocation with control. The construction described here is, at every layer, anonymous. The oracles do not know who Alice is. They do not know who Bob is. They do not know each other. Each oracle sees, on the public ledger, a request signed by a temporary public key it has never seen before, and it answers, into a void, with an encrypted response. It receives payment from the same void. It accumulates a reputation under a pseudonymous public key, which it may abandon at any time and replace with another, at the cost of forfeiting the reputation it had built.
This is what permissionless infrastructure actually looks like when it is built honestly. It is not the absence of rules; it is the absence of gatekeepers. The rules — that an oracle must encrypt to the current owner, that a payment must be claimed honestly, that misbehaviour is contestable — are enforced not by a body but by the public visibility of the ledger and the small economic cost that any party can impose on any other for a violation.
The pseudonymous oracle is also a more interesting economic agent than the corporate trustee. The corporation has a reputation that is partly the reputation of its parent company, partly its compliance posture, partly the regulator that supervises it. When the corporation fails, all three reputations fail together. The pseudonymous oracle has only its on-chain history. Every transaction it has ever signed is visible to anyone who cares to look. This is the closest the digital world has come to the reputation of a craftsman in a guild — an identity bound entirely to the quality of work, not to the trappings of office.
There remains the question of incentives. Why would anyone run an oracle?
The protocol pays them. Each request reserves a small payment for each respondent; the response, if it survives the challenge window, claims it. An oracle that consistently behaves correctly accumulates payments. An oracle that misbehaves has its payment forfeit. The on-chain history of each oracle public key becomes a cumulative judgment of its honesty. This is, structurally, the same mechanism that supports Bitcoin mining: an open pool of pseudonymous participants who do useful work in exchange for protocol-issued payments, with the integrity of the system coming not from the trustworthiness of individual participants but from the cost-incentive structure of the protocol itself.
Because every interaction is on-chain and pseudonymous, the construction supports one-shot transfers. There need not be a continuous oracle network running between Alice’s purchase and Bob’s purchase. The protocol is summoned by a request transaction; the responses are summoned by the request; the payments are claimed by the responses; the protocol completes. It can run once, between a single Alice and a single Bob, with two oracle responses, and then go quiet. It can also run continuously for a streaming service consumed by millions. The same primitives serve both.
Let me restate the construction, briefly, in the form of an equation that anyone with elementary algebra can read. The decryption key K for the asset is reconstructed from a set of pieces s_1, s_2, ..., s_n, combined by a procedure (Tassa’s hierarchical scheme) that requires all of the owner-tier pieces and at least a threshold count from the oracle-tier pieces:
K = combine(s_owner_1, s_owner_2, s_owner_3, s_oracle_i, s_oracle_j)
where the s_owner_ live in the owner’s TEE and the s_oracle_ are delivered on demand by oracles, encrypted to the owner’s per-session key.
The encryption of an oracle’s piece in transit is
E_j = AEAD(HKDF(z_j), s_j)
where z_j = sk_oracle_j × P_session, the elliptic-curve product of the oracle’s private key and the owner’s session public key. Anyone observing the ledger sees E_j and the oracle’s public key but cannot recover z_j without one of the two private keys.
When ownership changes, the oracle pool re-runs the share generation under the new session structure. The owner-tier pieces in Alice’s TEE are abandoned; new owner-tier pieces are sealed into Bob’s TEE. The oracle-tier pieces, when next requested, are encrypted to Bob’s session key:
E_j_new = AEAD(HKDF(sk_oracle_j × P_Bob_session), s_j_new)
Alice has neither sk_oracle_j nor sk_Bob_session, and so even if she somehow held one of her old pieces in her hand, she could not reconstitute the key from new oracle responses. Her revocation is not a matter of her promising not to read; it is a matter of the cryptography, by construction, denying her the necessary pieces.
The economic security comes from the contestation:
Pr(false attestation survives W blocks) ≤ W × p_no_watcher
and the expected loss to a colluding oracle is at least b_min, the per-response escrow. The honest watcher need not be a designated guardian; anyone running open-source verification software is a watcher, and a single one suffices.
There is a kind of dignity in being able to sell a thing and have it gone from you. There is a kind of squalor in selling and lying about it, in promising not to use what you still possess, in pretending that a public ledger entry is the same as a transfer of capability when it is in fact only a transfer of social belief.
The squalor has been the default for thirty years. It does not have to remain the default. The construction is here. The mathematics works. The economics align. The only remaining question is whether the parties who profit from the squalor will accept the discipline of the new arrangement, and that, of course, is a question of will and not of capability.
I am inclined to think they will not, and I am inclined to think it does not matter. The discipline of the new arrangement is available to anyone who wishes to adopt it. It does not require their permission. The book you sold, properly sold, will be a book you have parted with. The keys will not follow you home in your pocket like guilty stowaways. The ledger will record the change, and the cryptography will enforce it, and the next morning when you sit down at your desk and open the file you used to own, the screen will return to you the answer that ownership has always required and that the digital age has, until now, been unable to provide:
This is no longer yours.
And that, in the end, is the whole of the matter.