Re: Potential Work Item: Blockchain-Links

On Fri, 3 Apr 2020 at 12:37, Markus Sabadello <markus@danubetech.com> wrote:

> 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:
>
> blink:bitcoin:mainnet:000000000000000000010382095b5308881ddf0902b59d0328a1401548383c5a:d7a008c9f9eab701132d394410f4e9d578790fb41848013fc5ba35951acdca24
>
> Could also be expresses as follows to be consistent with BTCR DIDs (it's
> much shorter):
> blink:bitcoin:rzv7-ypyq-q5n6-7v9
>
> 2. In DID Resolution, we also came across the question how you handle
> forks, e.g. see this issue:
> https://github.com/w3c-ccg/did-resolution/issues/43
>
> One idea we had was that you could include a parameter in a DID URL that
> indicates which fork you want, e.g.:
> did:btcr:xz35-jznz-q6mr-7q6;fork=3
>
> ... 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.:
> did:btcr:xz35-jznz-q6mr-7q6;btcr:block-123456=ae676e00
>
> ... to identify the fork which has block hash ae676e00 at block height
> 123456.
>

That is pretty cool!

But alas it still doesnt map to say mainnet, because it could be orphaned

In fact mainnet isnt really defined except for longest chain wins

Ultimately what you are doing then is providing a chain of check points in
a URI

But even that can be forked, depending on the block chain structure.


> all the best,
> Markus
> 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.
>
> 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.
>
> 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
>
>
>