§Introduction
In the early 2000s there were thousands of people in the United States with kidney failure, a relative willing to give them a kidney, and a blood type that made the gift impossible. Say a patient in Boston has a type A donor and a patient in Ohio has a type B donor. Each could save the other's life. They never meet, because nothing in the medical system is set up to look. In 2004 the economists Alvin Roth, Tayfun Sönmez, and Utku Ünver published the design for a clearinghouse that would look, and New England transplant centers built the first regional one on that design, with its first transplants the following year. Paired kidney donation in the United States now produces about a thousand transplants a year.
I think most of the economy looks like that waiting list. A finance team is writing requirements for a system that a small company across town has already built three times. A lab is about to repeat an experiment that failed quietly at a competitor last year. Two startups in the same investor's portfolio should be each other's first customer, and the partner who could introduce them has two hundred companies to think about. The information that would connect them exists, in unusual detail, in shared drives, repositories, lab notebooks, and old proposals. It is private, and there is no safe way to let it meet.
A company's website is what it wants you to believe. Its shared drive is what it is. Nobody publishes their shared drive, for good reasons: it belongs to them, it is often confidential by contract, and much of it is valuable because competitors don't have it. So every organization stays a black box to every other, and introductions happen by luck.
What I'd like to propose is a way for organizations to pool what they know without any of them giving it away. I'll call it a confidential collective intelligence: a shared, continuously updated understanding of what a group of participants can offer and need, computed inside hardware designed so that no participant and no operator can look into it, which releases only what each participant has agreed to release. Agents inside sealed machines read what each participant connects, keep a catalog of what everyone offers and needs, and propose introductions that happen only if both sides say yes.
Three things have recently made this buildable. Confidential computing has reached the GPU, so a language model can run inside hardware that isolates its memory from the host and signs a statement of what code is running. Public blockchains give us somewhere to anchor that statement where no operator can quietly change it. And language models can now read a folder of messy evidence and write a fair account of what an organization does.
I'm the founder of Lit Protocol, a network for holding keys that no single machine ever sees, and of Room, the alpha described in section VII. Before that I was part of founding a company that LinkedIn acquired.
IThe Knowledge Problem
In 1945 Friedrich Hayek published a short paper called "The Use of Knowledge in Society." His argument was that the knowledge an economy runs on is not held in any one place and cannot be. It exists as "dispersed bits of incomplete and frequently contradictory knowledge which all the separate individuals possess." His example was a shipper who makes a living from knowing about half-empty tramp steamers. No planner can collect that kind of knowledge, because it is local, tacit, and changes faster than any survey.
Hayek's answer was the price system. A price compresses what a market knows about a good into one number that anyone can act on without knowing why. He called it a marvel.
But a price is a narrow channel. It aggregates willingness to trade a known good. It says nothing about who could build something that has no price yet, who has already solved the problem you're about to spend six months on, or which two teams should be talking.
Kenneth Arrow explained why in a 1962 paper on the economics of invention. To convince a buyer that a piece of information is worth paying for, you have to reveal it, and once revealed the buyer has it for free. That is why information is hard to sell: the buyer can't inspect it first. The same trap catches any organization deciding whether to tell a stranger what it knows. To show you we could help, we'd have to show you how we helped someone else, which is the one thing we're not allowed to show you.
George Akerlof added the third leg in 1970 with "The Market for Lemons." When one side of a trade knows more than the other and can't credibly share it, the market shrinks. Good sellers can't distinguish themselves from bad ones, buyers assume the worst, and trades that would have benefited both sides never happen. Akerlof wrote about used cars, but the argument applies just as well to consultants.
Economics did not stop there. The field of market design, which grew out of a 1962 paper by David Gale and Lloyd Shapley and matured in Roth's hands, is largely about matching parties who hold private information and will only proceed if both agree: doctors to hospitals, students to schools, patients to kidneys. What market design has always assumed is a clearinghouse that is allowed to see everything. The kidney exchange works because hospitals send it their patient data and a trusted institution runs the algorithm. It also carries a warning for anything built in its image. Roth and Itai Ashlagi documented hospitals holding back their easy-to-match pairs to transplant locally and sending the clearinghouse only the hard cases, which lowered the total number of transplants for everyone. Participants hold back their best assets whenever joining costs them something, and any room built on these ideas will face the same temptation to connect its thin folders and keep the good ones back.
The internet's answer to Arrow's trap was publication. If you can't share what you know, at least publish a description of yourself. This gave us company websites, directories, review sites, and professional networks, each a catalog of self-descriptions: what an organization chose to write about itself, at the time it chose to write it, for an audience it wanted to impress. They are thin, and they are stale, because nobody updates a marketing page with bad news.
The cost of this shows up as entire professions. Business-to-business sales exists largely to solve the problem by force: hire people to guess who might need you and interrupt them until one says yes. Procurement is the mirror image: write down what you need and wait for the guessers to find you. Partnerships form through personal networks, which means between people who already know each other. In each case both sides would be better off if they could see each other.
IIWhat a Confidential Collective Intelligence Is
It runs as a loop with four steps.
Connect. A participant connects data where it already lives: a document store, a code repository, a customer database, a folder of proposals. The participant chooses what to connect, can withdraw it, and nothing is copied anywhere in the clear.
Catalog. Inside the sealed space, an agent reads the connected evidence and maintains a catalog entry for the organization: what it can offer, what it needs, what it is working on, what it has done before. The entry is a set of claims, each pointing back to the evidence that supports it. Neither the evidence nor the claims ever leave the sealed space. As the underlying data changes, the entry changes.
Search. Other agents search the catalog inside the sealed space, in narrow tasks, looking for fits: a need in one organization that matches a capability in another, a project one team is planning that another has shipped, two roadmaps that interlock. These agents can see everything, which is what makes them useful. They can say almost nothing, which is what makes them safe. Their only output is a recommendation to connect, sent to each party and explained in terms of that party's own evidence.
Introduce. Each party receives the recommendation along with whatever the other party has chosen to say about itself in advance: a short, self-written description with names left out. If both accept, the system releases identities and opens a channel. If either declines or never answers, the other learns nothing. Every disclosure is recorded, with what was shared, to whom, and under which approval, in a log the owner can read.
The loop closes when introductions produce new evidence. A conversation starts, a contract is signed, a project ships, and the participant's data changes. The catalog updates, and new fits appear.
IIIA History of Computing on Secrets
In 1841 Lewis Tappan, a New York abolitionist whose family silk business had been ruined by the panic of 1837 and by a boycott his politics had earned him, started a company called the Mercantile Agency. Its product was a ledger. Tappan recruited correspondents across the country, mostly lawyers, to send confidential reports on the character and creditworthiness of every business in their town, usually in exchange for the agency's debt-collection referrals, and he sold access to those reports to New York merchants deciding whether to extend credit. The agency's histories list among its early correspondents a young Illinois lawyer named Abraham Lincoln and a clerk in his father's leather store named Ulysses Grant, which means two future presidents spent part of their early careers reporting on their neighbors' finances.
Tappan had found that merchants would pay well for a current catalog of every business. The Mercantile Agency became R.G. Dun & Company, merged with its rival Bradstreet in 1933, and survives today as Dun & Bradstreet, still cataloging companies and still selling the entries.
He had also found the catalog's central problem. The businesses being described had no say in what was written about them, no way to see it, and no way to correct it. The ledgers were secret from their subjects and open to their subjects' creditors. Within a decade the agency was fighting libel suits from the businesses it described; one of them, brought by an Ohio merchant whose entry reported that his wife was about to sue him for divorce and that he had moved his property out of reach, ran for years and reached the Supreme Court in 1870. The consumer credit bureaus that copied the model a century later grew so intrusive that Congress passed the Fair Credit Reporting Act in 1970 to give people the right to see their own file. A living catalog of organizations is valuable, but built without their consent it becomes a surveillance machine, and that has been true for a hundred and eighty years.
For more than a century there were only two ways to handle knowledge that couldn't be shared without being given away: publish less, or find an intermediary you trusted, and Tappan had shown what intermediaries become. Cryptography eventually offered a third.
Andrew Yao posed the question in 1982. Two millionaires want to know which of them is richer, and neither will say how much they have. Can they find out? Yao showed they could, and in doing so founded the study of secure multiparty computation: how several parties can compute a function of their private inputs and learn nothing beyond the answer. The millionaires' problem is a toy, but it has our shape. Two organizations want to know whether they fit, and neither will say what it knows.
Three years later, at the 1985 IEEE Symposium on Security and Privacy, Robert Baldwin and Wayne Gramlich presented a paper with the plain title "Cryptographic Protocol for Trustable Match Making." The example later papers cite from it is a company that wants to hire someone with particular skills without advertising the opening, and a candidate who wants to find a new job without telling their employer they're looking. The protocol lets each side learn that the other is interested only if the interest is mutual. If it isn't, neither learns anything, and the paper treats both the case where the matchmaking server can be trusted and the case where it can't. It is, in effect, the mathematics of a mutual crush, and it is the introduction step this essay depends on.
In 1997 Nick Szabo wrote a short essay called "The God Protocols" that I think is the clearest statement of the goal. Imagine, he said, a trusted third party we might as well call God. Everyone sends God their private inputs. God computes whatever needs computing and returns to each party only their own output, and nobody learns anything else. Szabo pointed out that multiparty computation lets us approximate this arrangement without the deity. Most of what has happened in the field since can be read, I think, as attempts to build a cheaper god.
In 2004 Helen Nissenbaum supplied a piece cryptography couldn't, in a paper called "Privacy as Contextual Integrity." Privacy, she argued, is about whether information flows appropriately for the context in which it was shared, not about whether it is secret. A company describing its past projects to a prospective customer is an appropriate flow. The same facts, scraped by a broker and sold to a competitor, are a violation, though the facts are identical. This is the right test for a system that has to decide what may move: would the owner consider this particular flow legitimate?
The hardware arrived next. Intel shipped the first widely available user-programmable enclave on general-purpose processors in 2015: a mode in which a program's memory is encrypted with a key that never leaves the chip, and the chip can sign a statement, called an attestation, naming by cryptographic hash exactly which program is running. AMD and Intel followed with versions that seal an entire virtual machine, the Linux Foundation formed a Confidential Computing Consortium in 2019, and in 2023 NVIDIA shipped GPUs whose workloads could be attested and whose memory was isolated from the host.
The idea that a cloud customer should not have to trust the cloud has a date on it. In 2014 three Microsoft researchers presented Haven, the first system to run an ordinary application inside an SGX enclave on a cloud machine, and their paper gives the reason in one sentence: as the Snowden leaks had demonstrated the year before, a cloud user implicitly trusts law enforcement in any jurisdiction where their data may be replicated. The two threats Haven set out to remove were a malicious employee of the provider and a government subpoena. Three years later Azure sold the same idea under the name confidential computing, and the other clouds followed. The GPU step is the one this essay needs: before it, an enclave could hold a key or check a signature, but not a language model.
Tim Berners-Lee, at about the same time, decided the web he invented needed fixing. He began the Solid project at MIT in 2015 and wrote in 2018 that the web had "evolved into an engine of inequity and division" because personal data had been centralized in a handful of platforms. Solid's proposal was to reverse the flow: your data lives in a store you control, and applications come to your data and ask permission. This essay departs from Solid in one place. In the design below, the data does travel, into a sealed machine, because reading a million documents needs the documents and the model in one place. The enclave brings the data to the application without letting the operator watch.
Public blockchains, which arrived in 2009, contribute something specific and easy to misunderstand. They are not a place to put private data; everything on them is public. What they provide is a program that runs the same way for everyone and a record that no administrator can alter. The approved list of enclave programs, the rule for who gets which key, and the record of what ran belong somewhere no single party controls, and a public ledger is the first such place we've had.
The last piece is the newest. Until a few years ago, computing on secrets meant arithmetic: comparing numbers, matching identifiers, summing columns. The knowledge that matters in an organization is prose, code, diagrams, and half-finished documents, and the only way to learn what a company could do was to have a person read them. A language model can now read them inside an enclave and write a faithful account, and it can do the second job too, the search across the catalog, which needs judgment rather than lookup: this need and that capability are the same thing described in different words. None of that was possible in 2015.
Catalogs of companiesWhy the knowledge stays locked upComputing on secrets
IVWhat Exists Today
Several kinds of systems solve part of this already.
Publishing platforms. Professional networks, company databases, review sites, and marketplaces are catalogs of self-descriptions. Most business discovery runs on them. Their limits follow from their inputs: every entry was written by its subject, for an audience, at a moment, and the platform sees everything, so the more you tell it the more you've given away.
Data brokers and credit bureaus. Tappan's heirs. Their catalogs are rich because they were assembled without asking. They show both that the catalog is valuable and why it has to be built differently.
Data clean rooms. Over the last decade, mostly driven by advertising, the industry built environments where companies can join their datasets and compute aggregate statistics without seeing each other's rows. Google's Ads Data Hub arrived in 2017, and Amazon, Snowflake, and others now sell general versions. A few, such as Decentriq and Microsoft's confidential clean rooms on Azure, run inside attested enclaves, so the hardware guarantee I'm describing is not new to the category. What clean rooms don't do is the rest of the loop. They compute aggregates over tables rather than discover opportunities in documents, and they are built for a handful of parties who already know each other rather than for a many-to-many search among strangers.
Secure multiparty computation and homomorphic encryption. The strongest guarantees available, and still orders of magnitude too slow to run a language model over a million documents. They have an essential role in the design below, holding and releasing keys through threshold schemes so that no single party can unlock anything alone. They are the wrong tool for the reasoning layer.
Federated learning. It trains a shared model without moving the data, which is a good trick that answers a different question. A trained model is not a catalog and does not introduce you to anyone.
Matching platforms. Dating apps and their business imitators get the interaction right, since nobody sees a name until both sides say yes, but the platform itself reads every profile and every message, and its business depends on that.
Each of these gets one piece right. The rest of this essay is about assembling the pieces into one loop, and about the ways that loop can fail.
VDesigning a Confidential Collective Intelligence
Principle 1Evidence and claims stay sealed. Only a recommendation leaves.
The raw material (files, records, code, notes) is read inside the enclave and nowhere else. What the system produces from it is a set of claims: "has built invoice automation for a finance team," "is looking for a manufacturing partner with cleanroom capacity," "shipped a scheduling product in 2025." Each claim points back to its evidence so it can be checked inside the sealed space, and neither the evidence nor the claims are ever part of any output. The only thing that crosses the boundary is a recommendation to connect, addressed to each party and explained in terms of that party's own data. What a party then says about itself, and to whom, is a human decision. This loosens Arrow's trap rather than dissolving it. A recommendation is itself a signal, and Principle 6 is about what that signal can leak.
Principle 2Nobody can look inside, and anyone can check that.
Every step that touches a participant's data runs in an attested enclave, one that can prove by hash which program is running inside it. The code is published. Its hash is registered in a public program on a blockchain. A participant's data is encrypted to keys held by a threshold of independent parties, and those parties release a key only to an enclave whose attestation matches a registered hash.
1
2
3
4
- Compute chiplets. The eight small dies around the edge. This is where the program's code runs, inside an encrypted virtual machine. They never see a key.
- I/O die. The large die in the middle. It carries the memory controllers and the encryption engine: everything leaving the package for the memory modules is encrypted here, and decrypted here on the way back.
- The chip that holds the keys. On the I/O die sits the AMD Secure Processor, a separate ARM Cortex-A5 core with its own firmware. It generates the memory-encryption keys, holds the signing key derived from fuses burned in at the factory, and signs the attestation report that names the running program by hash. None of those keys ever leave it. The ledger checks that report before any data key is released.
- The substrate. The wiring that connects the dies to each other and to the socket beneath. From here outward, across the memory bus to the modules, the data is ciphertext. The 2025 interposer attacks read data from that bus.
The enclaves are ephemeral, but only the compute is. The data persists: the catalog, the encrypted evidence, and the log of past disclosures all live in storage encrypted to those threshold keys, readable only by the next attested enclave that needs them. Anyone, anywhere, running attested hardware can provide an enclave just in time for a task, and it turns off when the task ends. The next task can run on a different machine under a different operator, and the participant's data is no worse off, because the keys were only ever released to code whose hash was registered, not to any particular company's servers. What learns across participants, for instance which kinds of introductions turn into contracts, learns only from outcomes participants have agreed to report.
The operator moves data without being able to read it, and a participant can verify that. The full statement of who you trust is longer than "the chip." You trust the chip vendor's attestation keys and the vendor-run services that vouch for them; the threshold of key holders not to collude; the published code, which you or someone you trust has read; the public ledger; and whoever can add a new program hash to the approved list. The last is the most important. Whoever controls upgrades is the new operator, so the upgrade key must itself be held by a threshold, changes must be announced onchain before they take effect, and a participant must be able to withdraw its keys before a change it dislikes applies. Every item on that list can be inspected, which is not true of a company's promise.
One more choice belongs to this principle: which model does the reading. My view is that an open-weight model inside the enclave is already good enough to draft a brief, if not yet for the subtlest matching, and that the gap narrows every year. Until it closes, a room can send evidence to a frontier model behind an API, in which case that provider reads it and Principle 2 does not hold for that step, no matter what the provider's retention policy says. A room's governance has to choose, per task, and every record has to state which venue it ran in.
Principle 3The catalog is alive.
A catalog entry written once is wrong within a quarter. Teams ship, needs get met, people leave. The value of a confidential collective intelligence over a directory comes from its connection to the evidence rather than to a form someone filled out, so it can notice change. When a repository gains a project or a document store gains a proposal, the entry updates. Staleness produces wrong introductions, and a wrong introduction is the fastest way to lose a participant. A team that gets introduced to a buyer for something it stopped doing last year will not accept the next one.
Principle 4Discovery happens inside.
Matching can work at three depths. At the shallowest, the system compares only the self-written descriptions each participant has chosen to show, which is what a directory with a good search box does. In the middle, an agent reads a participant's own private evidence and compares it against other participants' self-written descriptions; each organization's data is read only on its own behalf, so the only party it needs protecting from is the operator, not the other members. At the deepest, agents search across all the evidence at once, which is where the best fits are, because a need and a capability are usually the same thing described in different words and you need the documents, not the summaries, to see it.
Whatever the depth, the agents' sole output is a recommendation to connect, addressed to each party and explained only in terms of that party's own evidence, and it passes through a separate check before it leaves. Nothing derived from one participant's data is shown to another. That output channel is the narrow waist of the whole design and should be the most carefully audited part of the code.
Principle 5Consent is a protocol.
Following Nissenbaum, every disclosure is its own decision, made by the data's owner, for a named recipient and purpose. In practice: the only description of a participant another participant ever sees is one the first participant wrote and chose to show. Identity is released only on mutual acceptance, as in Baldwin and Gramlich. Every disclosure is recorded with what was shared, to whom, and under which approval, in a log the owner can read and the operator cannot edit. Withdrawing a source stops future use of it. One complication: a company's files contain other people's information, such as customers' names and terms under non-disclosure, and the company's consent does not settle their claims. Keeping claims inside the sealed space is the first defense, since nothing derived from those files is ever shown to another party, and a room's governance should say what else is required.
Principle 6Neither silence nor a match should leak.
Being in the catalog must not itself be a disclosure. A participant who is never matched should be indistinguishable, to everyone but itself, from one who was never there. A declined introduction should tell the decliner nothing beyond the description they already saw and tell the other party nothing at all. Any output whose size, timing, or existence depends on private data is a leak, including anything written to the ledger.
The harder problem is probing. Suppose a member is the only one in a room with a cleanroom. A competitor could connect a fabricated "need" for cleanroom capacity and watch whether a recommendation comes back. Repeat with a few dozen crafted needs and the competitor has mapped the room's capabilities and can start guessing who holds them. Every matching system with private inputs has this exposure. The defenses are governance as much as code. Admission control, so that a room's members are known organizations rather than accounts, is the first and does most of the work. Limits on how many introductions any participant can receive about any other in a period are the second. Batching and delaying the release of matches helps against timing leaks rather than against probing itself. And a participant's connected sources should be treated as evidence that can be checked, since a claim backed by a signed commit history or a verified domain is harder to fabricate than one backed by a pasted document. Fabricated evidence brings Akerlof's lemons problem into the room. None of this closes the problem, and I don't know of a design that does.
What the hardware doesn't promise
Attestation proves which code ran. It does not prove nothing leaked. Enclaves have a long record of side-channel attacks, and in 2025 three research groups showed that an interposer costing less than a thousand dollars, placed on the memory bus of a server, could read secrets out of Intel's and AMD's server enclaves, including current generations. In one demonstration the attackers extracted the CPU's attestation keys, which was enough to pass off an unprotected GPU workload as a confidential one. Chip vendors mostly leave physical attacks out of their threat models.
The design responds in layers. Because compute is provided just in time and released per task, a compromised machine holds only the data routed to it, not everyone's, with one important exception: the deepest search step, where an agent sees every entry, is the highest-value target in the system. It should be broken into narrow tasks, per pair or per shard of the catalog, at some cost in match quality. Threshold keys mean a compromised machine can decrypt only what was released to it. Against stolen attestation keys, just-in-time compute and thresholds do nothing; the answers there are the vendors' own revocation and recovery procedures, requiring attestations from more than one vendor for the most sensitive tasks, and refusing to run on hardware whose physical custody is unknown. Spreading tasks across vendors and operators means one broken product doesn't break the room. And stating on every record which venue it ran in means that when the hardware improves, a participant can tell.
Verifying an attestation onchain is not a single signature check. It means checking the vendor's certificate chain and revocation data, which someone has to relay to the chain, and for GPUs it currently depends on NVIDIA-run services, an offchain party that belongs on the trust list above. The ledger must not become a leak either. What goes onchain is hashes and commitments, batched, never an event a reader could tie to a participant, because a public record of who ran what and when would violate Principle 6 by itself.
VIRooms for Consortia
Room is one room, open to any team that signs up. Nothing about the method requires that. Any group can run the same attested code against the same root of trust and get a room of its own, with its own members and rules.
The clearest case is a venture fund. A fund with two hundred portfolio companies knows that dozens of them should be each other's customers, that several are quietly building the same internal tool, and that at least one has already solved the compliance problem another is about to hire a consultant for. The partners know this in the abstract and cannot act on it, because acting on it means reading two hundred companies' internal documents and holding all of it in one head. Each company would be glad to be found by the right sibling, and none of them wants to hand its roadmap to its investor, who may also back a competitor. A room changes the arrangement: the companies connect their repositories and their planning docs, the fund sets the schema and the admission list, an agent inside the room reads everything, and the only thing that comes out is "these two should talk," to both of them, if both agree. The fund gets what the participants release to it and nothing more, and it should hold at most one share of the upgrade key; otherwise it is just a trusted intermediary again.
The same shape serves a biotech consortium that wants to know when two members are working on the same target or when a negative result in one lab would save another six months; a hospital network looking for trial capacity or a vendor another site has already vetted, over data that is protected by law and therefore never moves; and a trade association matching members' surplus capacity to unmet demand among firms that also compete.
What varies between rooms is governance: who is admitted, what schema the catalog uses, what a member may say about itself in an introduction and to whom, which model providers are permitted and under what retention terms, who audits the logs, and how upgrades are approved. What stays the same is the code, the attestation, and the root of trust.
Two questions come up every time. Why would the first member join an empty room? And who pays? A room starts with a convener who already has the members, such as a fund, an association, or a hospital system, rather than with strangers. The convener pays, because the convener is the one who currently spends staff time doing this badly by hand. Rooms that grow beyond their convener can later admit outsiders under the same rules.
The closest existing precedent is the multiple listing service in real estate, which began in the 1880s as brokers in a city agreeing to pool their listings under shared rules. Each region runs its own database under a shared convention. A confidential collective intelligence has the same shape, with two differences: the entries are computed from evidence rather than typed in, and the pool is sealed.
VIIWhat We've Built
Two halves of this exist today that I've built with my team.
Room runs the matching. At useroom.ai, a team connects a folder or a tool, an agent drafts a brief from the evidence, the team edits and approves it, and Room looks for fits against other teams' approved briefs. When it finds one, each side gets a recommendation. If both accept, Room makes the introduction and records what was shared and under which permission. It is an alpha, and its runs execute on ordinary infrastructure today, which every record says.
Lit runs the sealed room. Lit Protocol's network, Chipotle, executes any program inside attested Intel TDX enclaves, including AI workloads on confidential GPUs, with no operator access to runtime memory. Its keys come from a decentralized root of trust built on dstack: the root secret is shared across independent enclave nodes, at least two-thirds of them must cooperate to use it, and a smart contract decides which nodes may join, which code they must run, and which programs may receive keys. Lit's permission state lives on Base, every program is identified by the content hash of its code, and the network secures about fifty billion dollars a year in cross-chain volume. That is Principle 2 in production, with paying users.
The wire between them is next. As Room approaches a thousand monthly active users, its catalog and search runs move into Lit's enclaves, and the word on each record changes from ordinary to attested. If you'd like to try the matching, connect a folder. If you'd like to run a room for a consortium, or help build the wire, get in touch.
VIIICheaper Gods
Szabo's god was a party everyone could trust with everything because it would return to each of them only what was theirs to know. He was clear that no such party existed and that the point of cryptography was to build a substitute. Twenty-nine years later the parts of a substitute exist: hardware that keeps a program's memory from the machine's operator, within the limits I've described; ledgers no administrator can rewrite; and models that can read a company's documents.
Lewis Tappan's ledger made him rich and made his subjects furious, and both reactions were correct. The catalog of every company has been worth building for a hundred and eighty years, and it has never been built with the consent of the companies in it, because there was no way to do that which didn't require either publishing their secrets or trusting someone with them. Now there is a third way. Here is what you can do with it.