Category Archives: Privacy

fungibility Monero Privacy

Idea: Colored Coins on Monero

Published by:

While the main goal of Monero is obviously to be a fungible cryptocurrency, lots of cool things can be done with the technology. Recently I saw an article about “Confidential Assets” by a start-up called “Chain”.

The Confidential Assets that Chain is proposing are basically a form of issued tokens that can be transferred anonymously between parties on the same network. The issuance can be anonymous and the balances of the accounts are unknown to an observer. There is a downside however: the history of the assets/tokens can be tracked. This scheme can for example be used for creating virtual poker chips,  company shares or even cryptofiat backed by a reputable bank who holds the currency on balance.

While this is a cool idea, I don’t think it needs its own blockchain or other form of “decentralized” database with some weak consensus mechanism. If you want fungible assets however, then a different approach is certainly needed. Monero lends itself perfectly for this job because all transactions are untraceable, unlinkable and with RingCT the amount isn’t visible. In this small article I propose a system for building Colored Coins on the Monero network. These Colored Coins are fungible, the transactions use RingCT, the issuer can be anonymous and an observer who isn’t part of the CC-network doesn’t necessarily need to know the amount of Colored Coins in circulation.
Seems like a cool idea? 🙂

How does the Colored Coins on Monero looks like in general?

1) Monero is divisible into 1 trillion (10^12) atomic units (“etoj”). To create a specific Colored Coin, the Issuer needs to first define the amount of Coins he wants to issue. He also needs to take into account how much decimals the token can have. If a bank for example wants to issue 1 million USD on the blockchain with 2 decimals, then there are 100 million atomic units. To issue this particular Colored Coin, the Issuer will need 0.000100000000 XMR. Every eto will represent 0.01 USD.

2) Now that the Issuer defined the amount of atomic units, he can do the “Issuance Transaction”. The Issuer simply sends a transaction with the required output to an address he controls. There is no need for a paymentID. No special measures need to be taken. This transaction just looks like any other transaction on the blockchain.

3) The Issuer then needs to perform the Enabling Transaction: this is the first transaction which uses the full supply. Let x be the minimum Ring Size, then this Enabling Transaction needs to have at least x outputs.

4) From this point onwards, transactions which use this specific Colored Coin are required to only use txo’s that stem from the Issuance transaction in the ring sigantures. If any other txo’s are used in the ring signature, then all the outputs will lose their Color. These txo’s won’t be recognised anymore by the Colored Coin network.

5) There is one problem however with this scheme: monero transactions aren’t free. But to be able to pay for the fee, additional inputs in the transaction are needed and it will need to be possible to verify that all the additional real XMR is spent as a fee payment. This would require tweaks in the RingCT protocol, disclosing a lot of info about the transaction to the public, etc.
A more private solution is the following: when you spent a colored txo, you’ll usually have at least 3 outputs: the payment, the change and a 0-output. This 0-output will then be spent again in another transaction using a ‘Child Pays for Parent’ scheme. The result will be that this 0-output will lose its Color, but who cares? It was a 0-output anyway.
Note: currently CPFP is not yet possible on Monero. Maybe another solution for the fee problem is possible. But I suggest that this system would reveal as little data about the Colored Coin transaction as possible.

The result of this scheme is that someone is able to issue Colored Coins on the XMR blockchain. The transactions will use RingCT. The issuer can chose to disclose the amount of coins created, or not. The Colored Coins will be fungible. Downside: it will be pretty easy to spot colored coin transactions on the blockchain, even if an observer isn’t aware of the Issuance public key and/or or the Enabling transactionID. If regular Monero users use real XMR in a ring sig in combination with txo’s that are inside the Colored Coin system, an observer will be able to discard those Colored txo’s as real inputs of the transaction.

Assuming CPFP will be implemented, a practical implementation of this scheme seems pretty easy: what is needed?

