Is it possible to hide the sender or receiver of transactions by "zk-SNARK" or "Bulletproofs"?

Is it possible to hide the sender or receiver of transactions by "zk-SNARK" or "Bulletproofs"?

To support the user privacy, is it possible to hide the sender address or receiver address of transactions by "zk-SNARK" or "Bulletproofs" ? Or we’ll be able only to hide the value that is mapped to an address ?

Assume the following mapping:

mapping (address => bytes32) userData;

Normally, using non-interactive zero-knowledge proofs (like "zk-SNARK" or "Bulletproofs"), we are able to hide the value that is mapped to an address (i.e. userData) as follows:

mapping (address => bytes32) userDataHash;

And then by zero-knowledge proofs, we can prove that if userDataHash meets a condition? For example, prove that an encrypted number is in a given range, without revealing anything else about the number.

However, assume that instead of Data, we want to hide sender of transaction (i.e. address). We want to keep confidentiality of the user/sender himself, instead of their data.

Is it possible ? And if yes, How ?

https://ift.tt/2MzuHND

Comments

Post a Comment

Popular posts from this blog

What exactly is a block?

What exactly is a block? I am trying to understand the Blockchain algorithm used in Bitcoin. I do not get the part how blocks are created. Let’s say transactions occur at some time. Then, if some nodes get these transactions, these verify the transactions are valid and then send it to other nodes. With this verify-send algorithm, almost every node verifies these newly occurred transactions in few seconds. Now, it is a time for a miner to do his job, which I do not understand. He needs to find a nonce which makes a lower value than hash values given in transactions. Question 1 How many transactions should a miner should verify in a single block? For example, if a miner A finds a nonce which gives a lower value than hash values given in 50 transactions, and if a miner B finds a nonce which gives a lower value than hash values given in 70 transacations, would a reward be given only to the miner B? So should a miner appropriately choose how many transacations he will work for? Ques...
Read more

how a system based on a blockchain would deal with exponential growth of informations carried in it?

how a system based on a blockchain would deal with exponential growth of informations carried in it? I was reading this article about the difference between a blockchain and centralized servers and a question came up to my mind: if I understand well the difference stands in the fact that in a blockchain there isn't a centralized server that maintains online a version of the informations based on it and protects them from corruption. I'm thinking for instance about wikipedia. Every "miner" instead has a copy of the informations - of the blockchain - and that is why it is so difficoult to alter a blockchain. But what if these informations, and with them the blockchain itself, became too heavy to be supported by little private servers? My question is how a system based on a blockchain deals with exponential growth of informations. I hope to ask in the right place, if it isn't I beg your pardon! http://ift.tt/2GIuwJX
Read more

Do extra hop channels in a BOLT#11 invoice need to exist on chain?

Do extra hop channels in a BOLT#11 invoice need to exist on chain? According to the BOLT#11 specification, a node may add extra routing information for private channels to an invoice, where they specify the public key of the penultimate hop, along with the short_channel_id. r (3): data_length variable. One or more entries containing extra routing information for a private route; there may be more than one r field pubkey (264 bits) short_channel_id (64 bits) ... However, unlike channels announced through a channel_announcement message, there are no signatures to prove that the invoice payee actually owns that channel, or even that it really exists. Technically, it appears that the invoice creator could point to any valid 2-of-2 UTXO on the chain and claim it to be their private channel. Do existing implementations check whether the transaction referred to by the r field's short_channel_id actually exists on the blockchain and that they are valid 2-of-2 multisig transaction...
Read more