Recipient bitcoin address for identity only, not transaction destination?

Technical
1

A few questions about how bitcoin addresses are used in blockcerts:

So I think bitcoin addresses are used in blockcerts in three ways (and maybe also a fourth - for revocations):

  1. Payment. The issuer creates a bitcoin address (outside of blockcerts), and transfers enough money to the address to pay for the bitcoin transaction that logs the merkle root in the bitcoin blockchain. I think (based on the tutorial in the cert-issuer README (https://github.com/blockchain-certificates/cert-issuer/blob/master/README.md) that this same bitcoin address is also used to identify the issuer (by embedding the address in the certificate), as well as to sign the certificate (more specifically, using the private key that backs the address), as described further below.

  2. Identification. Bitcoin addresses are used as public keys with which to identify the:

    a) recipient - the recipient’s blockcerts wallet generates a bitcoin address and sends it to the issuer (to the ‘introduction’ endpoint). The issuer embeds this address into the certificate for the recipient. Because the recipient owns the key pair that generated the bitcoin address (in that the bitcoin address is a hash of the public key part of the key pair), the recipient can use the private part of that key pair to prove that the bitcoin address, and so also the certificate, is theirs. QUESTION: Are all the bitcoin addresses for the certificate recipients (in a batch) also listed as recipients of the bitcoin transaction (the transaction that logs the merkle root for the batch)? Or was this how an earlier version of blockcerts worked, and the recipients’ bitcoin addresses are no longer used as recipients of the bitcoin transaction, and are only used for identification (in which case any public key would do, not just a bitcoin address?) Are any bitcoin addresses listed as recipients for the bitcoin transaction?

    b) issuer - the issuer embeds their bitcoin address (QUESTION: is this in fact the same address that was used to pay for the transaction?) into the certificate, just as the issuer embedded the recipient’s bitcoin address into the certificate. The issuer’s bitcoin address is also published publicly somehow (I think in the ‘issuer identify json’ endpoint like this example: https://www.blockcerts.org/samples/2.0/issuer-testnet.json under the ‘publicKey’ property. As an aside, I assume that since the publicKey property is an array, multiple public keys can be listed?). Because the issuer’s key is publicly available at a known/verified url, it can be (is?) used in the verification process to confirm that the key is actually owned by the university (i.e, to prove identity of the issuer, I think?).

  3. Signing - The private key associated with the issuers bitcoin address (again, the same bitcoin address used for payment and for identification) is used to digitally sign the certificate (by encrypting the hash of the certificate).

  4. Revocation - There is a command line utility in the blockcerts cert-utils to generate bitcoin addresses to be somehow used with revocation lists. I don’t, though, see how that would work with the revocation list endpoint. But, maybe using bitcoin transactions for revocation is an older approach (which seems likely, given what Kim says here:

In summary, there seem to be two bitcoin addresses in play: that of the recipient (assuming one recipient, but as many more addresses as there are recipients for a batch of certificates) and that of the issuer. The recipient’s address is used for one purpose: to identify the recipient by embedding the address in the certificate. The issuer’s address serves three purposes: to identify the issuer by embedding the address in the certificate, to sign the certificate, and to pay for the bitcoin transaction.

Have I got this mostly right?

Many thanks,

James

1 Like
2

Yeah, you’re pretty much right on with that. Although we no longer use bitcoin addresses for revocations, it’s now a URL on an issuer profile.

So currently 1, 2, and 3 apply. 2 addresses, one for issuer and one for recipient per each certificate.

And yes, the same issuer address that pays for the transaction is the one that should be in the certificate and issuer profile.

3

Great - thank you.

Does the bitcoin transaction that logs the merkle root list any recipients (on the bitcoin transaction)? If not, then the recipient’s public key doesn’t necessarily have to be a bitcoin address? A recipient might have their own key pair, say RSA (rather than ECDSA), and could give the public key part of that to the issuer?

Or is that the blockcerts wallet assumes that the recipient’s public key is a bitcoin address when verifying that the recipient owns the public key (and hence owns the certificate)? And since a bitcoin address is a hash of the public key, there is probably a slightly different process for verifying that the hash of the public key (i.e, the bitcoin address) matches the private key, than if verifying that an unhashed public key (e.g. RSA) matches the private key?

1 Like
4

Sorry for the late reply.

The bitcoin transaction does not list any of the recipients, and technically, the blockcerts file has the option for different key pairs. If you look at one of the sample certificates, it includes this entry for recipient public key:

"publicKey": "ecdsa-koblitz-pubkey:1QBiZ94RQ5iyGW2m8TDoaEmKohQzAjVWkH"

Not quiet sure where that identifier comes into play, but I’d assume you could stick any recognizable key type into that.

However, the blockcerts mobile wallet uses the recipient’s bitcoin public key as the key transmitted to issuers when they “Add Issuers”. Currently there is no cross signing or verifying that the recipient owns any certificate in their mobile wallet.