A) a special wallet that is “Color Aware”. The user needs to be able plug the public key of the Issuance transaction (the key that contained the whole supply) and the txid of the Enabling Transaction into the wallet. By doing this, the wallet recognises that a certain transaction contains all issued tokens and that a specific transaction enabled the network. Note that the txid is needed, because nothing stops normal users of the Monero network to use the public key of the Issuance Transaction in a regular ring signature.

B) Optionally, the user can add more sets of public keys and txid’s later on. If the Issuer decides to create more tokens (for example new shares) then the user can decide to accept this new issuance.

C) The Color Aware wallet needs to be able to recognise incoming Colored transactions and check their validity.

D) The Color Aware wallet needs to be able to pick the txo’s from the approved list when creating Colored Coin transactions.

E) The Color Aware wallet needs to add a 0-output to every transaction and pay 0 fee when sending a Colored transacion

F) The Color Aware wallet needs to spend the 0-output with a “double fee” using CPFP to confirm the Colored transaction.

G) Optionally, a public database can be created that has the info of certain Colored Coins with the data needed to add it to the Color Aware wallet. The Issuer can decide to publish it or not. Optionally, he can also disclose the amount of tokens issued by disclosing the TX private key of the Issuance transaction and the originating address of the Enabling transaction.

ShapeShiftOpenAlias

Altcoins fungibility Privacy ZCash

The Untrusted Setup – Why you shouldn’t trust ZCash

Published by:

Hidden inflation

ZCash will launch today. This is not a “normal launch” like any other altcoin, because ZCash required a so called “trusted setup”. During this setup, some secret (public) parameters were generated based on a “master private key”. These network parameters are needed to create the so called “zero-knowledge proofs”, which is the anonymizing mixer on the ZCash network. The “master private key”, referred to by Zooko as toxic waste, needed to be destroyed.  If this data is not destroyed, someone who has access to this key is able to generate an infinite amount of anonymous ZCash.

This is the so called “hidden inflation problem”; unlimited counterfeiting of coins while nobody is able to detect it. If this were to happen, it would undermine the value proposition of the ZCash cryptocurrency. ZCash would never be considered to be “sound money” where the emission scheme can be checked by all participants. The problem is that nobody can check if the setup actually did occur  in a correct manner. People who hold value in ZCash will need to trust the setup process from the genesis block onwards.

Setup of the setup

ZCash used a “multi party protocol” which means that, according to the team, as long as one of the participants in the generating process is honest and doesn’t keep a copy of his part of the “toxic waste”, nobody else will be able to get access to the full “master private key” that is needed to create counterfeit coins. Only 6 people participated in the setup. This is a very small group and thus creates a theoretical possibility that these people were conspiring or were being coerced by a TLA to keep a copy of the “master private key”. While this is a possibility (certainly considering possible involvement of the Israeli government), it doesn’t seem all that likely due to the involvement of Peter Todd, who isn’t a part of the ZCash team.

What’s more worrisome is the fact that the setup itself could have been compromised: think about hardware, network, software, operating system, binaries, etc. There are a lot of attack vectors. Governments had a very big incentive to compromise the setup of the setup. If successful, they are able to create free money without people noticing and meanwhile diluting the value of a potential powerful cryptocurrency. State sponsored attacks are known to be very sophisticated, like Stuxnet that sabotaged the Iranian nuclear power plants.  Is it therefore likely that governments were able to compromise this “trusted setup” as well? I my opinion it is. It’s impossible to prove that an unknown attack didn’t happen. You don’t know what you don’t know.

Sybil zk-proof attack

The ZCash team often repeats that even if the setup is compromised, the anonymity of the network isn’t at risk. However, I beg to differ. Due to the high RAM requirements to generate “jointsplits”, it’s unlikely that the anonymizing feature of the ZCash network will be used much in the first years of the existence of the coin. This leads to the possibility of “timestamp analysis attacks”. People tend to use new mixing technology as an “intermediate step” for obfuscating bitcoin transactions. But due to volatility risk, people tend to have their value for the shortest possible time in an altcoin. If people use the zk-mixer for obfuscating bitcoin transactions, it will be trivial to connect the transparent ZCash that enters the zk-mixer and the ZCash leaving the mixer again after only a few minutes or even hours. (Sidenote: this leads to fungibility problems within ZCash; you can read more about it here.)

