One shared history

The opening follows an illustrative history through Bitcoin block 10.

0:00–0:24

Registrar A registers in block 1. B registers in block 3. C registers in block 5. Each has an independent public identity.

0:24–0:34

They check the history through block 9: three registrars, zero DID lifecycle operations. That completed history is the shared starting point for their next submissions.

0:34–0:54

Alice signs a request to create her DID and select provider A. Her operation, AL-1, arrives at A. The signed request remains pending in registrar storage.

0:54–1:16

Maya also submits to A. Ben submits to B and Cleo to C. Alice sends an identical AL-1 to B as well. B carries that request, but Alice’s signed choice is still provider A.

1:16–1:36

The registrars seal three ordered batches against the checked history through block 9. A’s batch contains Alice then Maya. B’s contains Ben then the identical Alice request. C’s contains Cleo.

1:36–1:58

Their compact commitments enter Bitcoin block 10 at transaction positions 3, 8 and 12. Bitcoin binds and orders the commitments. The signed operation bytes stay off-chain.

1:58–2:18

A fetches B’s and C’s batches while their original copies remain stored. B and C also obtain the required batches. Every complete registrar holds the shared inputs. Downloading them is separate from verifying the history.

2:18–2:44

The registrars check committed bytes, authorization and whether each operation can take effect, following Bitcoin position and batch order. Alice, Maya and Ben are accepted. The repeated Alice request has already been applied, so it creates no second DID. Cleo is accepted.

2:44–2:50

Five submissions produce four accepted creations. A, B and C independently verify the same shared history through block 10. Alice and Maya select A, Ben selects B, and Cleo selects C.