IDEA: Anonymous, revocable transactions

[JoelKatz]

Granted, bitcoin does provide more anonymity and privacy than other payment method known. However, a lot of identity information can be scraped by forensic analysis of the hash chain. If anyone ever asks for donations in public, whether in a forum, a web page, a flyer, or whatever, anyone can tell exactly how many donations they got and the timing and amount of each one.

By scraping the Internet, an interested organization could map thousands of bitcoin addresses to identities. By mapping the hash chain intelligently, they could obtain a lot of information about cash flows. You can create new address for each payment, but this doesn't work for cases where an address has to be persistent such as in print media, press releases, source code, and so on.

Also, bitcoin provides no way to confirm receipt. If you see my donation address and want to send me 10 bitcoins, you have to assume that I am actually still monitoring that address and haven't lost the key. For months, years, or more the transaction can sit in limbo with you having no idea whether I got the coins or not.

In addition, bitcoin requires you to either compromise some anonymity or create a new address for each transaction's change. This makes it more difficult to keep your addresses safe. You are constantly creating addresses with non-zero balances and you can't really control it.

Well, I have a solution to all of these problems. It works like this:

1) Instead of using a hash as a bitcoin address, you use the public key itself. You create one address for each public identity. (For example, if you want to receive money anonymously, you can't tell others the same address you post in your forum signature. And you may want separate addresses to know why you got money. But otherwise, one address does it. New addresses are only needed when the user needs one.)

2) To send money, you generate a public/private key pair. You then encrypt this new private key with the recipient's public key (this is the primary key) and with your own public key (this is the secondary key). To perform the transaction, the output includes the public key, the primary key, and the secondary key.

3) The client checks every transaction's unclaimed outputs to see if any of its keys decrypt the primary key or the secondary key to a private key whose corresponding public key is the one in the output. If the client can decrypt the primary key, it marks the transaction as unclaimed incoming funds. If the client can decrypt the secondary key, it marks the transaction as unclaimed outgoing funds.

4) For the recipient to claim the funds, he simply transfers them to himself, following the method in step 2, except the secondary key is the encrypted transaction ID. The recipient will know these transactions are to himself because the secondary key will decrypt to the transaction ID. But otherwise, these 'claims' will look just like all other transactions.

5) If the recipient has not claimed the funds, the sender can reclaim them using the secondary key. Again, these claims will look like all other transactions. Nobody else will be able to tell how the person claiming the transaction got the private key needed to sign a transaction claiming it.

One downside to this is that some people may prefer irrevocable transactions. One way to solve this is to overload the public key a bit. The last four bits can indicate the transaction preference. For example, '00' can mean the recipient has no preference. '11' can indicate the recipient only wants transactions they do not have to claim. There is no requirement a secondary key be included. You can zero it to make it public that this is irrevocable. You can make it random to secretly make it irrevocable.

The beauty of this is that an organization can include a donation address in their contact information and it is not possible to tell how much money was donated to them. You can still give them a donation and find out when they claimed it but not where it went, since the recipient of the very first transaction is opaque to you (you can't even compare it to other transactions where they are the sender or recipient!) this doesn't get you much.

This can easily be added to bitcoin without disruption, though it cannot be done quickly. It will have to be done in stages adding support for introduced transactions first, then waiting for the vast majority of miners to support the new code before adding the ability to introduce transactions. Then miners who don't support the new code won't get their blocks in the public chain (or alternatively, will just reject transactions of the new type).

So, what do you think?

[1714838058]

1714838058

[1714838058]

1714838058

[1714838058]

1714838058

[1714838058]

1714838058

[1714838058]

1714838058

[just_someguy]

Its interesting but this part:

The client checks every transaction's unclaimed outputs to see if any of its keys decrypt the primary key or the secondary key to a private key whose corresponding public key is the one in the output.

would be brutally expensive at a certain volume of transactions.

[JoelKatz]

Its interesting but this part:

The client checks every transaction's unclaimed outputs to see if any of its keys decrypt the primary key or the secondary key to a private key whose corresponding public key is the one in the output.

would be brutally expensive at a certain volume of transactions.

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.

[antares]

1) Instead of using a hash as a bitcoin address, you use the public key itself. You create one address for each public identity. (For example, if you want to receive money anonymously, you can't tell others the same address you post in your forum signature. And you may want separate addresses to know why you got money. But otherwise, one address does it. New addresses are only needed when the user needs one.)

You really want to move down security in an environment that is based on a network that is/may be soon capable of performing successful attacks on private keys?

Remember, current Network Strength is currently at ~13TH ie 13.000.000.000.000 Hashes per second.
Given a growth after this hype by about 100% every 18 months(following moore, and assuming that the hype around bitcoins will flatten out some time), it's only a matter of time until the network is capable of searching the limited keyspace(as we're talking public-key encryption, theres only a limited numbers matching the rules for being a private key[could not find something about the actual algorithm used here, doing the stupid 'assume its rsa'], eg them being prime numbers), and then that opens the question: why shouldn't miners focus on wallets with > 10k BTC on them instead - so no, using only the pkey is by no means something desirable!