Imagine an attacker counterfeiting a lot of fake zk-proofs. This could create the illusion of a liquid mixer. A lot of usage means that suddenly one can hide his transaction in this mixer with a lower (perceived) risk of being tracked. Timestamp analysis attacks become increasingly harder. But the attacker, who knows all the fake zk-proofs, can ignore his own counterfeited liquidity. He is still able to do the timestamp analysys based on the real (low) liquidity inside the zk-mixer. This leads to a very dangerous situation in which the user thinks he is transacting anonymously, but in which an attacker will still be able to track all transactions. Privacy theatre is a huge risk.

Chain rollbacks

There is a (drastic) option to solve this issue. Zooko proposed recently to periodically force everyone to reveal their balance as a solution for the hidden inflation problem. At a certain block height all “anonymous” coins would become invalid and an observer would be able to sum up all “transparent” coins. If the total amount is equal to or less than the emission should actually be, the  system can be considered “sound” until that point in time.

If however an anomaly is discovered, then the ZCash community will face a difficult decision: continue with the inflated emission or rollback to the previous checkpoint. The network would also come to a halt until the bug is found. Trust in the currency would be lost immediately. If the community decides to do a rollback, this means that all transactions between the previous checkpoint and the detection of the hidden inflation will become invalid. Some people won’t like this rollback and maybe a non-rollback ZCash fork would emerge.  When people use the “rollback ZCash” however, one can only consider transactions to be “fully confirmed” after such a successful “emission checkpoint” happened.  Exchanges, users, merchants and wallet services should be aware of this serious risk.

Inflation bugs

ZK-proofs are very difficult to understand. Recently, Zooko even admitted he doesn’t understand the math. The ZCash team has some smart people on board, but even they can not guarantee that the network is free of bugs. During the test phase, a bug was discovered that made it possible to counterfeit coins. This attack had nothing to do with the “trusted setup”, but would cause the exact same problems as described in this article. Due to the fact that the ZCash protocol is very complex code, it’s not at all guaranteed that similar bugs aren’t still present in the protocol.

Conclusion

You shouldn’t trust ZCash.

zcash2

ShapeShiftOpenAlias

Altcoins DASH fungibility Privacy

Warning: DASH privacy is worse than Bitcoin

Published by:

This article analyses how DarkSend works and will explain why there’s absolutely no good  reason to use DASH for private transactions.

dash1

The cryptocurrency DASH (formerly known as Darkcoin, formerly known as XCoin) brands itself as a “Digital Cash”. When people promote DASH, they often claim that the PrivateSend (formerly know as DarkSend) feature makes DASH the “top contender in the realm of privacy coins”.

This recent steemit article by bravenewcoin is a perfect illustration of what I mean. There is zero critical thinking. Nobody seems to ask questions and do research. If there is no proof that these claims are correct, then it’s dangerous to use DASH in the first place. People who are not technically literate will use DASH while presuming that they are doing private transactions. They are exposed to some risky attack vectors, but think they are safe.

dash2

Let’s first look at how DASH describes the “Darksend” feature on their website:

Darksend is the feature that gives Dash users full privacy when they use it. It is an improved and extended version of the CoinJoin. In addition to the core concept of CoinJoin, we employ a series of improvements such as decentralization, strong anonymity by using a chaining approach , denominations and passive ahead­of­time mixing.

So DarkSend basically is a fork of CoinJoin. DASH added some things and claim these features are improving the privacy of the DarkSend user. We examine them one by one

 

1) Coinjoin basics

