3

This is just a random idea with no technical backing: with RingCT the input is obfuscated, but everyone still knows that the output destination holds the money. Is there any possibility of also obfuscating the output similar to RingCT? For example, the transaction output would consist of the real destination plus a bunch of fake public keys so that an observer cannot tell exactly where the money went to.

Is something like this just technically impossible?

7

With ring CT, the amounts will be obfuscated. Inputs are already obfuscated by using ring signatures.

The destination is already obfuscated by using stealth addresses. Only by having the private view key that belongs to the address (and knowing the address), you're able to tell that the output was sent to that address, which is exactly what your wallet does when it's syncing with the blockchain. It checks every output and attempts to decrypt it with your private view key - if successful, the output is for you. If not, it's for someone else, and you don't know for who.

For example, let's have a look at a random transaction. There, you will see two inputs, and for each input, 3 public keys. This is a 2-mixin transaction, meaning there are 2 fake keys and 1 real. You're not able to tell which one, so you can't tell who spent the key image.

It's been split into 7 outputs, and you can't tell to whom the outputs belong to, unless you're able to "decode" them. Note that any of those outputs can be used as a "fake" key in someone else's transaction.

1

I think what you are describing is basically what already exists in Monero (even prior to the RingCT release) You cannot look at the blockchain and know where the output is going.

  • I think what I meant was not well understood. With RingCT, usually the output consists of the receiver's output public key (opk) and the sender's opk for change. Therefore, an observer can guess which of the two was the receiver/sender with 50% probability. Before RingCT, the output consists of many opks due to denomination, which is a security risk as explained in Sec3.2 of MRL-0004. What I meant was to introduce some purely dummy opk whose private key is known to nobody (like H in CT), which can then later be used in a new ring signature. – kenshi84 Sep 26 '16 at 1:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.