A Bitcoin-anchored DID network
One shared history
Three registrars. Five submissions. Four creations.
170 seconds · opening sequence
Narration with subtle sound effects. Captions included. Use fullscreen for a closer look.
ABC
Read the narration transcript
The spoken narration follows an illustrative history through Bitcoin block 10. Download the narration text.
- 0:00–0:07
- Three independent registrars are forming a network. Registrar A records its public identity in Bitcoin block one.
- 0:08–0:15
- Registrar B registers independently in block three. Its identity is public too, on the same Bitcoin chain.
- 0:16–0:22
- Then registrar C joins in block five. With all three identities public, they turn to the shared history.
- 0:24–0:33
- They verify through block nine: three registered identities, with no D I D operations yet. That empty history becomes their shared starting point.
- 0:34–0:41
- Let's follow Alice. She signs A L one, a request to create her identity, and chooses registrar A to serve her document.
- 0:44–0:51
- When registrar A receives it, the request is still pending. Holding the bytes hasn't yet created Alice's identity.
- 0:54–0:57
- Maya sends her own request to A, alongside Alice's.
- 1:00–1:02
- Meanwhile, Ben sends his request to B.
- 1:05–1:07
- And Cleo sends hers to C.
- 1:10–1:15
- Alice sends B the same signed request. B carries it; her provider stays A.
- 1:16–1:23
- Now the registrars seal ordered batches. Registrar A puts Alice first, then Maya, and keeps that order fixed.
- 1:24–1:28
- B seals Ben's request first, then the identical Alice request.
- 1:30–1:34
- C seals Cleo's. Each batch extends their shared base through block nine.
- 1:36–1:44
- Each registrar sends a compact commitment to Bitcoin, binding the completed base and its new batch. The full signed operation bytes stay off-chain.
- 1:48–1:55
- In block ten, transaction positions three, eight, and twelve set the batch order. Within each batch, requests keep their committed order.
- 1:58–2:04
- A fetches B's and C's complete batches. Copying leaves the originals and their Bitcoin positions unchanged.
- 2:06–2:15
- B and C fetch the same batches in turn. Having the inputs lets them begin checking; their verified history stays at block nine until those checks finish.
- 2:18–2:21
- First, match each batch to its Bitcoin commitment.
- 2:22–2:25
- Then follow the submissions in Bitcoin and batch order.
- 2:26–2:31
- Alice's signature is valid. Her creation fits the current state and takes effect.
- 2:32–2:36
- Maya's creation passes the same checks. Ben's passes next.
- 2:38–2:40
- Alice's request already took effect.
- 2:41–2:43
- Finally, Cleo's creation is accepted.
- 2:44–2:49
- B and C check independently. All three agree: four creations, verified through block ten.
An illustrative protocol design: this example assumes available, eligible submissions and uses symbolic commitments. Availability and eligibility rules, and cryptographic proofs, remain under design. The film performs no real cryptography.