Darksend uses the fact that a transaction can be formed by multiple parties and made out to multiple parties to merge funds together in a way where they can’t be uncoupled thereafter. Given that all Darksend transactions are setup for users to pay themselves, the system is highly secure against theft and users coins always remain safe.

dash3

Coinjoin, as implemented in Joinmaket on Bitcoin, is a system that enables users to mix their coins in a decentralized way. As shown in the image above, users basically transact together in the same coinjoin transaction. By doing this, an outsider can’t really know which output belongs to which input.

Joinmarket is currently the only viable decentralized implementation of Coinjoin on Bitcoin. DarkSend is a different implementation of Coinjoin on the DASH network. We’ll compare these 2 implementations in this article.

 

2) Decentralized mixing

In Joinmarket, there is no central server to find counterparties to mix with. You just announce to the network that you want to mix and someone else can join your mixing proposal. Other implementations of Coinjoin, such as Sharedcoin by blockchain.info uses a central server to generate the coinjoin-transactions. It is possible that these servers log the different inputs and outputs so they can potentially deanonymize the coinjoin-users.

In DASH, the DarkSend-users connect to a masternode for mixing. This masternode enables the mixing proces in a similar way as the sharedcoin system. These masternodes can log the inputs and outputs and therefore deanonymize the users.

Note that you don’t need to be the owner of a masternode to see these logs. Most of the masternodes are hosted on cloudhosting services. If a government demands access to these logs, they will probably get it. It’s entirely possible that right now the NSA is spying on the majority of masternodes without the owners even knowing their masternodes are being spied upon.

The DASH website ignores this risk and tries to reassure us that by using “chained mixing”, you’ll be safe:

 At set intervals, a user’s client will request to join with other clients via a Masternode. (…) Each Darksend session can be thought of as an independent event increasing the anonymity of user’s funds. (…) To increase the quality of anonymity provided, a chaining approach is employed, which funds are sent through multiple Masternodes, one after another.

Stating that chaining mixings is more secure is just false: suppose an adversary has access to a large number of masternode logs. When someone does one mixing and then waits a day to do a second one, he’ll be more private than someone doing 6 mixings in a row. Why? If the adversary owns 2 of the 6 masternodes used in the mixing process, it will be easy to undo the mixing that happened in between due to the low liquidity in the DASH system (see next point).

DASH mixing is far from decentralized and it’s even worse than Sharedcoin: when using Sharedcoin, the user is aware that he’s using a centralized system. When using DASH, everybody pretends it’s a private decentralized system, but in reality, it isn’t.

 

3) Mixing liquidity

The advantage of DarkSend compared to JoinMarket, is that it’s implemented in the official DASH GUI, so it’s easily accessible. I assume the idea behind that was to encourage the use of DarkSend which would improve the liquidity in the DarkSend mixing system.

Liquidity is very important for any mixing system to function well. If only a few people are mixing, these systems are easily Sybil attacked: if some adversaries just try to mix with as much people as possible, they will be able to get a lot of info from their own mixings because they are in most cases the only counterparty of the people who want to mix.

So let’s compare the liquidity between DarkSend and JoinMarket:

Currently, according to JoinMarket.me, this bitcoin mixing system has 86 counterparties to mix with. This means that at any time, someone who wants to mix can choose one of those 86 people to mix with. He can even do multiple mixings (“chained mixing”) to improve his privacy: it’s possible that some of his mixing partners were adversaries, but chances are smal that all of the counterparties were.

A Sybil attack is more difficult to successfully execute when the number of counterparties grows. Bitcoin has the advantage that there is a lot of liquidity in the Bitcoin network. The market cap of Bitcoin is more than 10 billion and I estimate that the number of active bitcoin users is in the millions. If only a small percentage of those people started using CoinJoin, the liquidity in the mixing system would grow and Sybil attacks would be very hard to pull off.