[JoelKatz]

You really want to move down security in an environment that is based on a network that is/may be soon capable of performing successful attacks on private keys?

IMO, this moves up security. Currently, anyone who finds a private key whose corresponding public key matches the 160-bit hash can claim a transaction output. With my change, they'd have to match the entire 256-bit key. Currently, you can work on breaking all accounts at the same time, since matching the hash of any key will do. With my scheme, you'd either have to focus on breaking a particular key or break a 256-bit key rather than a 160-bit hash.

Remember, current Network Strength is currently at ~13TH ie 13.000.000.000.000 Hashes per second.
Given a growth after this hype by about 100% every 18 months(following moore, and assuming that the hype around bitcoins will flatten out some time), it's only a matter of time until the network is capable of searching the limited keyspace(as we're talking public-key encryption, theres only a limited numbers matching the rules for being a private key[could not find something about the actual algorithm used here, doing the stupid 'assume its rsa'], eg them being prime numbers), and then that opens the question: why shouldn't miners focus on wallets with > 10k BTC on them instead - so no, using only the pkey is by no means something desirable!

Your logic is backwards. If you're worried about the security of relying on a hash function, you should support my scheme. It takes relying on the hash function out of the equation.

And, in any event, the current scheme does reveal the public keys in many cases. Consider the account in my sig. Bitcoins have been transferred to that account and I have claimed bitcoins out of that account. It has a current positive balance. Anyone can extract the public key from any claim I've made from that account. (You cannot confirm the hash without the public key. So while a hash is used to transfer in, the public key must be disclosed to transfer out.) If you think that someone knowing my public key makes an account unsafe, then you *cannot* use the current scheme for donations. You would *have* to create a new account for every incoming transaction after a single outbound claim.

[samr7]

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.

[JoelKatz]

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.

Correct. That's the tradeoff for anonymous transfers.

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.

It is a tradeoff. Perhaps the best solution is to support both methods, and my version can be used only (or primarily) for cases where you need to broadcast a receiving address.

[hashcoin]

Unless I am missing something, what is accomplished by doing this in the blockchain vs doing it offline?
I.e., what does this do that I can't do with the following scheme:

1) Gen a new bitcoin address.  Send coins to it.
2) Send the privkey for that address to the person I want to send money to (presumably, I would send it securely, by encrypting this privkey with their known publickey).  But this would be done offline, e.g., by PGP encrypted email.
3) They spend the coins to another address of theirs.

[JoelKatz]

Unless I am missing something, what is accomplished by doing this in the blockchain vs doing it offline?
I.e., what does this do that I can't do with the following scheme:

1) Gen a new bitcoin address.  Send coins to it.
2) Send the privkey for that address to the person I want to send money to (presumably, I would send it securely, by encrypting this privkey with their known publickey).  But this would be done offline, e.g., by PGP encrypted email.
3) They spend the coins to another address of theirs.

There are three problems with this approach. First, there is no good way to send someone an encrypted email anonymously. Second, it requires a fixed contact point. If that's an email address, their ability to receive funds could be shut off by disabling that email address at its provider, registrar, or whatever. Third, there is no good way to automate the receipt and processing of funds.

The transaction will be anonymous in the blockchain. But it will have several offline components that are vulnerable.

[FreeMoney]

Unless I am missing something, what is accomplished by doing this in the blockchain vs doing it offline?
I.e., what does this do that I can't do with the following scheme:

