Standard protocol for Bitcoin/SSL content verification

[earonesty]

As a merchant, I'd like to provide some assurance to my customers that the wallet address I'm signing with is one linked to my domain, in an irrevocable manner.

Currently, the merchant hosts an ssl connection, the customer typically sees a random, sometimes even recycled, address to send to.  

For assurance, the merchant may sign a message with order information : "Order# 4456 Address: 1N57686... Amount: 1.56 BTC", or something like that.  For that signature, the merchant will used a published address, typically one on his home page, or a donation page, and/or one associated with these forums.

This is great!  Because the customer can come along and prove that the merchant signed that message, and prove he sent the BTC to that address, etc.  

But suppose the merchant didn't post that public signing address anywhere? Do customers have to check archive.org first, to ensure the merchant's home page is in the cache with the donation address?   Or worse, bitcoinforums (yes, that's the standard these days).

Who's to say a particular address is associated with a particular site? 

And of course a customer can always create a wallet, stick a url in it, sign it and "swear it was on the merchant's site".

This is all silly, and we can have a standard, and SSL URI's are the right way to go:

a) publish a message at (https://) URL, can contain anything
b) client reads that, stores the results in his wallet
c) client sends a "verify transaction" consisting of a {SHA256(url+contents)} + bounty per verification + # of verifications requested
d) peers can accept the "verify transaction", verify that ssl url contents hash as stated, obtain the bounty, and publishing the signed {SHA256(url+contents)} message in the bitcoin block chain as a transaction from their address along with 50% of the bounty as a transaction fee.

At the end of the day, miners participating in verification get paid for verification services.  Customers can get assurance that verification is irrevocable.

Something like that...not terribly well thought out.  But something.

But here's the thing....I think it really should be built-in to bitcoin.   It could, of course, work as an "other coin".  

If even 10% of the miners upgraded, a customer could pay for URL content verification and get a response within a few minutes.  It won't be on the blockchain in a few minutes, sure.  But it will propagate fast, and block-chain confirmation would only be needed for a lawsuit later... not for a "confirmation now".

(Note: it could be used to "confirm content" of any kind, enabling interesting new uses)

[1715459484]

1715459484

[1715459484]

1715459484

[earonesty]

Encode these verifications in the existing blockchain. 

- Set the private key of an address to a the hash of the (url+thumbprint+content) you want to verify. 
- Send the url + public key to anyone that supports the new protocol
- Load that address with the bounty amount
- That peer then verifies the content by downloading, hashing and transferring out the BTC from the public key
- The existence of that transaction verifies the content because it's nearly impossible for someone to "guess" that combination of url+thumbprint+content without actually downloading the claimed content

You then have the ability to prove that the content was downloaded from the SSL-encrypted site in question, since it's unlikely that you'd be able to guess that hash. You can also show that there were transactions moving money out of the bounty accounts. 

These transactions demonstrate that the remote peers also were able to compute the same hash from the same content

[gmaxwell]

Encode these verifications in the existing blockchain.  

Encoding 'in the blockchain' is pretty much the absolute last thing you want to do for pretty much any question.

What you're describing also has the bad property that you can't prove the connection without disclosing the private key.

It also suffers from bad key management since coins will be assigned to non-backed up ephemeral keys which could be loss.

It also doesn't create strong evidence that the receiver of the coins actually knew of their existence... e.g. I fail to give you the private key, then I spend the coins myself, then I say you didn't live up to your side of a contract you never saw.

There are proposals for pay to contract which are much better, but they still have the data integrity issues.

The payment protocol supports x509 signing for non-repudiation of invoices, which is I think mostly what the OP wanted.

[Mike Hearn]

As a merchant, I'd like to provide some assurance to my customers that the wallet address I'm signing with is one linked to my domain, in an irrevocable manner.

Good to hear it! As Gregory points out, this upgrade has already happened. The design work was done end of 2012/2013 and implementations of BIP 70 are about to ship. Please do start vending signed payment requests when wallets begin supporting it! In fact, you could start work on coding it up now, and test against Bitcoin Core built from git master.

[earonesty]

Of course, a direct x509 signing of invoices/contracts along with the payment addresses and amount would work fine.  If you don't have the actual invoice/contract signed with an identity-bearing cert, then there's no point.  

Looking forward to some sort of widespread adoption of this.  

Important features would include the ability to encode something into the bitcoin URI enabling the merchant to link an x509 invoice with a payment request.

Something like this:

bitcoin:<addr>?amount=X&invoice=<encoded-uri-for-signed-invoice-or-contract>

That would enable the customer to both a) confirm the invoice and b) retain the invoice and signature for repudiation

NOTE: Without including URI support the feature is not going to be broadly adopted.

[earonesty]

Well, all you needed to do was point me here:

https://bitcointalk.org/index.php?topic=300809.0

That handles pretty much everything, including the request URI, signatures, etc.

Didn't know about it.

That payment system is going to be huge.