Re: Potential Work Item: Blockchain-Links

> I wanted to get this out there as a potential work item that might
provide value to others in this space.

Thanks for the proposal Anthony, it looks like a good start. To officially
propose a new work item, please fill out the github work item template
(this pre-populates the necessary fields):
https://github.com/w3c-ccg/community/issues/new?assignees=ChristopherA%2C+jandrieu%2C+kimdhamilton&labels=proposed+work+items&template=ccg-new-work-item-template.md&title=%5BPROPOSED+WORK+ITEM%5D

On Fri, Apr 3, 2020 at 12:37 PM Kim Hamilton <kimdhamilton@gmail.com> wrote:

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