It’s not possible to get exact data on how many counterparties are available in DASH DarkSend, but we know a few things: the DASH market cap is 50 million USD and I estimate the number of active users to be in the thousands. So by using DASH you already reduce the anonymity set you’re in by multiple orders of magnitude.
Due to the low liquidity on the DASH blockchain, it’s possible to attribute “chained mixings” to the same individual solely based on blockchain analysis.

But what’s even more telling is the fact that a lot of DarkSend users seem to experience a very slow mixing process. Check this subforum for their stories: http://dash.org/forum/topic/privatesend-questions-and-help.77/ 

DASH developers tried to improve the number of mixing participants compared to JoinMarket. Joinmarket usually only has 2 participants, DASH has t least 3 people mixing together:

Currently to mix using DarkSend requires at least 3 participants.(…)However each session is limited to three clients, so an observer has a one in three chance of being able to follow a transaction.

The DASH developers also noticed that mixing is slow, so they decided to pay 5 “liquidity providers” to constantly mix their coins. This probably increased the speed of the mixing a bit since this system was implemented, but it is also a very big risk: if these 5 people collude (or are being spied upon), it will be trivial to deanonymize every DarkSend transaction that happened on the DASH blockchain. This is a very unsecure system to depend upon for your private transactions!

 

4) Denominations

DASH added a denomination system to the coinjoin-implementation of DarkSend:

To improve the privacy of the system as a whole we propose using common denominations of 0.1DASH, 1DASH, 10DASH AND 100DASH. In each mixing session, all users should submit the same denominations as inputs and outputs.

Statistical research is needed to confirm the claim that denominations are actually better for privacy. If it were better, then joinmarket could easily implement it. But I think there are also some risks associated with using denominations: if you want to mix 987.6 DASH, you’ll end up with 30 outputs. When you want to spend 375 DASH, you’ll regroup at least 15 of those outputs. This could potentially lead to making your previous DarkSend privacy weaker. A better approach would be to conceal the amounts in the transactions by using Confidential Transactions combined with coinjoin.

 

5) Passive mode

With joinmarket, you have an incentive as a market maker to propose mixings to the bitcoin network. Joinmarket has an incentive to provide liquidity. Tis makes it easier for people who want a fast mixing to just ping the network and accept a mixing by one of the market makers.

The DASH developers correctly identified that timing attacks are an issue with mixing. But the fact that they promote the “passive mode” of  DarkSend as a feature is very telling: it’s turning a bug into a feature.

Darksend is limited to 1000 DASH per session and requires multiple sessions to thoroughly anonymize significant amounts of money. To make the user experience easy and make timing attacks very difficult, Darksend runs in a passive mode.

In DASH this “passive mode” is just your node waiting for other people to show up to mix with you through a masternode. There is no incentive at all to do this. It’s a necessity. It shows (again) that the DarkSend liquidity is painfully low.
Conclusion

DarkSend (now called PrivateSend) has some serious privacy issues. It’s risky to rely on this system and the liquidity is very low which makes it not really usable. If you need to choose between Bitcoin and DASH, it’s safer to rely on Bitcoin mixing systems and more specifically on JoinMarket.
PS: fungibility claims

dash4

DASH also claims to be a “truly fungible” coin:

By having a decentralized mixing service within the currency we gain the ability to keep the currency itself perfectly fungible. At the same time, any user is able to act as an auditor to guarantee the financial integrity of the public ledger without compromising others privacy.

There is a lot to say about this, but I’ll refer to a previous article of mine about fungibility. Basically bitcoin and DASH have the same fungibility issues. Coinjoin can’t “fix fungibility”. You can read that article here: http://weuse.cash/2016/06/09/btc-xmr-zcash/
PPS: Instamine scam

By the way, if after reading this article you somehow still regard DASH as a legit project, there is still the instamine you can look into…

Teaser: this chart shows the first 72 hours of DASH. At the moment there are about 6.5 million DASH in circulation. In the first 2 days 2 million coins were created. In the first hour more than 500000 coins were created.

dash5

 

ShapeShiftOpenAlias

Bitcoin fungibility Monero Privacy

