Re: Introducing the Bitcoin Ordinals DID Method

Thanks Ben,

I have added an issue to include a section re: attacks on bitcoin. Ordinal
inscriptions inherit all of the properties of regular bitcoin payments in
this regard. If miners collude to attack the network and are able to steal
coins they would likely be able to rewrite DID Documents as well. Important
to touch on, as unlikely as such an event is.

Brian

On Sun, May 7, 2023 at 6:22 PM bengoering@gmail.com <bengoering@gmail.com>
wrote:

> I admit I am new to the ordinals thingo. my understanding is that btco
> inherits the risks of using the underlying ledger as an integrity mechanism.
>
> Some examples of risks of trusting a blockchain for data integrity are
> explained here by a pretty good security auditing firm.
> [image: preview.png]
>
> Unintended_Centralities_in_Distributed_Ledgers
> <https://www.trailofbits.com/documents/Unintended_Centralities_in_Distributed_Ledgers.pdf#page9>
> PDF Document · 1.2 MB
> <https://www.trailofbits.com/documents/Unintended_Centralities_in_Distributed_Ledgers.pdf#page9>
>
> <https://www.trailofbits.com/documents/Unintended_Centralities_in_Distributed_Ledgers.pdf#page9>
>
> In order to help end-users make safe choices, it it also worth explicitly
> enumerating the dangers of using a DID that is subject to adversarial
> rewriting of a did document via attack on the ledger.
>
> I think something you could do with btco that might mitigate these risks
> is:
> * add a cryptographic signature segment to the end of the DID that signs
> the part before it. Upon resolution of the did doc, verify that the
> signature corresponds to one of the verification methods
> (rel=authentication) in the did doc AND, critically, that the did doc
> contains an integrity proof that is signed by the same key.
>
> Then if I used the did for awhile, but later that DID is attacked via
> eclipse attack or mining pool collusion, such that some validators resolve
> the did:btco ordinal to a did doc I didn’t intend, the attacker would be
> unlikely to be able to add the integrity proof unless they’ve also stolen
> my integrity proof mechanism.
>
> I can empathize with why people may prefer to try to stay safe (from
> identity theft, etc) by trusting a ledger, and why other people would want
> to stay safe by only trusting their ability to keep their keys a secret. I
> don’t think there’s a one size fits all approach, which is why I think it’s
> important that all candidate solutions earnestly advertise the risks and
> benefits so end-users can make a decision of informed consent.
>
> Sorry if the ordinals or inscription aspect to things provides further
> integrity or reliability on top of BTC itself. If so, the above
> considerations may not apply.
>
> I found the above report at this link
> darpa.mil <https://www.darpa.mil/news-events/2022-06-21>
> [image: favicon.ico] <https://www.darpa.mil/news-events/2022-06-21>
> <https://www.darpa.mil/news-events/2022-06-21>
>
> which contains a good quote
> “
>
> The study resulted in a report that provides holistic analysis that’s
> available to anyone considering blockchains for important matters so they
> can better understand the potential vulnerabilities within these systems.
>
> “The report demonstrates the continued need for careful review when
> assessing new technologies, such as blockchains, as they proliferate in our
> society and economy” said Joshua Baron, DARPA program manager overseeing
> the study. “We should not take any promise of security on face value and
> anyone using blockchains for matters of high importance must think through
> the associated vulnerabilities.”
>
> “
>
> On May 6, 2023, at 1:18 AM, Snorre Lothar von Gohren Edwin <
> snorre@diwala.io> wrote:
>
> 
> Cool work thanks for sharing.
> You can promote it as the Rolex of DIDs, there might be someone who is
> eager to have that 😅
>
> But all in all great that we continue to develop on new technology that is
> coming! That is the only way to move knowledge and become better in
> iterations!
>
> On Wed, May 3, 2023, 20:45 Brian Richter <brian@aviary.tech> wrote:
>
>> Thank you Markus, your feedback means a lot.
>>
>> I actually created the first did:btco last night. It only has a single
>> verification method and no service endpoint. As soon as it was mined, it
>> could quickly be found on any of the Ordinals explorers that have popped up
>> in the short few months that they have been around.
>>
>>
>> https://ordinals.com/inscription/432d87fab6285271c400fc375616f66dd13ee128a2e7811f5a72cd25c6966cddi0
>>
>> https://bioniq.io/inscription/432d87fab6285271c400fc375616f66dd13ee128a2e7811f5a72cd25c6966cddi0
>>
>> https://ordinalswallet.com/inscription/432d87fab6285271c400fc375616f66dd13ee128a2e7811f5a72cd25c6966cddi0
>>
>> https://magiceden.io/ordinals/item-details/432d87fab6285271c400fc375616f66dd13ee128a2e7811f5a72cd25c6966cddi0
>>
>> https://www.ordinalhub.com/inscription/432d87fab6285271c400fc375616f66dd13ee128a2e7811f5a72cd25c6966cddi0
>>
>> https://ordinals.hiro.so/inscription/432d87fab6285271c400fc375616f66dd13ee128a2e7811f5a72cd25c6966cddi0
>>
>> https://ordynals.com/inscription/432d87fab6285271c400fc375616f66dd13ee128a2e7811f5a72cd25c6966cddi0
>> https://ordiscan.com/inscription/3321042i0
>>
>> I inscribed this using the long form version as I am still working out
>> the specifics of the short form so it isn't the most cost effective. In a
>> relatively high fee environment (I paid 25 sat/vB) it cost me 10425
>> satoshis in fees which is roughly $3. For my next test I will include a
>> service endpoint and use whatever is decided for the short form. It's
>> important to note an Update operation will cost roughly the same.
>>
>> I'd love to present the method to the DIF ID working group to discuss the
>> technical implementation if you'll have me.
>>
>> Thanks,
>> Brian
>>
>> On Wed, May 3, 2023 at 9:40 AM Markus Sabadello <markus@danubetech.com>
>> wrote:
>>
>>> Brian,
>>>
>>> I really like this. I remember the did:btcr method, which was one of the
>>> first DID methods ever, and I always thought a method based only on
>>> Bitcoin could be very useful for certain use cases where you don't need
>>> a lot of DIDs.
>>>
>>> Yes, this approach is neither cheap nor scalable, but it's probably much
>>> more reliable than many other DID methods.
>>>
>>> did:btcr used TxRefs and OP_RETURN operations, whereas if I understand
>>> correctly did:btco uses ordinals and inscriptions.
>>>
>>> I don't really know anything about ordinals and inscriptions. :)
>>> How many Bitcoin transactions would you actually have to write, and how
>>> much would that cost, for let's say a "typical" DID document with one
>>> verification method and one service endpoint?
>>>
>>> Anyway, very interesting.
>>>
>>> Markus
>>>
>>>
>>>
>>>