How it works

The mechanisms

The making runs in stages paced by new Bitcoin blocks, and each stage is made of many small legs. Each leg produces a result recorded in the PCOC. A verifier later selects legs at random from across the hike and recomputes them to check the recorded results.

1. Make. Your device generates a key pair, fills and retains a 256 MiB terrain, then runs memory-dependent legs continuously. When the producer observes a new Bitcoin block header, that header closes the current stage and provides the reference for the next. The process continues through 18 stages. Your private key stays on the device.
2. Anchor. The construction binds the hike to Bitcoin in both directions. Bitcoin block headers provide the public references used during production. At stage boundaries, the producer derives waypoints from the work and submits them for anchoring. groundinglab’s Bari service batches accepted waypoints into Bitcoin transactions. You can operate your own Bari instance, or use a direct-to-Bitcoin approach. Anchoring is best effort: the object records which paths were available, and the verifier measures them. Bitcoin does not check the legs or certify the making.
3. Keep. When the last stage closes, the terrain is released. You keep a small file containing your public key and the production record. The public key is the self-issued identifier. You show the file when a service asks; the service receives it as a small file.
4. Check. The verifier measures the PCOC against the published specification and the corresponding public Bitcoin record, normally obtained through a portable index. It checks the object’s structure, its Bitcoin bindings and the recorded checkpoint relationships. It also recomputes six legs selected at random from across the hike. The service’s admission policy can require additional rounds of six. The verifier needs the public key in the object, but not the maker’s private key or access to the maker’s device. It reports measurements; it does not make the admission decision.
5. Decide. The service’s policy reads the measurement record and says yes or no. Two services can measure the same object under different requirements and make different admission decisions. Policies differ by design; none is the right answer, and none is a promise of protection.

Stage = wait for the next public block, then hold memory. Leg = one unit of that memory work. The cost is holding memory while blocks pass, not a short burst of hashing.

A shared specification, a different role for resource commitment

Bitcoin and PCOC share an important architectural principle: independent participants operate under a common set of rules and independently validate the objects they receive.

In both systems, participants adopt a common protocol contract. They implement its rules independently and do not require a central issuer to certify every object before another participant can examine it.

Participants who adopt the same specification version share a contract for what constitutes a valid object.

There is, however, a distinction between agreement on rules and agreement on a shared history.

Bitcoin: proof-of-work establishes a shared history

Bitcoin nodes validate transactions and blocks against common consensus rules. Proof-of-work changes the basis of influence from network addresses to accumulated computational work.

When competing valid histories arise, the chain with the greatest accumulated proof-of-work determines which history nodes follow. Miners express their acceptance by building on that chain. Other nodes independently validate the blocks and transactions and follow the valid chain with the greatest accumulated work.

In his 13 November 2008 correspondence, Satoshi Nakamoto explicitly described the proof-of-work chain as a solution to the Byzantine Generals’ Problem: reaching agreement despite participants who may be faulty or malicious.

PCOC: resource commitment attaches to each identifier

PCOC applies the resource-commitment principle at a different level.

Its common specification defines how an identifier is produced and how the resulting object is measured. Independent producers and verifiers implement that specification. The agreement on the specification creates a shared definition of a valid PCOC and allows objects produced by different implementations to be interoperable.

The resource commitment is carried by each identifier. Producing another identifier requires another staged memory commitment. The resource commitment is incurred by the producer of each PCOC. It is not a fee for using the specification, measuring an object or operating an admission service.

A verifier measures the resulting object against the specification and the public Bitcoin record. A relying service then applies its own admission policy.

PCOC does not establish a separate shared history of PCOC activity or a network-wide decision to admit an object. Those decisions remain with individual relying services.

Why this shape

Some making can be pre-computed, solved once, or reused across many attempts. A door or a CAPTCHA farm works that way: pay the hard case once, then replay. Memory held while Bitcoin blocks you do not control arrive is a different shape. The holding is tied to stages paced by a public clock whose next tick is not yours to schedule, and the design aims for that cost to start fresh for each identifier. How far that holds when someone makes many at once is still being measured.

A newly observed Bitcoin header closes the current stage and provides the reference for the next. Inside a stage, the device runs many legs (memory work). A verifier later redoes a sample of legs drawn at random from across the whole hike and checks the results.

Stage = continuous memory work until a new public header is observed. Leg = one unit of that memory work. The cost is holding memory while blocks pass, not a short burst of hashing.

Best-effort anchoring. Waypoints are submitted for anchoring, but not every path is necessarily available to the verifier. The final waypoint, W17, is not fetched by design. Earlier paths may be skipped or unavailable. The object records the available evidence, and the verifier measures it. Anchoring records the making; Bitcoin does not certify the legs.

Stays local: the memory and your private key. Travels: the PCOC, with your public key and its leg results; a service receives it as a small file. Public: Bitcoin’s blocks and the anchors.

Bitcoin as the clock

Bitcoin’s blocks are a shared public tick. They pace the stages. Satoshi called this a timestamp server; here that tick is the clock the making waits on.

Each PCOC incorporates Bitcoin block references into its construction and records the waypoint anchoring evidence that was obtained. Bitcoin records; it does not check legs or certify the making.

With a batch anchoring service, you need no bitcoin, wallet, or node. Who anchors is a choice: groundinglab’s batch anchoring service, your own copy of that service, or anchoring directly.

The shared public tick stops anyone making one identifier faster than the 18-block schedule: each stage waits on a new public header. Holding memory per identifier is what makes many cost more. Parallel makings all wait on the same blocks, so the unpredictability of the next tick does not by itself raise bulk cost. The design aims for the memory commitment not to amortise across many identifiers; how that holds at scale is still being measured.

Blocks pace the making. Anchors record points along the way. Bitcoin does not certify the legs.

The principles

• Self-issuedNo issuer, registrar or account. The identifier starts on your device.
• Checkable by anyoneThe record is in the PCOC and in Bitcoin’s public record. No one has to be asked.
• Measure, then decideThe verifier records; only the service’s policy accepts or refuses.
• Each service sets its own rulesgroundinglab’s gate is one policy, not the policy.
• Bitcoin as the clock and the anchorBitcoin block headers pace and bind the production process. Waypoints are submitted for anchoring, and the resulting evidence is measured independently. Bitcoin does not certify the making.
• Open, and run your ownOpen specification and code. The hosted index, hosted anchoring service and hosted admission gate are optional. You can operate your own services or use the specified alternatives.

It does not make fake accounts impossible. Each identifier is designed to carry its own cost; whether a service accepts one identifier per account is that service’s policy.

The whole design in about seven minutes.

Who runs each part

Questions

The questions people ask are answered one at a time in Learn. Start with Fundamentals: why bots win, issued, listed or made, why memory and a clock, and how you can check a stranger without asking. Or start from your own world in By audience.

The specification, the SDKs and the code are open, in one repository: github.com/groundinglab/pcoc.

Inspect a real example PCOC (groundinglab’s own production object, measured by the site verifier).