Bitcoiners, why not hedge your position?

Published by:

Bitcoin is stagnating. There seems to be no consensus on how to scale bitcoin. Bitcoin blocks are almost full. Transactions are slow. On the regulation front, it’s possible that the traceability will be used to enforce blacklisting or whitelisting. Mining is centralized, this can lead to governments forcing mining pools or big mining farms to filter certain suspicious transactions.
Will bitcoin lose its monetary characteristics due to these issues in the long run?

If you answered this question with a “definitely not”, you are in denial. This is a threat to the future of bitcoin as money. There is always a chance that Bitcoin becomes obsolete. We saw Digicash, e-gold and Liberty Reserve also ceased to be money. So, my advice would be to find a good hedge for your BTC position.

What characteristics are needed for a good crypto hedge?

1. No Bitcoin copy

Most of the altcoins are forks of bitcoin with a minor tweak. Litecoin was popular in the past because the mining algorithm was GPU-friendly, and thus decentralized. Since scrypt ASICs exists, this unique selling proposition is gone. LTC is a very bad hedge against BTC because most of the code is identical.
LTC is exposed to the same issues as BTC: problems with scaling, a possible error in the BTC codebase, traceability of transactions, etc.

2. Unique features

The hedge should have some use case. If the only demand for the coin is to function as a hedge, then it probably won’t succeed because there is no market demand, unless BTC is in trouble. Once the issues are resolved, the value of the hedge would drop dramatically. There are some coins with a decent market cap who fit rule 1 and rule 2:

Ether: decentralized smart contracts
Ripple: different consensus model  (note: almost dead because no use case and considered a scam by many because not really decentralized)
Maidsafe: decentralized cloud storage
Peercoin: first Pow/PoS hybrid
Factom: notarizing on the bitcoin blockchain
NXT: decentralized asset exchange

3. No apptoken

However, most of these coins, with the exception of Peercoin, aren’t “coin-like coins”. They are apptokens and it is very likely that all features can be implemented with bitcoin as currency in the future (on a sidechain, or maybe just on top of bitcoin itself). There is a chance some of them (maybe Ether?) will survive on their own if the development is strong and the userbase is solid.
But even if an appcoin can stand on his own legs, this isn’t a guarantee that it will be valuable because there will only be demand for using the apptoken when using the application. There won’t be monetary demand., incentivizing to store a portion of your net worth in it. This gives these coins a very questionable long term value proposition, again with the exception of Peercoin (maybe).

Monero

I intentionally left out Monero. Currently it has a market cap above 10 million USD and I think this is the perfect hedge for your bitcoin position.

Why, you ask?

  • Monero has a different codebase: it is based on the “cryptonote protocol” and is building a lot of additional functionality, like RingCT (Ring Signature Confidential Transactions)
    resulting in default untraceable and unlinkable transactions. This makes monero real fungible and anonymous eCash. Browse this website for more information on this subject.
  • Monero uses a different elliptic curve. If the BTC curve is broken, the XMR curve could still be solid (and vice versa).
  • Monero also has a scaling solution baked in the protocol: it has a dynamic block size limit. If the demand for transactions goes up, the block size limit will scale. For this to work, it is necessary to have a “tail emission”. When the initial emission of 18.4 million moneroj runs out, a minimum block reward of 0.6 XMR / 2 minutes will  be given to the miners. This ensures long term incentives for the miners, even if a fee market doesn’t develop.
  • The mining algorithm is a different hashing function that is written to be CPU-friendly. The performance gap between CPU and GPU mining is small. A features called “smart mining” will probably generate more decentralized mining.
  • Last but not least, Monero isn’t an apptoken: it’s highly unlikely that the properties of Monero will be implemented in Bitcoin. Bitcoin is transparent by default, monero is private and fungible by default. Implementing ring signatures as a sidechain for example, isn’t sufficient:  the sidechain would function as a mixer, but transparent bitcoin transactions are still possible. Regulation could force services to only accept traceable bitcoin transactions, miners could be forced to not process anonymous bitcoin transactions, blacklisting of coins would still be possible, etc. If raising the bitcoin block size limit is creating a consensus problem, then  changing the core functionality of bitcoin transactions will not happen. It’s highly unlikely that bitcoin ever will be private and fungible by default.

