Re: Potential Work Item: Blockchain-Links

On Thu, 2 Apr 2020 at 19:23, Anthony Ronning <aronning@learningmachine.com>
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.
>
> https://www.blockcerts.org/blockchain-links/
>
> Example:
>
>
> blink:bitcoin:mainnet:000000000000000000010382095b5308881ddf0902b59d0328a1401548383c5a:d7a008c9f9eab701132d394410f4e9d578790fb41848013fc5ba35951acdca24
>
> Manu had suggested the idea of using this concept for MerkleProof2019 (
> https://w3c-dvcg.github.io/lds-merkle-proof-2019/) 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.
>
Not a bad idea.  It seems quite well thought out.

> Some other considerations that might be useful to think through are:
> - Hard forks
>
This is an issue.  For example, there are 3 testnets on bitcoin.  There are
also version numbers, which could change.  How is the registry managed.
Who decides what the real 'mainnet' is?

> - Query/command parameters
> - Other possible examples of defining the most common chains such as
> bitcoin and ethereum.
>
> Any thoughts would be appreciated!
>

The main problem I see with this is that there's no way to dereference the
the blink URI

Some years ago I came up with a system using RFC 6920 [1] which names
hashes.  That has the advantage of being standardized already and provides
a mechanism to derefernece the block header id, or tx and get more
information, similar to a block chain.  That info can include the a bunch
of information about which net it uses, version, chain and is extensible,
and I think could perhaps cover this use case already, unless ive missed
something

[1] https://tools.ietf.org/html/rfc6920


> Anthony Ronning
> Learning Machine / Hyland Credentials
>