Blind Transactions

[ffe]

Today it is possible to trace the flow of bitcoin using the blockchain. This forms a graph with the nodes labeled by public keys. At various nodes some of these public keys get associated with real life identities, maybe because the recipient publishes it on a website for example. This is bad if you don’t want your identity as the sender tied to the identity of the recipient.

It would be nice if a sender can create a transaction sending to a recipient by sending to a “blinded” public key that cannot be linked to the recipient but that only the recipient can receive and spend.

The following scheme allows for blind transactions and has been described in the past. I’m repeating it in slightly altered form. It involves no changes to the protocol or the block chain. The client would have to have added capability however.

The receiver signals his willingness to receive blinded transaction by publishing a full public key rather than a shortened hash of one as is the norm today. The idea is that the sender recognizes the full public key as a blindable key, not a vanilla receiving key.  When this happens, the sender generates a new, unique, public key from the receiver's public key and sends bitcoins to that new public key.  The sender cannot generate the corresponding private key.  Only the receiver can generate the private key (the new private key is derived from his secret key as described below).  So only the receiver can later spend those coins.  Furthermore, no one but the sender and receiver know that the transaction belongs to the receiver.

This is how you implement blinded keys:

Assume Alice owns a key she wants to receive blinded transactions on. Let "a" be the private key.  The public key is "A" (A = aQ where Q is the basis point in the curve).  A is published by Alice.  Also, let Bob have coins under a public key "Y" so the bitcoin block chain has a transaction transferring coins to "Y" and Bob has the private key, "y", corresponding to "Y".

Bob wants to send some coins to Alice anonymously. He does NOT want his "Y" associated with "A". He looks up "A" and and uses his client to generate a new key for "A". Remember "A" is the full public key. Bob's client knows about blindable keys and it generates a public key "X" from "A", "y", and "m" ("m" is randomness derived from parts of the transaction that transfers the coins).  "X" has the property that only Alice can derive the private key "x" and only Bob knows that Alice owns "X". Alice can spend the coins in "X" by generating "x" and using it to sign a transaction spending the coins at some future time.

Bob generates "X" as follows:  s = Hash(m,yA);  X = sA.  Note yA and sA are cryptographic multiplies in ECC. Also note, only Bob and Alice can generate "s" which is a Diffie Hellmann shared secret between them.  Also, Bob cannot generate the private part of "X" but he can transfer coins to the public "X".

Alice generates "x", the private part of "X", as follows:  She obtains m and Y from the transaction; then  s = Hash(m,aY);  x = sa (modulo a large prime determined by the ECC);  She can check that X = xQ.  Note, yA = aY and only Bob and Alice can calculate them. Also, "X" is derived from "A" but no one can prove Alice is the owner of "X" since only Alice and Bob know "s".

"m" is chosen so that no two transactions produce the same "s". Hence "X" will always be unique to that transaction. "m" would be a few bytes from the transaction that are unique to the transaction but are not dependent on "X", the receiving key in the transaction.

A client holding "A" would have to check every new transaction for the property that s = Hash(m,aY) and X = sA to know to add the coins to the balance in the wallet.

[1714958511]

1714958511

[1714958511]

1714958511

[1714958511]

1714958511

[1714958511]

1714958511

[wumpus]

Interesting idea, following this thread.

A client holding "A" would have to check every new transaction for the property that s = Hash(m,aY) and X = sA to know to add the coins to the balance in the wallet.

That sounds like effectively a brute force, and the bottleneck in this scheme? Or not?

[ffe]

An issue with blinded transactions is that a network-facing server at a business allowing blinded transactions needs to verify payments and with the scheme above this requires knowledge of the secret key “a”. (Used in the check of every new transaction for the property that s = Hash(m,aY) and X = sA).

This added note is to show how Alice allows a server fronting her business to verify that she owns a blinded transaction without requiring the server to have her secret key thus protecting her wallet if the server is hacked.

It’s done this way:

Alice generates a secondary key used to verify blinded transactions from her master key. Her private key is “a”. She generates a verifier private part “b” by hashing “a”,  b = Hash(a). Let the public part of “a” be “A” and the public part of “b” be “B”.   A = aQ and B = bQ. The doublet “A,B” is published as the blind transaction enabling public key. “A,B” and the private verifier “b” are given to the server she is using to manage monitoring the block chain for her. With “b” the server can verify transaction ownership but not spend. Hacking the server does not give you “a”.