So if you are looking to hedge your bitcoin position, maybe research Monero. The number of BTC and XMR in existence are comparable, so if you decide to buy a similar amount of XMR as you currently own BTC, you are hedged. Why not take a small insurance policy for you precious bitcoins? You can start researching here.

 

ShapeShiftOpenAlias

fungibility Monero Privacy ring signatures RingCT

Tying up loose ends with RingCT

Published by:

RingCT, as proposed in a paper by the MRL researcher Shen Noether, was announced just a few months ago and recently received enough funding for the implementation. Ring Confidential transactions is complicated new technology using math and cryptography to hide amounts in transactions using ring signatures. Not many people saw the implications of this innovation for XMR and even less people actually understood how it all works.

I can’t explain you how it works. If Shen’s paper will be published in Ledger, an academic journal on cryptocurrency and blockchain technology, RingCT will be subject to peer review. When the academic community decides it works, we’ll know for sure. But let’s just assume for now that it will actually work once it will be implemented.

What I can try to do is explain some of the implications of RingCT. Hiding amounts seems a nice feature to have, but why do we need it? After all, we have already the stealth addresses and ring signatures which provide us with privacy and fungibility.

If you read MRL-0004, you’ll notice that there are still some privacy concerns when using Monero. The issues raised in section 3.2 (Association by Use of Outputs Within a Transaction) can be solved by using RingCT.
In short, the problem is that when you want to spend 2 outputs that you received in the same transaction as an input for a new ring signature transaction, these outputs can be linked together. For an observer it’s very likely that these 2 outputs are the real inputs of your transaction, making your ring signature obsolete.

An example will hopefully clarify what I mean. I’ll ignore the fees for simplicity.
Transaction X: Alice sends 123 XMR to Bob with mixin 5.
This means that Bob receives 3 separate outputs: 100 XMR, 20 XMR and 3 XMR
Transaction Y1: When Bob wants to send 3 XMR to Charlie, he just chooses his 3 XMR output as the input for transaction Y1. He chooses a mixin level so Alice can’t trace the 3 XMR. She doesn’t know for sure that Bob actually spent the 3 XMR she sent to him. Oliver the observer just sees a regular private XMR transaction. He can’t determine identities.
Transaction Y2: When Bob wants to send 23 XMR to Charlie, he could choose to use the 20 XMR and 3 XMR outputs as inputs for Y2. But this would not be a great choice: even if Bob uses a high mixin level, it will still be possible for  Oliver the observer (and thus also for Alice) to see that 2 outputs who were both the result of transaction X are used together in a new transaction. Even if Bob used mixin 100, this is still visible. What a coincidence! Oliver will conclude that those 20 XMR and 3 XMR are the real outputs. Alice will know that it was Bob who spent 23 XMR.  The state of the outputs isn’t uncertain anymore: we know the 20 XMR and 3 XMR are spent.
Transaction Z2: Dave sends 3 XMR to Eve. Dave uses mixin 1* and by accident picks as a fake input to mix with the 3 XMR Bob received in transaction X. When Dave sends his transaction, Oliver can see the 3 XMR input received by Bob is already spent in transaction Y2. This actually means that Oliver now knows that this input in Dave’s transaction is fake. So Oliver immediately knows the real input that is spent in Dave’s transaction, revealing the state of Dave’s 3 XMR.
Also note that if transaction Z2 happened before transaction Y2, Dave will still be private when he sends his transaction, but his privacy will be weakened when Bob sends transaction Y2. So transaction Y2 creates a “chain reaction privacy problem”.
*the XMR protocol enforces a minimum mixin of 2, making this “chain reaction privacy problem” in transaction Z2 less likely.
Transaction Y3: Bob wants to prevent that the state of his 20 XMR and 3 XMR is revealed when he spends them, so he decides to spend the 100 XMR he received from Alice instead. Charlie will still receive a 20 XMR and a 3 XMR output, but a 70 XMR and 7 XMR output will be sent back to Bob. At this point, the situation is exactly the same as in Transaction Y1: Alice doesn’t know for sure that Bob actually spent the 100 XMR she sent to him due to the mixin. Oliver just sees a regular private XMR transaction. He can’t determine identities.
But… Charlie now knows something: he can see that 77 XMR used as change and that this change is probably sent to Bob. So Charlie knows Bob owns at least 77 XMR. Bob can attach an identity to both the 70 XMR and 7 XMR outputs.
Transaction Z3: Bob now wants to send 75 XMR to Eve. If Bob only owns the 77 XMR he received as change, he now faces an even bigger problem: he can’t select just one output as an input for his transaction to Eve! Bob has no choice but to use both the 70 XMR and 7 XMR as inputs for his transaction to Eve. Eve will receive 70 XMR and 5 XMR and Bob will receive 2 XMR as change. Sending this transaction does a lot of damage to Bob’s privacy:
– Charlie knows that Bob has sent 77 XMR and that it’s very likely the 2 XMR output in transaction Z3 is change to Bob.
– Eve knows that Bob received 2 XMR as change and can attach his identity to those 2 XMR.
– Oliver sees that the 70 XMR and 7 XMR are spent, making it not desirable for every XMR user to mix with those.
– If Oliver accidentally already mixed with the 70 XMR or the 7 XMR before transaction Z3 happened, his privacy is now weakened. This can create new “chain reaction privacy problems”.

