Re: Introducing the Bitcoin Ordinals DID Method

Dear,

Thoughts/remarks from experience of designing/building DID methods/VDRs:

- DID method or DID Registry (Verifiable Data Registry) should serve as a decentralised PKI (DPKI).
- It should be capable of key updates, suspensions, revocation, rotation (update+revoke). Suspension/Revocation can be direct or mandated/federated.
- It should support historical DID/key resolution.
- “Key recovery” should be one of the properties of the DPKI, to avoid custom key recovery, i.e., the DID method should be such that it should not depend on individual key recovery.
- As DPKI for legal entities or enterprises it should be able to define relationships between one or more DIDs.

When it comes to Natural Persons, it is advisable to not store information on any blockchain (at least in EU). Combining key rotation with sole control is challenging for all cases.

If ordinals are transferrable, implications for DIDs should be clear.

Scalability is already being discussed. Another point is usability - I need BTC to register and manage my DID. This can represent a challenge for adoption.

Hope, this helps.

BR, Alen


On 2 May 2023, at 00:15, Brian Richter <brian@aviary.tech> wrote:

Yes, we agree Bitcoin as it is currently architected will never support billions of users on layer 1 however the bet I'm making is that there will be users willing to pay a premium to get their keys and services endpoints embedded on layer 1. I am hoping we can keep a single DID operation to below that $0.50 mark for a very long time which I agree is not ideal 😅. But this is still a small price to pay to avoid any L2 tradeoffs whatsoever.

I'm interested in hearing your thoughts about the technical architecture of the method. It's essentially an identity baton that hands off control of the DID to another DID every update. Inscriptions have a commit/reveal pattern that works nicely for key pre-rotation as popularized with KERI. I am considering whether or not to use an "alsoKnownAs" field that would help trace a random inscription to its root DID document.

Brian

On Mon, May 1, 2023 at 2:57 PM Gabe Cohen <gabe@tbd.email> wrote:
Sure, but the situation isn’t so binary. Lightning is an adaptation of Bitcoin that allows significantly higher scale — anyone in the world can transact with it. The same is true of the ION DID method, which is an L2 on BTC—it supports batches of 10k for about $0.50. That scales pretty well, albeit with some L2 tradeoffs.

I’m not opposed to block space being filled up as long as the fees are paid, as is the law of Bitcoin. My point was more that the DID method doesn’t inherently have wide utility if it fundamentally can’t scale to supports billions.

Gabe

On May 1, 2023 at 2:39:24 PM, Brian Richter <brian@aviary.tech> wrote:
Thanks Gabe

By limiting block size and relying on a fee market Bitcoin core has already signalled that not everyone will be able to transact on it. The cost of using this method will definitely rise to become unaffordable for most people just as regular transactions will. This is just one of many ways block space will be filled driving fees up. For example there is already a fungible token standard using inscriptions that is making transactions very costly.. We can debate whether these are valid use cases of the network all day long but at the end of the day block space will be used by whoever is willing to pay for it.

For anyone who finds the costs to be too egregious I will likely be creating a similar method on other Bitcoin forks that have made different scaling decisions which will of course have other tradeoffs.

Brian

On Mon, May 1, 2023 at 1:50 PM Gabe Cohen <gabe@tbd.email> wrote:
Cool work, Brian!

I’m curious if you’ve run any numbers for how well the method scales? I see there’s a section on cost/transaction fees which mentions batching.
Do you know the cost If, say 1000 or 10k DIDs were in it?

 I am trying to evaluate DID methods on a global scale. This means each human on earth could have multiple. So, if everyone on earth used the method (let’s say 10B DID:BTCOs), would it consume all Bitcoin block space and become untenable?

If not, seems like it’s more of an experiment, which still has value — and is neat!

Gabe

On May 1, 2023 at 12:39:01 PM, Brian Richter <brian@aviary.tech> wrote:
Melvin,

There is no proposal being made here for you to oppose. If inscriptions were off-chain this would break the discoverability of the method and require additional sidechains or tokens which goes against the main goal of the method. Since inscriptions are possible on the Bitcoin network today this method is also already possible.

Since the method inherits the security of layer 1 Bitcoin it is the most decentralized and censorship-resistant method available. I am more interested in hearing this community's thoughts regarding the technical implementation, not the politics of whether Bitcoin should or shouldn't be used for decentralized public key infrastructure. Bitcoin is so much more than a financial network.

Brian

On Mon, May 1, 2023 at 12:22 PM Melvin Carvalho <melvincarvalho@gmail.com<mailto:melvincarvalho@gmail.com>> wrote:


po 1. 5. 2023 v 21:01 odesílatel Brian Richter <brian@aviary.tech> napsal:
Hello CCG,

I have created Yet Another DID Method. This method uses Bitcoin transactions directly on L1 to manage DID Document state. The full specification can be found on github<https://github.com/ordinalsreserve/btco/blob/main/spec.md>. I welcome your feedback, questions, and suggestions as this method is developed and refined. Please don't hesitate to send me questions about the method or ordinals directly.

The Bitcoin Ordinals DID method is a decentralized identifiers (DIDs) solution that leverages the Bitcoin blockchain and ordinal theory. By uniquely identifying individual satoshis, this method enables creating, resolving, updating, and deactivating DIDs without altering the Bitcoin network or requiring additional sidechains or tokens.

DID Syntax and DID Document
DIDs in this method have a specific syntax, which includes a method-specific identifier derived from the Bitcoin address and the ordinal position of a satoshi. The syntax can be represented as did:btco:<satoshi>.

A DID Document contains a DID's public key, authentication information, and service endpoints. The data model follows the W3C DID Core Specification, using JSON or JSON-LD as the serialization format.

Creating a DID Document
Select a unique identifier using ordinal theory to determine a specific satoshi within the Bitcoin blockchain.

  1.  Create a public/private key pair for cryptographic operations and authentication.
  2.  Define any necessary service endpoints for communication or interaction with the DID.
  3.  Create a DID Document with the required properties following the DID Core Specification.
  4.  Inscribe this document (long form json or short form text) onto the satoshi with the ordinal number mentioned in the identifier.

Resolving a DID Document

  1.  Retrieve the inscription data from the satoshi associated with the method-specific identifier.
  2.  If this utxo has been spent, look for the next DID Document by finding another inscription in the spending transaction.

Updating a DID Document

  1.  Perform a Bitcoin transaction that sends the inscription to the control of a new public key (burns the current DID Document). In the same transaction, inscribe the new DID Document. The control will effectively transfer to this new DID.

Deactivating a DID

  1.  Perform a Bitcoin transaction that updates the DID but does not transfer control to a new DID.

In summary, the Bitcoin Ordinals DID method provides a practical and secure solution for managing digital identities within the decentralized identity ecosystem. By leveraging the existing Bitcoin blockchain and ordinal theory, this method enables a range of innovative use cases and applications.

-1 to this.  Strongly oppose.

The bitcoin network works best as a financial network

Inscriptions belong off-chain, with at most a reference to them, on-chain


Best regards,

Brian Richter
Founder / CEO
Aviary Tech / Ordinals Reserve
brian@aviary.tech