Class Btc1Read

Implements 4.2.3.6 Apply DID Update.

This algorithm attempts to apply a DID Update to a DID document, it first verifies the proof on the update is a valid capabilityInvocation of the root authority over the DID being resolved. Then it applies the JSON patch transformation to the DID document, checks the transformed DID document matches the targetHash specified by the update and validates it is a conformant DID document before returning it. This algorithm takes inputs contemporaryDIDDocument and an update.

Implements 4.2.2.2.2 CAS Retrieval.

The CAS Retrieval algorithm attempts to retrieve an initialDocument from a Content Addressable Storage (CAS) system by converting the bytes in the identifier into a Content Identifier (CID). It takes in an identifier and an identifierComponents object. It returns an initialDocument.

Implements 4.2.3.5 Confirm Duplicate Update.

The Confirm Duplicate Update algorithm takes in a DidUpdatePayload | DID Update Payload and verifies that the update is a duplicate against the hash history of previously applied updates. The algorithm takes in an update and an array of hashes, updateHashHistory. It throws an error if the update is not a duplicate, otherwise it returns.

Implements 4.2.2.1 Deterministically Generate Initial DID Document.

This algorithm Deterministically Generate Initial DID Document algorithm deterministically generates an initial DID Document from a secp256k1 public key. It takes in a did:btc1 identifier and a identifierComponents object and returns an initialDocument.

Implements 4.2.2.2 External Resolution.

The External Resolution algorithm externally retrieves an intermediateDocumentRepresentation, either by retrieving it from Content Addressable Storage (CAS) or from the Sidecar Data provided as part of the resolution request. It takes in a did:btc1 identifier, a identifierComponents object and a resolutionOptions object. It returns an initialDocument, which is a conformant DID document validated against the identifier.

Implements 4.2.3.3 Find Next Signals.

The Find Next Signals algorithm finds the next Bitcoin block containing Beacon Signals from one or more of the beacons and retuns all Beacon Signals within that block.

It takes the following inputs:

• contemporaryBlockhieght: The height of the block this function is looking for Beacon Signals in. An integer greater or equal to 0.
• targetBlockheight: The height of the Bitcoin block that the resolution algorithm searches for Beacon Signals up to. An integer greater or equal to 0.
• beacons: An array of Beacon services in the contemporary DID document. Each Beacon contains properties:
  • id: The id of the Beacon service in the DID document. A string.
  • type: The type of the Beacon service in the DID document. A string whose values MUST be either SingletonBeacon, CIDAggregateBeacon or SMTAggregateBeacon.
  • serviceEndpoint: A BIP21 URI representing a Bitcoin address.
  • address: The Bitcoin address decoded from the `serviceEndpoint value.
• network: A string identifying the Bitcoin network of the did:btc1 identifier. This algorithm MUST query the Bitcoin blockchain identified by the network.

It returns a nextSignals struct, containing the following properties:

• blockheight: The Bitcoin blockheight for the block containing the Beacon Signals.
• signals: An array of signals. Each signal is a struct containing the following:
  • beaconId: The id for the Beacon that the signal was announced by.
  • beaconType: The type of the Beacon that announced the signal.
  • tx: The Bitcoin transaction that is the Beacon Signal.

Implements 4.2.2 Resolve Initial Document.

This algorithm resolves an initial DID document and validates it against the identifier for a specific did:btc1. The algorithm takes in a did:btc1 identifier, identifier components object, resolutionsOptions object and returns a valid initialDocument for that identifier.

Implements 4.2.3.4 Process Beacon Signals.

The Process Beacon Signals algorithm processes each Beacon Signal by attempting to retrieve and validate an announce DID Update Payload for that signal according to the type of the Beacon.

It takes as inputs

• beaconSignals: An array of Beacon Signals retrieved from the Find Next Signals algorithm. Each signal contains:
  • beaconId: The id for the Beacon that the signal was announced by.
  • beaconType: The type of the Beacon that announced the signal.
  • tx: The Bitcoin transaction that is the Beacon Signal.
• signalsMetadata: Maps Beacon Signal Bitcoin transaction ids to a SignalMetadata object containing:
  • updatePayload: A DID Update Payload which should match the update announced by the Beacon Signal. In the case of a SMT proof of non-inclusion, no DID Update Payload may be provided.
  • proofs: Sparse Merkle Tree proof used to verify that the updatePayload exists as the leaf indexed by the did:btc1 identifier being resolved.

It returns an array of DID Update Payloads.

Implements 4.2.2.2.1 Sidecar Initial Document Validation.

The Sidecar Initial Document Validation algorithm validates an initialDocument against its identifier, by first constructing the intermediateDocumentRepresentation and verifying the hash of this document matches the bytes encoded within the identifier. It takes in a did:btc1 identifier, identifierComponents and a initialDocument. It returns the initialDocument if validated, otherwise it throws an error.

Implements 4.2.3 Resolve Target Document.

The Resolve Target Document algorithm resolves a DID document from an initial document by walking the Bitcoin blockchain to identify Beacon Signals that announce DID Update Payloads applicable to the did:btc1 identifier being resolved. It takes as inputs initialDocument, resolutionOptions and network. It returns a valid DID document.