UTXO DID Method Normative Reference
8.1 DID Syntax
DID method name: bsv
DID method specific identifier: 64 characters long hexadecimal presentation of BSV Blockchain transaction ID
The hexadecimal presentation MUST use lowercase characters for hexadecimal digits a–f.
Example: did:bsv:8280eadd84515d071e942f1548af7891e0182bf83e7b5848a02b0a58543fbf5f8.2 Verifiable Data Registry
UTXO DID method SHOULD use BSV Blockchain as a public ledger to store the DID related data and statuses. Each DID is recorded as a sequence of chained transactions of the following kinds:
DID issuance transaction, which is the first transaction in the DID chain
DID document transaction, a transaction which OP_RETURN data contains a version of the DID document
DID revocation transaction, which MUST be the last transaction in the DID chain and which presence invalidates DID Owing to the blockchain design, each of the DID document transactions MUST be preceded by either DID issuance transaction or a special DID funding transaction which provide additional funds for mining fees. DID funding transactions do not change the state of DID.
Below text uses the following symbols that refer to SECP256K1 private and public keys:
C0 , PKC0 DID controller’s private and public key, respectively.
S0, PKS0 DID subject’s private and public keys, respectively.
SigC0, SigS0 Signatures made by using DID controller’s or DID subject’s private keys, respectively.
It also uses term identityCode. This is a code that identifies the DID controller that created by transactions. This code MUST be present, and it SHOULD be unique.
8.2.1 DID Issuance Transaction
The issuance transaction has one input and one output. The input spends the funding UTXO provided out-of-band by the issuance transaction creator. The UTXO spent by this transaction MUST contain enough funds to cover mining fees for this and two next transactions. The OTXO of DID issuance transaction MUST provide funds to cover mining fees for two next transactions. The locking script of DID issuance transaction MUST require signatures by both DID controller and DID subject to spend it. The first segment of the OP_RETURN data payload MUST be set to the string literal BSVDID. The second segment of the OP_RETURN payload MUST be set to identityCode. The third segment of the OP_RETURN data payload MUST be set to string literal 1 (numerical digit 1). Implementations MAY add more segments for their own use.
8.2.2 DID Document Transaction
The DID document transaction is funded either by the DID issuance transaction or DID funding transaction. It carries DID document in the third segment of OP_RETURN payload. The transaction has one input which MUST spend the UTXO provided by either DID issuance or DID funding transaction.
The UTXO of DID document transaction MUST provide funds to cover mining fee for the next transaction. The locking script of DID document transaction MUST require signature by either DID controller or DID subject to spend it. The first segment of the OP_RETURN data payload MUST be set to the string literal BSVDID. The second segment of the OP_RETURN payload MUST be set to identityCode. The third segment of the OP_RETURN data payload MUST be set to the JSON string representing DID document. Implementations MAY add more segments for their own use.
The transaction ID (TxID) of the DID document transaction is the versionId of the DID document and resolvable as such. The timestamp of the block that contains the DID document transaction is the versionTime of the DID document and resolvable as such.
8.2.3 DID Revocation Transaction
The DID revocation is funded by the preceding DID document transaction. The transaction has one input which MUST spend the UTXO of the preceding DID document transaction. The transaction MUST one output with value 0, which makes it unspendable. The DID revocation transaction, when present, is thus the last transaction in the DID chain and invalidates the DID.
The OTXO of DID revocation transaction MUST have value 0 and SHOULD have no other locking script but OP_FALSE OP_RETURN. The first OP code should be OP_FALSE to prevent spending output. The first segment of the OP_RETURN data payload must be set to the string literal BSVDID . The second segment of the OP_RETURN payload MUST be set to identityCode. The third segment of the OP_RETURN data payload MUST be set to string literal 3 (numerical digit 3). Implementations MAY add more segments for their own use.
8.2.4 DID Funding Transaction
The DID funding transaction does not affect the DID state and is used only to bring in additional funds needed to extend the DID transaction chain. IT has two inputs and one output. The first input MUST spend the out-of-band UTXO provided by the creator of this transaction. This UTXO MUST provide enough funds to cover mining fee for two transactions. The second input MUST spend the UTXO of the preceding DID document transaction, which provides funds to cover mining fee for one transaction.
The OTXO of DID funding transaction MUST provide funds to cover mining fee for two next transactions. The locking script of DID funding transaction MUST require signature by both DID controller and DID subject to spend it. The first segment of the OP_RETURN data payload MUST be set to the string literal BSVDID. The second segment of the OP_RETURN payload MUST be set to identityCode. The third segment of the OP_RETURN data payload MUST be set to string literal 2 (numerical digit 2). Implementations MAY add more segments for their own use.
8.2.5 Example of DID Transaction Chain
THIS SECTION IS NOT NORMATIVE
The below example shows the DID transaction chain for DID that had one change in DID document and was finally revoked.
Last updated