Quote from: JoelKatz on July 04, 2011, 11:17:46 PM

A block only comes in every ten minutes. And you don't need as many local accounts. But let's take the worst case reasonable scenario -- you have 20 local accounts and a block comes in with 500 transaction outputs. That would require 10,000 decrypts followed by 10,000 public key to private key transformations. That would take a typical modern PC about 15 seconds, using a single core. The operation could intentionally be spread over a longer period of time to reduce the load burst.

If you think this is a problem, a simple change will solve it. Leak one byte of the public key into the primary and secondary transaction keys. That would mean you only had to check accounts whose public key matched the leaked byte. This would reduce anonymity a bit (the transaction outputs that might be going to a particular account would now be only 1/256th of all the transaction outputs), but would reduce this computation load by a factor of 256.

I really like your idea, giving every transaction its own key and obfuscating the receiving addresses like this is ingenious.

It would seem to complicate the problem of having lightweight mobile clients. The private keys will have to be explicitly and completely shared with the server in order to even search for transactions belonging to the client.

Also, if bitcoin gets as big as they want to speculate, very few people will even be able to run full nodes, and some of the nodes will serve huge numbers of people. It's not a matter of having 20 local accounts, but a matter of having 20 million accounts that are explicitly searched.