In a nutshell, if 2 outputs who originated from the same transaction are used as inputs in a new transaction, we now can assume that those 2 outputs are spent. This has 2 main consequences:
– Some people can know in certain circumstances that you have spent a certain amount of XMR.
– It’s possible that by random chance some people’s ring signature is weakened when such linked outputs are used for mixing in a new transaction.

So how can the hiding of the amounts in a transaction with RingCT potentially solve the “association by use of outputs within a transaction” and the related “chain reaction privacy problems”?

Well, if you understood the example, this is quite easy: A RingCT doesn’t require to be mixed with outputs with the same denomination. So when you send a transaction using RingCT, you can use arbitrary amounts. This means that in general, you would only have 2 outputs in a transaction: one output is sent to the receiver and another one is the change that is sent back to you.

This obviously makes it impossible to use 2 outputs who originated from the same transaction as inputs for a new transaction which was exactly the issue described at the start of this article. It also hides the change amount for the receiver. the receiver only knows you received change, but doesn’t know how much.

As you can see, RingCT solves a lot of edge cases for XMR and adds additional privacy to the balance of your XMR account!

Addendum:

Reddit user /u/mWo12 found this transaction: txid ea8bca898505b0c4b2ee9ff08d44ff8a2d60f0d397d8987fb68cd0ff11a88a15.

If you expand the inputs and check from which blocks the inputs originate, you’ll see 4 “ring members” of the 4 inputs coming from block 1015051.
All the inputs seem to be outputs in this transaction: txid bb4d4142ede8e9b32d1d9b81274cfa9d934b9d931faa521d6e6eab1bf917fff4.

It is very likely that the 4 outputs in transaction bb4d…fff4 are spent in transaction ea8b…8a15.
This results in a “chain reaction”. We now for example can assume that the 100 XMR txo with public key e3a8ef35175c931ec811bcc1667e66ab691ed1ca2d971e044b394d02a24f38ad is spent.

All other people mixing with this txo are not adding any “real” plausible deniability to their 100 XMR, because we already know it is spent. If someone only used this txo in the ring signature, his txo can also be considered spent, and so on and so forth…

 

ShapeShiftOpenAlias