Topic: Way to make transaction amounts and receiver address completely hidden (Read 2423 times)

gmaxwell
Very good questions that I hadn't thought about.
What if it we aimed for 0,5% inflation but spread the spoils based on how many transactions were included in that block? Of course this would give the miners a real incentive to spam the network with transactions. But what if we required some local proof of work for each transaction, that the clients were expected to do themselves. Like hashing the transaction data with different salts until a salt with x number of zeroes in the end was found? Then this salt could be added to the transaction data for others to confirm easily. Each transaction data together with its salt had to be unique, so you couldn't spam the network with the same transaction. This local proof of work would also have to be less profitable for miners than just mining transaction proof of work made by others. That shouldn't require much, since you would be unlikely as a miner to receive the bonus for your bogus transaction anyway (win the block). Spamming would be very computationally intensive and spammers would in effect pay by loosing potential income from not using that computational power to mine.

As for if this is for bitcoin, I don't know if it can be implemented at this point with backwards compatibility. It would probably take a lot of work. Seeing as you are a moderator feel free to move the post if you feel it belongs in the other section. But please also feel free to continue to provide valuable feedback

Why should anyone include any transactions at all? How do you prevent someone from typing while true; do stuffecoin sendtoaddress `stuffecoin getnewaddress` ?

If you're not talking about something even possible in Bitcoin— this is the wrong subforum, altcoin subforum is over there ---->

Thanks for the answers

BurtW:
If by "public ledger system" you mean a block chain that everyone agrees on, then yes. A block chain like with bitcoin, just a different standard for what is stored in those blocks.

gmaxwell
I have not been actively following this board for a while. what is anti-dos? (anti denial of service I guess)?
I don't see the need for fees, if the mining bonus stays for ever (say at 0.5% inflation long term).
I agree that it couldn't scale if transactions had to stay secret for ever, but you could make public transactions that are older than say 30 days, to avoid this problem. I understand that later transactions in the Chain can reveal previous ones, but I don't see this as "brittle security," since it is still an improvement from BitCoin where everything is always visible. Also its not a problem as long as you don't spend your coin or send the rest of your coin to a new place every time you spend. But I will have a look at your links and reply thoroughly later!

What you appear to be describing is a cryptographically blinded commitment scheme.

See Adam Back's commitment thread: https://bitcointalksearch.org/topic/blind-symmetric-commitment-for-stronger-byzantine-voting-resilience-206303

Blind commitment schemes have problems with anti-dos, with paying fees (makes the anti-dos problems worse), with poor scalability (the coins become larger linear with their history size— and the history tends to grow exponentially over time with splits and merges),  and brittle security— because someone down the line can leak the whole history.  You can attack the scalability by later disclosing the history in public but then you just make the security story worse.

Most of these issues go away if add to the system a zero knoweldge proof that confirms that the blinded data is valid, consistent with the network history (e.g. spending existing coins), discloses the fee, and confirms that that its outputs, fees add up to the input... then perhaps you get something that might work acceptably. But then the challenge is getting a ZKP which is fast enough, produces small enough proofs, and doesn't depend on a trusted party to initiate the system. There is lots of work going on in the ZKP space, but a lot of it is focused on delegated computation and needs trusted initialization, though theory permits solving these problems.

Question before I start:  are you proposing this system to be added to a Bitcoin like public ledger system that like Bitcion uses a decentralized concensus mining system OR is this a proposal for a completely different yet to be designed system?

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?