Attach and persist identity to address

Question

With Bitcoin, you can sign messages to prove that you are in possession of a private key associated to a public key. Correct me if I'm wrong, but from my understanding this only works with a separate communication channel, such as email or a central system where you request the other system participant to sign the message for you.

I think this works great if you want to confirm a shipping address in order to make sure the person who paid is aware of where the shipment goes (if you want to accept the fact that everyone in the network can see your shipping address).

But does that work for a notary use case, for example? How can you know, using Bitcoin message signing, that the company "AMCE Ltd." is actually behind the address "XYZ"? Is this only possible if you actually call AMCE Ltd. or email them for them to sign a message for you? What if you can not trust the communication channel (e.g. message gets intercepted by a potential attacker).

The only thing I can think of that can solve the problem is introduce a middlemen you are required to trust (from what I understand, Onename.com is such a middleman) and who does the background check for you. But from my understanding, this would eliminate a significant part of the value of Blockchain. Why would you need a distributed ledger anyways if you already trust the middleman?

Answer 1

I think this works great if you want to confirm a shipping address in order to make sure the person who paid is aware of where the shipment goes (if you want to accept the fact that everyone in the network can see your shipping address).

You can embed an shipping address into the blockchain using OP_RETURN or something similar, but a much simpler way is to sign your shipping address using your bitcoin address, and send that via a private channel.

But does that work for a notary use case, for example? How can you know, using Bitcoin message signing, that the company "AMCE Ltd." is actually behind the address "XYZ"? Is this only possible if you actually call AMCE Ltd. or email them for them to sign a message for you? What if you can not trust the communication channel (e.g. message gets intercepted by a potential attacker).

You need some sort of trusted communication channel to send an address. If you do not have one, most methods of starting one (like SSL) involve some kind of trusted third party.

But that's not unique to Bitcoin, of course. There's a huge problem with fake, nonexistant businesses on Google Maps. In order to create a naming system that resists tampering and fraud, you must have 1) some system to detect and remove fakes, and that system must work consistently and 2) some way of punishing people who create fakes.

Why would you need a distributed ledger anyways if you already trust the middleman?

One reason is that there are different kinds of trust in play. For example, I trust Comodo to verify SSL certificates before signing them, but I don't trust them to hold any of my personal data. I trust my bank to route payments to the correct recipient, but I don't trust them to not charge me an inactivity fee.

Answer 2

One idea that I came up with is to have every node in the network expose a "sign" endpoint. Something like:

Request:

GET https://acme.com/sign?message=randomText&address=Ajd45...

Response:

{
    "address": "Ajd45...",
    "message": "randomText",
    "signature": "..."
}

Using this data, one can verify that the owner of the DNS acme.com has the possession of the private key. The only thing you need to make sure that the server behind acme.com is actually owned by Acme.