 |
December 07, 2013, 08:04:24 PM
Last edit: December 08, 2013, 03:32:21 AM by Stuffe |
|
Crossposted from something I added to the Anoncoin thread. I hope other people will look at this and reveal any flaw in the scheme they might find.
Ok, much of this will use PGP in reverse of the way it is normally used, so the key Public key will be kept secret and the key Private key will be given out. Therefore I will call the Public key the "Encryption key," and the Private key the "Decryption key" in the rest of this post.
Imagine two types of transactions in the block chain, one visible and one secret:
The visible one would include:
- the sender in plain text
- the receiver in plain text
- the amount in plain text
The secret one would include:
- sender in plain text
- The receiver id hashed with a salt, then encrypted with senders encryption PGP key (unique PGP pair for every transaction)
- The amount encrypted with senders encryption PGP key
- Parent transfer ID in plain text (transfer where the sender received the money he now wishes to spend)
Example
Let’s say we want to transfer coins we received in Transaction 1 (visible), to Bob in Transaction 2 (secret). Bob would take his id together with a salt and hash it and give us this hash. Now we take the hash and use our PGP encryption key to encrypt it together with the amount. We also give Bob our decryption key so he can privately verify the transaction when it goes out on the block chain, but we don’t give it to anyone else. Giving it out, would be the same as making the transaction visible. Of course any of the two parties now can make the transaction visible should they want to, by giving out the decryption key, but this is not a problem that can be fixed, as they are both aware of the transfer and could just tell people about it in any case.
Anyway Bob uses our decryption key to see on the block chain that it is his hash that is encrypted in the transfer, he sees the amount is right and he looks up the ID of the parent transfer and sees that we indeed have enough money from Transaction 1, that means it he can verify it. Also no one, not even we know Bobs real sender ID (only his salted hash) and only we and Bob know how much we actually send him.
But now Charlie doesn't know that we actually don’t have any money left, let’s try and buy something from him with money we already spent (Transaction 3). How can he know if we have the money? Well he gets our decryption key, otherwise he will think it is very weird and assume our payment is bogus. Then he looks at this new Transaction 3, he sees the reference to Transaction 1 where we got the money from, so that checks out. But he then searches for other transactions with references to Transaction 1 and he finds Transaction 2 that we made with Bob. But since he already has our decryption key, he also can read the amount we sent to Bob, and subtract it from the money we had and sees that we actually don’t have enough coin for the transaction to be valid. The rule is that older transfers take priority over new ones, so even if we “overspend” in Transaction 3, everyone agrees that Transaction 2 is still valid. Only Transaction 3 is to be ignored. Now Charlie knows Transaction 3 is invalid and doesn't hand over the goods we tried to purchase!
Later transactions can always verify by the receiver in this way, so if Charlie always verify it properly he can be 100% of the coin he receives. Charlie can also see Bob’s receiver hash of course, but that doesn't reveal Bobs sender ID and he can’t “dictionary attack” with the senders on the block chain, since Charlie doesn't know the salt.
But say Bob now wants to send some of the money we gave him to David (Transaction 4), how can David verify that Bob has the money when Transaction 4 refers to Transaction 2 which was secret? Well since it was secret, Bob has to make it visible to David, by sending our decryption key and the salt he used in that transaction to him. David can now verify Transaction 2 and that we were in fact the receivers and he can then verify Transaction 4 too and is happy that he received the coin.
Space issue:
Of course if David wants to spend the money from Transaction 4 he now must send both our and Bob’s decryption key and salt, together with his own and so on. In order for space for saved decryption keys and salts not to grow out of control long term, you could include a fix where senders would be forced to make old secret transactions visible by giving out the decryption keys and salts from those transactions. The network would not accept transfers from further down the "chain" unless outdated transactions in that chain become revealed by the sender at the same time.
Information of this revealed old Transactions are added to the block chain and supersede the older ones (that can be removed using a method that doesn't compromising the security of the block chain. I won’t go into this now). Now every one in the Chain can get rid of the decryption keys and salts from those outdated transactions.
Receiver address:
Your receiver address is a hash of your sender salted address, you can generate as many receiving addresses as you want for each sender address, just by changing the salt. This also means you can keep your sender address hidden to the person sending to you and you can have him send to you multiple times, without him even knowing he is sending to the same sending address.
What do you guys think about this? It is not easy to explain, do you understand it? If someone who understands this can verify that it seems to work, I will probably make some graphs to explain better. Have you found any flaws/mistakes?
|
