Class SMTAggregateBeacon

Creates an instance of SMTAggregateBeacon.

Get the Beacon service.

Implements 5.3.2 Broadcast SMTAggregate Beacon Signal.

See Beacon Interface Method broadcastSignal for more information.

To publish a DID Update Payload, the DID controller MUST get a hash of the DID Update Payload included at the leaf of the Sparse Merkle Tree (SMT) identified by their did:btc1 identifier and receive an inclusion proof for this data. If a member of the Beacon cohort does not wish to announce an update in a Beacon Signal, they MUST receive and verify a proof of non-inclusion for their DID. Upon verifying the non-inclusion proof against the SMT root contained in the Beacon Signal, they SHOULD accept and authorize the signal following the MuSig2 protocol. Once all members of the cohort have authorized the signal, it can be broadcast as a transaction to the Bitcoin network. DID controllers are responsible for persisting their DID updates and proofs, these will need to be provided through a Sidecar mechanism during a resolution process.

TODO: Figure out if this is necessary or not.

Implements 5.3.3 Process SMTAggregate Beacon Signal.

See Beacon Interface Method processSignal for more information.

A Beacon Signal from a SMTAggregate Beacon is a Bitcoin transaction with the first transaction output of the format [OP_RETURN, OP_PUSH32, <32bytes>]. The 32 bytes of data contained within this transaction output represent the root of a Sparse Merkle Tree (SMT). This SMT aggregates a set of hashes of DID Update payloads. In order to process these Beacon Signals, the resolver MUST have been passed Sidecar data for this signal containing either the DID Update payload object and a SMT proof that the hash of this object is in the SMT at the leaf indexed by the did:btc1identifier being resolved. Or theSidecar data:: MUST contain a proof that the leaf indexed by the did:btc1identifier is empty, thereby proving that theSMT:: does not contain an update for their identifier.

The Process SMTAggregate Beacon Signal is called by the Process Beacon Signals algorithm as part of the Read operation. It takes as inputs a did:btc1 identifier, btc1Identifier, a Beacon Signal, tx, and a optional object, signalSidecarData, containing any sidecar data provided to the resolver for the Beacon Signal identified by the Bitcoin transaction identifier.

It returns the DID Update payload announced by the Beacon Signal for the did:btc1 identifier being resolved or throws an error.

Implements 5.3.1 Establish Beacon.

The Establish Beacon algorithm is essentially the same as for the CIDAggregate Beacon in Establish CIDAggregate Beacon. A cohort of DID controllers need to coordinate to produce a Bitcoin address that will act as the Beacon. It is RECOMMENDED this is an n-of-n P2TR address, with n being the set of DID controllers in the cohort. Once the address has been created, and all parties in the cohort acknowledge their intention to participate in that Beacon, each DID controller SHOULD add the Beacon as a service to their DID document.

Additionally, the SMTAggregate Beacon cohort participants MUST register the did:btc1 identifiers they intend use this Beacon with. This is so the Beacon coordinator can generate the necessary proofs of both inclusion and non-inclusion for each DID.

Static, convenience method for establishing a Beacon object.