W3C home > Mailing lists > Public > public-credentials@w3.org > April 2020

Re: Potential Work Item: Blockchain-Links

From: Markus Sabadello <markus@danubetech.com>
Date: Fri, 3 Apr 2020 12:35:19 +0200
To: Anthony Ronning <aronning@learningmachine.com>, public-credentials@w3.org
Message-ID: <292edc3b-4a2c-b9aa-b9ad-7d3233f17805@danubetech.com>
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.

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
>
Received on Friday, 3 April 2020 10:35:36 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:24:58 UTC