Re: Potential Work Item: Blockchain-Links

Looks interesting! Two thoughts:

1. In the case of Bitcoin specifically, would it make sense for Blinks
to use the same format that BTCR DIDs are using as their
method-specific-id, i.e. bech32bis-encoded TxRefs?

In other words, your example:

Could also be expresses as follows to be consistent with BTCR DIDs (it's
much shorter):

2. In DID Resolution, we also came across the question how you handle
forks, e.g. see this issue:

One idea we had was that you could include a parameter in a DID URL that
indicates which fork you want, e.g.:

... to identify "fork 3" of Bitcoin mainnet.

But how can you agree what "fork 3" means?

A better idea may be to include one or more parameters that state the
expected hash of a certain block (which would unambiguously identify a
certain fork), e.g.:

... to identify the fork which has block hash ae676e00 at block height

all the best,

On 4/2/20 7:22 PM, Anthony Ronning wrote:
> Hello all,
> I wanted to get this out there as a potential work item that might
> provide value to others in this space. Blockchain-Links, aka Blinks,
> as a way to reference blockchain/dlt data in a URI format.
> Example:
> |blink:bitcoin:mainnet:000000000000000000010382095b5308881ddf0902b59d0328a1401548383c5a:d7a008c9f9eab701132d394410f4e9d578790fb41848013fc5ba35951acdca24|
> Manu had suggested the idea of using this concept for MerkleProof2019
> ( so that we could
> minimize the size of |proofValue| using CBOR encoding. This also opens
> up the possibility of referencing transactions in fields that are
> restricted to URI’s. From my experience, referencing blockchain
> transactions had typically been reserved for JSON or are done so in
> blockchain-specific ways.
> The initial draft is an attempt to get the idea out there and adapt on
> it as needed. The idea is to take a similar approach to DID’s (as far
> as the DID URI goes) such that the |blink:chain-name| parameters can
> be specialized per blockchain or blink chain creator. It may be
> beneficial to have a registry of existing blink chains.
> Some other considerations that might be useful to think through are:
> - Hard forks
> - Query/command parameters
> - Other possible examples of defining the most common chains such as
> bitcoin and ethereum.
> Any thoughts would be appreciated!
> Anthony Ronning
> Learning Machine / Hyland Credentials

Received on Friday, 3 April 2020 10:35:36 UTC