A sender would recognize “A,B” as a blindable key. The sender then generates "X" as follows:  s = Hash(m,yB);  X = sA. The sender sends coin to “X”.

A server holding verifier "b" can check every new transaction for the property that s = Hash(m,bY) and X = sA to know to add the coins to the balance in Alice’s wallet. (Note yB = bY). Notice that the server does not need “a” to verify the transaction. The server can verify “X” but cannot generate the private part of “X”.

Alice later generates "x", the private part of "X", as follows:  She is given m and Y from the transaction; then  s = Hash(m,bY);  x = sa (modulo a large prime determined by the ECC);  She can check that X = xQ. Alice can now sign a prepared transaction using “x” and publish the signed transaction when spending.

[ffe]

Interesting idea, following this thread.

A client holding "A" would have to check every new transaction for the property that s = Hash(m,aY) and X = sA to know to add the coins to the balance in the wallet.

That sounds like effectively a brute force, and the bottleneck in this scheme? Or not?

It's more expensive than the current check but very do-able with today's servers. This will only get easier as processing power improves. 

[Zeilap]

I don't see how this provides any more privacy than Alice simply creating a new address herself for each transaction. The difference being that your scheme allows for Bob to send without contacting Alice to get a fresh address, but what's the use case where you send coins to someone you've never contacted?

There is also the trust issue - if Alice doesn't really care about your privacy she might spend some of her coins together, associating her various blinded addresses with each other. Your payment links your address with an address which now is seen to be belonging to Alice, defeating the whole purpose.

[ffe]

I don't see how this provides any more privacy than Alice simply creating a new address herself for each transaction. The difference being that your scheme allows for Bob to send without contacting Alice to get a fresh address, but what's the use case where you send coins to someone you've never contacted?

There is also the trust issue - if Alice doesn't really care about your privacy she might spend some of her coins together, associating her various blinded addresses with each other. Your payment links your address with an address which now is seen to be belonging to Alice, defeating the whole purpose.

I agree this does not provide more privacy than an offline transfer of an address generated by Alice on some private machine. It is better than Alice emailing Bob an address or Bob going to Alice's web site for a new address which leaves a trace online.

I also agree you have to trust Alice. At a more basic level, Alice knows your key "Y" and if she publishes a nice "Thank You Y" on her web site you're linked...

A contrived use case might be anonymous bidding where Bob is sending earnest money to Alice implying a bid on something but absolutely not wanting his competitors to know he is bidding. Alice would hold off spending until the bidding is over and a winner is announced. Alice has a strong incentive to honor anonymity or she scares away bidders.

Another use case might be Bob time stamping a contract by creating a transaction whose target address "y" is the hash of a contract (sending a tiny amount of money to "Y") yet not wanting to reveal to the world his connection to the contract until a later date.  At a later date, by revealing "y" he can prove his earlier commitment to the contract.

But you're right. It's just a toy from the point of view of normal transactions.

[wheatstone]

My first thought was exactly what Zeilap wrote; this scheme only adds complexity to something easily accomplished already.

A contrived use case might be anonymous bidding where Bob is sending earnest money to Alice implying a bid on something but absolutely not wanting his competitors to know he is bidding. Alice would hold off spending until the bidding is over and a winner is announced. Alice has a strong incentive to honor anonymity or she scares away bidders.

Another use case might be Bob time stamping a contract by creating a transaction whose target address "y" is the hash of a contract (sending a tiny amount of money to "Y") yet not wanting to reveal to the world his connection to the contract until a later date.  At a later date, by revealing "y" he can prove his earlier commitment to the contract.

#2 would seem to not require the use of your scheme at all, unless I'm missing something.

#1 I simply don't understand. Why would any bidder send coins to a public key controlled by Alice until the auction is over and the bid has been won?

The bidding scenario is certainly an interesting one, but would seem to be better covered by a "minimal trust escrow" contract, cf. Mike Hearn's article on Contracts on the wiki (here) and BIP 11 by Gavin (here).