Maybe BTCR has registration backwards?

[msporny]

For whatever reason, this has been percolating in the back of my head over the past several weeks and I wanted to write it down before it disappeared again.

Perhaps BTCR has registration backwards? I'm sure I'm missing something, but...

The way Veres One works is you create/import the public/private Ed25519 keypair first, then sign a transaction, and send it to the ledger.

BTCR kinda does it in reverse, where you create a primordial DID document that doesn't have an identifier, anchor something to the Bitcoin chain pointing to an external document, and then create the final DID document.

The problem that this creates is this weird primordial DID document that doesn't have an identifier and then this complicated UTXO mechanism to crawl the UTXO spent/unspent transactions to get to the latest DID Document.

What if you just started w/ a did:btcr:ENCODED_PUBLIC_KEY, that is your DID. You can create your DID Document w/ that and sign the whole thing (putting the value in proof). So, at this point, you have a fully formed DID Document, that is digitally signed w/ the PRIVATE_KEY. It's valid, but not anchored in the Bitcoin blockchain yet.

Now, to anchor it in the public chain, you do a transaction w/ the PRIVATE_KEY, staking some Bitcoin and putting the URL (a hashlink, because you want cryptographic certainty) to where you publish your DID Document. You can then take that Satoshi Audit Trail and tack it on to your DID Document proof, meaning you now have two proofs. The first proof is a regular Secp256k1 signature on the DID Document, and the other proof is a SatoshiAuditTrail2019 proof on the DID Document. You verify the Secp256k1 using regular crypto. You verify the SatoshiAuditTrail2019 using that proof verification algorithm (get the transaction described by the proof, make sure it points back to the document you have, follow the UTXO stuff to discover any updates, etc.).

Have the BTCR folks considered this option before? It feels cleaner than what is being done right now (from my very limited knowledge of how BTCR works). I also haven't thought through the details, so there may be something lurking in here that's unworkable.

Thoughts?

[peacekeeper]

I believe the reason why the DID's method-specific identifier is an encoded TxRef rather than an encoded public key is that the latter would be very difficult to look up unless you index all the keys in the entire blockchain, whereas the TxRef points straight to the transaction you need for resolving the DID.

As a second comment, if you "take that Satoshi Audit Trail and tack it on to your DID Document proof" as you suggest, wouldn't that invalidate the hashlink in the transaction, but you can only construct the Satoshi Audit Trail after the transaction is accepted?

[ChristopherA]

On Fri, Aug 9, 2019 at 11:04 AM Manu Sporny notifications@github.com wrote:

What if you just started w/ a did:btcr:ENCODED_PUBLIC_KEY, that is your DID. You can create your DID Document w/ that and sign the whole thing (putting the value in proof). So, at this point, you have a fully formed DID Document, that is digitally signed w/ the PRIVATE_KEY. It's valid, but not anchored in the Bitcoin blockchain yet.

There are some other misinterpretations on how this works with Bitcoin in your writeup, but this is the biggest one. Bitcoin does not index public keys, and in fact, is only able to access them by extracting them from ECDSA signatures of legacy P2PKH keys, of which there are 4 possible private keys (in future upgrades like Schnoor signatures the public keys can not be extracted from the signature). We have to use txref to get around this, but we don't know what the txref will be until the block is confirmed.

I would like to do some version of BTCR for non-registered peers, along the lines of how the L2 Lightning Network works, but I'm not quite yet sure the best method. I see some things I like in the did:peer method that might be more like what you propose, but did:peer as written also a lot of sovrin'isms that don't fit well in the bitcoin ecosystem.

— Christopher Allen

[ChristopherA]

Brainstorming through what I think @msporny is thinking about, but integrating it with BTCR ideas, here are some thoughts. To be clear, I'm not proposing this as it has real serious problems. However, I want to demonstrate that I'm listening to Manu's idea and maybe someone will come up with something better.

The BTW method spec could define a special DID type which is a legacy P2PKH address, i.e. did:btcr:16k47uCffEkGkzX37d7Bt7mNnpzpu3hjvs — it is a bit long, but it is a base58 check of a hash(160) of a bitcoin public key. We'll call this variant of a "legacy" BTCR DID.

