kimdhamilton
commented
7 years ago From @ChristopherA on July 9, 2017 23:18
@veleslavs I was going to add an issue to your BIP proposal at https://github.com/veleslavs/bips/blob/Bech32_Encoded_TxRef/bip-XXXX-Bech32_Encoded_Transaction_Postion_References.mediawiki but issues are not allowed there.
What I wanted to propose was that you move the tx1- completely out of that BIP, and instead move it to you other BIP at https://github.com/veleslavs/bips/blob/wip/bip-XXXX-Revocable_Public_Key_Enrolment_Transaction_with_Optional_Cost.mediawiki
The reasoning is that there may be many uses for the bech32 chain+block+index besides for identity, and they may want a different prefix. I'd love to just be able to reference a chain+block+index BIP.
In addition, I'd like to propose in your ID BIP that you change it from tx1- to did:tx1: — this allows it to be a fully conforming W3C URN (Universal Resource Number) that makes for compatibility with other URN and URL tools.
If you open the issues in both of those, I'd be glad to propose them there. If there is another communication channel you'd prefer me to use to post those requests, let me know.
From @ChristopherA on July 9, 2017 23:11
I've come to the realization that both @veleslavs & @jonasschnelli's proposal at #24 and the original DID:BTCR proposal are all basically different methods, which the top level DID spec specifically encourages and supports.
If we do one for Lightcoin as well (LTCR? TX2?) and if Blockstack (BLST? cc: @muneeb-ali @shea256 ) also joins us, this means that we could all use the common bech32 encoding for our Decentralized IDentifiers.
Thinking through this further, this has some consequences on our design.
First, we've been proposing so far a DID that looks like my test DID of did:btcr:tx1-xxyv-xxxx-fpmf-u0 — however, in fact, we don't need the tx1 prefix as that is actually a method designator. So it could be shorter and thus
did:btcr:xxyv-xxxx-fpmf-u0, and @jonasschnelli DID would bedid:tx1:rk63-uvxf-9pqc-sy— both would be W3C conforming URNs and valid DIDs.However, this is another level of redundancy that we could consider. The bech32 encoding (see #2) actually has 'magic bytes' in it that signify the chain. In my case
xxyv-xxxx-fpmf-u0the firstxtells us to look for the transaction on the bitcoin testnet, and in @jonasschnelli's caserk63-uvxf-9pqc-sythe firstrtells us to look at the bitcoin main chain. Future magic numbers could tell us to look at a fork of the bitcoin main chain (hopefully none of those happen!), at a lightcoin chain, a sidechain, etc.This leads to the possibility is that it could be instead be used as a submethod identifier —
randxare for the tx1 style DIDs on main chain and testnet, new magic codes forsandycould be for btcr style DIDs on main chain and testnet, and some other values could be for lightcoin or used for Blockstack's proposal.f we can agree to a common root method spec, supporting all the variants, this could be useful. It does mean that there is a centralization of assignment of the magic codes, but that is also true for DID methods (for which we at least use the W3C process).
The disadvantage of combining is that anyone with a fifth idea or future idea would have a harder time getting a new submethod proposal once a joint proposal was publish. The advantage to everyone having a different DID method identifier is that they all can compete in the marketplace of ideas freely as anyone can propose a DID method. Of course we can also leave the differences between all these variants as separate but open submethod specs ;-)
For now I suggest we keep them as separate method specs, and help @veleslavs & @jonasschnelli create a parallel TX1 DID spec conforming to the W3C process with their BIP proposal. We can discuss if there are sufficient commonalities that it makes sense to go into creating submethod specs for the differences.
Copied from original issue: WebOfTrustInfo/btcr-hackathon#26