Re: Potential Work Item: Blockchain-Links

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

This is because you need the block height/position of a confirmed
transaction. Degree of confidence in transaction confirmation should be
part of your consideration no matter how it's encoded

On Fri, Apr 3, 2020 at 9:14 AM Anthony Ronning <aronning@learningmachine.com>
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
>
>
>