1) Gen a new bitcoin address.  Send coins to it.
2) Send the privkey for that address to the person I want to send money to (presumably, I would send it securely, by encrypting this privkey with their known publickey).  But this would be done offline, e.g., by PGP encrypted email.
3) They spend the coins to another address of theirs.

There are three problems with this approach. First, there is no good way to send someone an encrypted email anonymously. Second, it requires a fixed contact point. If that's an email address, their ability to receive funds could be shut off by disabling that email address at its provider, registrar, or whatever. Third, there is no good way to automate the receipt and processing of funds.

The transaction will be anonymous in the blockchain. But it will have several offline components that are vulnerable.

It's encrypted, you can put in anywhere and you can trust any intermediary or any number of them, you don't need to log on to your email to do this.

[JoelKatz]

It's encrypted, you can put in anywhere and you can trust any intermediary or any number of them, you don't need to log on to your email to do this.

While technically true, in practice, what do you do? What would I list as contact information if I wanted to do this right now?

[TierNolan]

This can easily be added to bitcoin without disruption, though it cannot be done quickly. It will have to be done in stages adding support for introduced transactions first, then waiting for the vast majority of miners to support the new code before adding the ability to introduce transactions. Then miners who don't support the new code won't get their blocks in the public chain (or alternatively, will just reject transactions of the new type).

Can this be done with script?

In theory, many public/private key systems could be implemented using the arithmetic opcodes.  However, they are currently disabled.

Does disabled mean that the current client will refuse the accept a block that contains them, or just transactions that contain them?

[JoelKatz]

Can this be done with script?

Yes, but changes in the client would be needed.

In theory, many public/private key systems could be implemented using the arithmetic opcodes.  However, they are currently disabled.

I don't think you'd want to do it that way. There are already script primitives for including public keys and checking signatures.

Does disabled mean that the current client will refuse the accept a block that contains them, or just transactions that contain them?

The current client will refuse to put them into blocks that it mines. So they would never get into the public hash chain anyway. It would have to be done in stages. First, you'd have to standardize a format for the public keys and the scripts. Then clients would have to be modified to accept such blocks as of a certain block number. Then we'd have to wait for that block to roll around, giving enough time for at least 51% of the mining power to support the new form. Then we can start using them.

[just_someguy]

Can this be done with script?

You could get close and have it validated as a good transaction today. All you'd have to do is send money to yourself with this script.
If <encryptedAddress> is a pgp encrypted bitcoin private key:

scriptPubKey: <encryptedAddress> OP_DROP <pubKey> OP_CHECKSIG
scriptSig: <sig>

[TierNolan]

The current client will refuse to put them into blocks that it mines. So they would never get into the public hash chain anyway. It would have to be done in stages. First, you'd have to standardize a format for the public keys and the scripts. Then clients would have to be modified to accept such blocks as of a certain block number. Then we'd have to wait for that block to roll around, giving enough time for at least 51% of the mining power to support the new form. Then we can start using them.

There are actually 2 issues with inclusion in the block chain.

There are transaction rules and block rules.

If a transaction fails the transaction rule, it won't be forwarded.  However, if the transaction is added to a block, then it will be accepted as long as it doesn't break the block rules.

The transaction forwarding rules are that it must be one of the standard transaction, but it should accept non-standard opcodes if they occur in blocks.

However, the latest client doesn't actually seem to do that, but the source is a little hard to follow.  The disabled opcodes are not accepted at all.

The standard script doesn't actually contain an opcode to encrypt/decrypt anything.  The only crypt it has are the hash functions and it can check the ECDSA signatures.

[ByteCoin]

I missed this first time round. I will edit this comment on Sunday to address this proposal.

ByteCoin

[JoelKatz]

The standard script doesn't actually contain an opcode to encrypt/decrypt anything.  The only crypt it has are the hash functions and it can check the ECDSA signatures.

This is the biggest problem. ECDSA is for signing and verifying, not encrypting and decrypting. Something like ECIES would have to be added or we'd have to use RSA instead.

[maaku]

If you're going to add something though, you might as well provide basic AES primitives for various modes. And while you're at it, raw ECDSA sign/verify primitives (operating on items on the stack rather than just the transaction). Most everything else can then be composed.