It is trivial to find out that there is no current UTXO on this address, and it has never been spent. Hundreds of bitcoin explorers exist that can be used to establish that, such as https://blockstream.info/address/16k47uCffEkGkzX37d7Bt7mNnpzpu3hjvs

If someone sent you a DID Document, you could validate the authentication public key defined in the document as matching the did:btcr:16k47uCffEkGkzX37d7Bt7mNnpzpu3hjvs by confirming the hash(160) of that address. You can also confirm that a private key does exist by verifying the signature of that DID Document matches the key, which matches the DID.

If a Verifiable Presentation was made with a VC issued by this DID, and the VP included as evidence the DID document itself, you can make some claims to the validity of that VC. If other VCs were presented at the same time from issuers you know, you might be willing to offer some trust to that VC and DID.

So far, we have replicated what a number of early decentralized CID systems offered, which is "peer" or "p2p" identifier, but using secp256k1 and an eclectic hash technique for the identifier. One major reason why didn't go with CID based systems is that they could not be updated, rotated or revoked.

The first thing we can do is use the bitcoin network to revoke the CID simply by using the private key in a way that the BTCR method knows is invalid. In addition, these CIDs could maybe be transitioned into full BTCR texref DIDs with all the update, rotate and revocation capabilities, making them potentially useful.

These could be the rules (which BTW don't work, see if you can spot the problem):

• If there no UTXO and thus no bitcoin transaction associated with the key, the key is considered valid to update the DID Document valid for any VCs signed by it, at whatever the level of trust this is good for (mostly cheap p2p levels of trust).

• If there is a valid UTXO for this address, and the first transaction that funded the address has a valid OP_RETURN in the DID Document, this could be a transition to a real BTCR DID. The transaction with the OP_RETURN pointing to a new DID document, and the address must NOT be the tip — instead, another output address must be the new tip. The OP_RETURN in the transaction must be a DID document that somehow lists the did:btcr:16k47uCffEkGkzX37d7Bt7mNnpzpu3hjvs as an alias for the DID for any old VCs using the legacy BTCR DID to be considered valid, and also the legacy BTCR DID's key must be listed as a valid key in the assertionMethod key list.

• Anything other than the above, the legacy BTCR DID is considered revoked, and all claims issued by it.

Some challenges:

• The reason this won't work is that anyone can spend coins to create a UTXO on this address, and once they do so there is a transaction. In fact, many people can do so. How hows does a resolver know which transaction to use for the transition? The above suggest the first transaction which will not work as it is easily denied with coin dust. You could say it must be the first transaction with an OP_RETURN but that is cheap also. You could put the a signed copy of the DID Document URL in the OP_RETURN, but that is too large for bitcoin. Manu suggest some type of hashlink in the bitcoin OP_RETURN that can be included in future DID Documents proof block, and just allow the P2P continue, but in that case why use bitcoin at all?

• If a DID Resolver is requested by an app to resolve the legacy BTCR VC or VP, that app must also provide what it thinks the DID Document is, or the DID Document has to be bound inside the VC or VP as evidence. The DID Resolver can either return back the legacy DID and report the legacy BTCR DID is non-revoked (no evidence of any presence of use of the key on the bitcoin blockchain), or tell the app there is a replacement DID (of the txref kind) but that the old legacy DID value is valid, or report that the DID is revoked. I'm not sure that is what @peacekeeper is thinking of in his design for DID resolvers.

• I'm not sure that there is precedet in DID resolver that it is sent one DID and returns a different DID but says that the first has some limited validity. I know there was some past attempts to have "alias" DID values expressed in DID documents. As I recall @christianlundkvist having real problems with alias DIDs.

• Using public key based P2PKH address is already a legacy architecture for bitcoin, superseded by PSH, then segwit, and soon schnorr. In all of those there is no public key-based addresses, however, @kallewoof has proposed in BIP-0322 a way for any bitcoin transaction to sign a message. The problem is, only bitcoin can validate signatures using this technique.

Maybe someone has a suggestion on how to solve these above challenges, but I at least wanted to share that I was taking Manu's ideas seriously.

-- Christopher Allen