A Bitcoin-anchored DID network
One shared history
Three registrars verify four creations from five submissions before the film explains the proposed SuperNova proof.
200 seconds · narrated explanation
The film includes narration, subtle sound effects and captions. Use fullscreen to read the diagrams on a phone.
ABC
Read the narration transcript
The narration follows an illustrative history through Bitcoin block 10 and explains the proposed proof. Download the narration text.
- 0:00–0:06
- The registrars begin by publishing their identities on Bitcoin. Registrar A registers in block one.
- 0:08–0:13
- Registrar B registers in block three. It uses its own identity on the same Bitcoin chain.
- 0:16–0:21
- C's registration appears in block five, and the registrars now check the same history.
- 0:24–0:32
- By block nine, they have checked the registrations and found no D I D operations. Their new requests will extend this completed base.
- 0:34–0:42
- Alice's request, A L one, asks to create her identity. The signed request names A as the provider she wants to serve her document.
- 0:44–0:52
- She sends the signed request to registrar A, where it waits for verification. Alice's identity will be created when her request passes the checks.
- 0:54–0:58
- Maya sends her own request to registrar A alongside Alice's.
- 1:00–1:02
- Ben sends his request to B.
- 1:05–1:08
- Cleo has chosen C and submits her request there.
- 1:10–1:14
- B carries Alice's signed request while her choice of provider stays A.
- 1:16–1:23
- The registrars put these requests into ordered batches. In A's batch, Alice comes before Maya, and that order is fixed.
- 1:24–1:28
- B's batch holds Ben's request, followed by the same Alice request.
- 1:30–1:34
- C seals Cleo's request against the same completed base through block nine.
- 1:36–1:43
- Each registrar sends Bitcoin a compact commitment to its completed base and new batch. The signed requests remain in storage.
- 1:48–1:56
- Block ten records the commitments at transaction positions three, eight and twelve. Each batch's requests then follow their committed internal order.
- 1:58–2:04
- A retrieves B's and C's full batches while their original copies and Bitcoin positions stay unchanged.
- 2:06–2:15
- B and C fetch the same batches in turn. They need the complete inputs to check the shared history, which remains verified through nine until those checks finish.
- 2:18–2:20
- Each fetched batch must match its Bitcoin commitment.
- 2:22–2:25
- The submissions are checked in Bitcoin and batch order.
- 2:26–2:30
- Alice's request passes the signature and state checks, so her creation takes effect.
- 2:32–2:35
- Maya's creation passes the same checks, followed by Ben's.
- 2:38–2:40
- Alice's request already took effect.
- 2:41–2:43
- Cleo's creation is accepted.
- 2:44–2:48
- B and C independently verify the same four creations through block ten.
- 2:50–3:00
- A registrar could use SuperNova to prove this ordered replay. It would extend a running proof as it checks each state transition, with different circuits for creation and recovery.
- 3:04–3:16
- The claim would bind base nine, all required inputs in order, the rules, and the history and state through block ten. Complete Bitcoin coverage must still be established, and registrars must keep the batch bytes available.
This illustrative design assumes available, eligible submissions. SuperNova is a proposed proving system; availability rules, the proof statement and protocol integration remain under design. The film generates and verifies no proof.