Re: Potential Work Item: Blockchain-Links

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