Re: Potential Work Item: Blockchain-Links

> I do really like this idea as well. Implementation wise, would that
mean that the resolver should look up that block, check the hash, and if
it’s not the same then return “not found” or “invalid chain”? Or if the
resolver really is keeping track of multiple chain splits, checking
block height against that split?

Yes exactly, that was the idea! We haven't actually tried to implement
it however..

Markus

On 4/3/20 6:11 PM, Anthony Ronning wrote:
>
> Hey Markus,
>
>     bech32bis-encoded TxRefs
>
> Yeah I think that’s definitely in the realm of possibilities! Is that
> specifically for just transactions? And does TxRefs rely on block
> height? I see the note for BIP0136 saying “TxRef's should be not used
> for positions within the blockchain having a maturity less than 100
> blocks”, which may be problematic.
>
> All good points to bring up though, at least for a bitcoin specific blink.
>
>     did:btcr:xz35-jznz-q6mr-7q6;btcr:block-123456=ae676e00
>
> I do really like this idea as well. Implementation wise, would that
> mean that the resolver should look up that block, check the hash, and
> if it’s not the same then return “not found” or “invalid chain”? Or if
> the resolver really is keeping track of multiple chain splits,
> checking block height against that split?
>
> In general after a short period of time, forks naturally seem to
> either die (in the case of orphans) or get renamed. I’d imagine that
> in the case of bitcoin cash, a DID called |did:btcr-cash| would be
> created as well.
>
> While I think some of this could be considered chain-specific, I do
> think getting some common generic parameters and best practices like
> the DID spec has is a great starting point as well.
>
> Anthony
>
> On 3 Apr 2020, at 5:35, Markus Sabadello 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.
>
>     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
>>
>
-- 

all the best,
Markus Sabadello
Danube Tech ~ danubetech.com
Sovrin Foundation * sovrin.org
+43 664 3154848