What I'm saying is that if 150 DRK from different sources goes in at hop 1, unless the exact same amount goes back out at hop 3/4/5/6/7, I'm not sure I understand how they can be associated. You'd have non-associated inputs at hop 2, 3, 4, 5 and outputs which may or may not be associated at 3, 4, 5, 6, 7 and 8. Actually, even if 150 DRK did go back out at hop 7, given the other inputs at different mixing depths input at 2/3/4/5, how could you prove that it wasn't a coincidental permutation of some combination of inputs from hops 1,2,3,4 and 5?
Each of those units from which the 150 aggregate is made looks like this:
1+1+1+1+1+1+1+5+5+5+5+5+5+5+5+5+5+10+10+10+10+10+10... You get the idea. It adds up to the 150.
But, each one was either signed or TXed, wasn't it?
So, I can pick out, using that metric, where those individual chunks came from:
1+1+1+1+1+1+1+
5+5+5+5+5+5+
5+5+5+5+10+10+
10+10+10+10...
So, it's not a blind 150 input! They had to prove to the network that they had a claim to those chunks they sent in, right? Otherwise anyone could just spend all the coin they wanted! They sign it. I can sign every message I post on this forum with my PGP key. Every sig will look different, but PGP will tell YOU that they match my pubkey, which I gave you. It's a pubkey...
We can tell that ever red chunk belongs to the same sender. Aggregate the red chunks, we have the total value.
We wait for X blocks, ignoring the mix altogether.
There will be a future TX in which we can aggregate this value again, and it'll also be going to a common pubkey/address which we can find the same way! The address has to be put in the blockchain, doesn't it? It doesn't stay unknown to the network AFTER it gets used, that'd unravel the whole game...
Currently, we know it will be 8 cycles or less, so that makes it way easier to find than if we had no idea.
I'm suggesting a way to blur that. Whether my idea for blurring that be a good one or not, I don't know. I just know it needs to be blurred.