Topic: Pay to website certificate / public key (Read 969 times)

I have made a proposal for this before.  I was under the impression that the Payment Protocol could be extended for this.  Better yet, BIP 32 is technically already capable of executing this process.  At the moment, I'll be working with individual merchants to implement this, though I'd love to have it be more widely accepted.


Functionality:

-- Merchant has root public key that is truly public (but the chaincode is not).  
-- Whenever a merchant gives you an address, they give you the root key and the multiplier/tweak along with the address
-- The client verifies the public key provided matches the known value for the merchant
-- The client software will multiply the root public key by the tweak and confirm they get the same payment  pubkey/address
-- Client software provably knows that the address belongs to the merchant's wallet
-- There's no way for the client to see any other addresses in the merchant's wallet without the chaincode that goes with the root public key

Similarly, you can have:

-- Customer creates a new BIP 32 wallet
-- Customer opens an account on the merchant website
-- Customer makes a deposit, of which the first input address is X
-- Customer software will supply the service with the root key and multiplier that produces X
-- Merchant will store the root public key(s) in the customer account/metadata
-- On a withdrawal, the customer software will send the address, along with the multiplier
-- The merchant software can verify that the address belongs to the same wallet as X
-- If the wallet is different (or do not supply that info), then the merchant will use extra authentication techniques.


How does it work?  All BIP 32 chains have a root public key and chaincode.  To get a particular address, you do mangle the key and chaincode with the address index to get a multiplier.  Knowing the multiplier does not allow you to backtrack the chain code.  But it does allow you to prove that the address is related to a given root public key.

In this way, merchants with persistent business relationships, or customers accessing well-known websites will pre-verify the merchant public key, and then can prove that all payment addresses belong to that actual wallet (which could be an offline wallet of the merchant, doesn't really matter).  Similarly, if the customer uses the same set of wallets persistently, the merchant at least knows that there's a recognized wallet being provided for withdrawal/payment.  Of course, they don't know if that wallet is compromised, but it still adds an extra layer of security.

The root public keys could easily be distributed via SSL/CA mechanisms.  It would then be a very simple addition to the payment protocol -- only requiring a couple extra fields to be transmitted with the addresses.  On the other hand, you can also exchange and verify root public keys manually and sidestep all the SSL/CA stuff.

This is extremely powerful, and I hope to see some adoption of this technique, though I suspect Armory will be the first, and will have to demosntrate its power before other really believe/understand it.

Yes. Regular bitcoin-qt or SPV wallets don't have such an index.

What do you mean Mike? According to https://en.bitcoin.it/wiki/Private_key, sweeping means:


Why would this require rebuilding indexes? Is that because the wallet would need to get a list of all the unspent outputs that are associated to that private key?

Most bitcoin software doesn't support sweeping of private keys (because it involves building large and expensive database indexes).

I haven't said I do not trust SSL or the payment protocol, I just described a way to pay someone when you only have their certificate (this could be a business or a person). They wouldn't have to create a Bitcoin address or do anything else, you could send them BTC and make sure that only the holder of the private key that corresponds to that certificate can redeem it.

If you trust SSL, why don't you trust SSL to protect the payment request message?

Hello everyone,

I was thinking about how a client could send a payment on a website and make sure that only the owner of that website can redeem it. The Payment Protocol (if implemented) is one option, but here's a crazy idea:

1. Payer generates a new Bitcoin private key and assembles a transaction that pays the amount he wants to pay to the corresponding public key.
2. Payer fetches the SSL certificate of the website, verifies its validity, then takes the private key it has generated and encrypts it with the public key of the website.
3. This encrypted private key is then attached to the transaction (using unspendable outputs or other similar techniques - if the site uses RSA-2048, it will not fit into the 80 bytes that Bitcoin will allow for additional data per transaction)

At a later time, the website owner uses his website's private key to decrypt the message containing the private key of the transaction, then sweeps the funds to his wallet. He still needs to wait for the transaction to confirm (since the sender might try to cheat and spend it again given that he also has the private key). But I think this would be an interesting way to pay to someone's X.509 certificate (that is "I agree to pay X BTC to whoever this certificate describes"), even in the absence of a destination Bitcoin address.

Ideas?