Re: Introducing the Bitcoin Ordinals DID Method

Hi Alen,

Let me address your great list of requirements:

- DID method or DID Registry (Verifiable Data Registry) should serve as a
decentralised PKI (DPKI).
This method definitely turns Bitcoin into DPKI

- It should be capable of key updates, suspensions, revocation, rotation
(update+revoke). Suspension/Revocation can be direct or mandated/federated.
This method is capable of handling all of these operations as every update
to the DID is declaring the entire new state of the DID Document.

- It should support historical DID/key resolution.
Yes, the previous states are all resolvable by tracing the state back to
the required time frame.

- “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.
I will have to think more on this but it sounds like an operation to be
done outside of a DID method, for example having a Shamir Secret Sharing
scheme to allow recovery of the Bitcoin spending key(s).

- As DPKI for legal entities or enterprises it should be able to define
relationships between one or more DIDs.
This seems like it is better suited for Verifiable Credentials and not
built into a DID method.

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.
Any information including their DID Documents? This method only uses
blockchain to store keys and service endpoints.

If ordinals are transferable, implications for DIDs should be clear.
The transfer of the ordinal is exactly how the method is powered. When an
ordinal inscription is transferred it signals that it is no longer the
current state and there will be either a new state in the same transaction
or the DID will be deactivated. The inscription will still be hanging
around and effectively be a receipt at that point. Theoretically those
receipts are still transferable however the method will not be interested
in what happens after the initial transfer so will ignore it.

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.
Bitcoin is still the most dominant cryptocurrency and the easiest to
acquire. Yes, it still acts as a barrier to entry for the majority of the
world that doesn't own any but it is by far the best option available in
this regard when limiting the scope to permissionless networks.

Thanks for your thoughts,
Brian

On Mon, May 1, 2023 at 11:47 PM Alen Horvat <alen.horvat@netis.si> wrote:

> 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* r**equire 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> 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
>>>>>>>
>>>>>>>
>>>>>>>
>