- 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