Re: Potential Work Item: Blockchain-Links

Hey Melvin,

Thanks for the thoughts, I’m intrigued by RFC6920. I’ll give that a 
deeper look later today, but do you have any examples of how it might be 
applied to blocks & transactions here?

> How is the registry managed.  Who decides what the real 'mainnet' is?

My thoughts were similar to the DID registry here 
https://w3c-ccg.github.io/did-method-registry/. So far it does not seem 
as there’s any intentional naming collisions but it’s possible. The 
registry being moreso as a reference point and not something enforced. 
It’s possible that there could be an official blockchain Improvement 
Proposal that is the “owner” of a given blink chain, such as 
BIP/SLIP/EIP. That would reduce the possibilities of multiple 
‘bitcoin’ namespaces unless of course a fork.

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

Yeah, that’s a good point to make. With there being multiple 
blockchain deamon’s and many different api wrapper’s around them, it 
could difficult coming up with official rules around how to dereference 
a specific chain asset. Perhaps we can attempt to solve that in this. Of 
course again leaving it up to the blink chain creator.


Anthony



On 2 Apr 2020, at 12:53, Melvin Carvalho wrote:

> 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
>>