[DRK] Copy of Evil-Knievel's Darkcoin is NOT Anonymous? Moderated for clarity

I don't know if this is ok (mods, do what you will).

I'm copying the relevant points of Evil-Knievel's "Darkcoin is NOT anonymous?" thread in order to provide clarity. The original thread became cluttered with XMR v DRK talk, in addition to allegations of DRK's coin distribution.

I'm not doing this because I'm a fan of monero. I'm doing this because these technologies should be put to the test before anyone's lives are compromised due to claims of a technologies ability. I would hope that someone would do this with monero as well.

A bounty emerged from the previous thread. Here are the details so far:

Quote from: GingerAle on March 06, 2015, 06:42:12 PM

Quote from: qwizzie on March 06, 2015, 06:02:17 PM

<-- throws away his popcorn and wonders off

i'm hoping my bag of popcorn lasts long enough for evil-K's deanonymizer darkcoin explorer.

From my last count its up to a 2 BTC bounty.

https://bitcointalksearch.org/topic/m.10681892

https://bitcointalksearch.org/topic/m.10682106

summarized in this quote for archival purposes:

Quote from: RW-Stott on March 06, 2015, 12:20:09 PM

Quote from: Longenecker on March 06, 2015, 11:55:24 AM

We should set up a BTC donation fund for Evil-Knievel to build a Darkcoin python deanonymizer!

I pledge 1 BTC if Evil-Knievel successfully builds a Darkcoin python deanonymize.

I'll add another 1 BTC to that.

Quote from: GingerAle on March 06, 2015, 07:11:30 PM

Quote from: Evil-Knievel on March 06, 2015, 06:44:46 PM

If such fund is really established, I will add 1 BTC myself which should be distributed to the "supporters" if I should not be able to acheive such thing.

I don't know what you mean by established - as you can tell, my status is slightly above noob. I therefore do not know the ins and outs of bounties - for instance, if escrows are required etc. Though I'm assuming it may be difficult to find a mediator / third party thats not vested. If any of the die-hard bitcoiners are around (i.e., there's only 1 true coin), their volunteering would be appreciated. Darnit, where's my decentralized truth oracle blockchain when I need it?

I'm a man of science - and it looks like this is the crytpocurrencies equivalent of peer review.

But for those following, Evil-K has offered a 1 BTC counter-bounty.

Quote from: Evil-Knievel on March 06, 2015, 06:44:46 PM

If such fund is really established, I will add 1 BTC myself which should be distributed to the "supporters" if I should not be able to acheive such thing.

I'm assuming the way this functions is 1 BTC will be distributed amongst those offering a bounty in the case that Evil-Knievel doesn't make a Darkcoin De-privatization Explorer.

May I also present that this explorer should work on the latest "patch" as well - whatever the DRK devs are referring to as masternode blinding.

Also, hopefully the XMR v DRK has died down - but if not, here's a thread
https://bitcointalk.org/index.php?topic=962235.240;topicseen

Please - this thread is about DRK's privacy technology - not alleged coin distribution problems.

So far, Evil-Knievel has not agreed to the bolded statement above.

I will eventually link to the relevant posts from the main thread.
https://bitcointalksearch.org/topic/this-message-was-too-old-and-has-been-purged-978447

If any conversation beyond DRK privacy technology arises, I will delete it.

But I gotta go grab dinner now.

-----------------------------------------------------------

Quote from: Evil-Knievel on March 06, 2015, 09:09:25 AM

Here I will tell you, how I think one can deanonymize every single darksend transaction from beginning of Darkcoin up to now.
Maybe someone of you guys can comment on this!

1. Step, let us say you want to deanonymize this transaction. This is a typical darksend transaction in the middle of the dark send process.
http://explorer.darkcoin.io/tx/9ad01adae3814abf9a9731f0003d95a0f9bf701d055152f7b54ee4b6be47bfca#o2

Now the only problem, that disallows us to know who send the coins where is,
because the outputs were shuffled and we no longer know which input corresponds to which output.
This is basically how "coin join" works.

Here comes the trick, how you can actually reassemble the original order of the elements and thus DEANONYMIZE the whole thing.

2. Step, recreating the original order

This step has to be done for every transaction in the redeemed fields of this transaction. We do this example for only one of them. You have to repeat then.
First of all, you can see which outputs most likely belong together, as they were spent in the same transaction.
e48b08b091... for example originally belonged most likely to one person, as the others did their subsequent round of coinjoin using a different master server.
However we do not know for sure.

Let us take a look into this transaction:

Now the fun thing comes, due to the nature of coin join, the inputs are now in the correct order, meaning inputs from one and the same person appear below as they are submitted in batches to the master node and then the masternode sequentially adds them to the transaction it is constructing.

Now we can search where the previous transaction hash appeared in the inputs - namely HERE:

Code:

0 	9ad01adae3...:5 	100.001 	Xxa6tei6bJ23VsSsbrN7rtjTh9QeXxTQLP 	72:3045...5a81 33:02ec...9eeb
1 	9ad01adae3...:1 	100.001 	XqzU22tys4HuJui2375B8ZpwUkDjYu5pMW 	71:3044...7e81 33:023b...bb2c
2 	9ad01adae3...:19 	100.001 	Xo29XWGNpJUiccCikM83RjQijsYxjYfToR 	71:3044...e981 33:0344...6726
3 	9ad01adae3...:17 	100.001 	Xb9VbtEu2SxamS7E4UmZwUJMKHcx7KEjL4 	72:3045...8081 33:02c1...119a
4 	9ad01adae3...:9 	100.001 	Xk3NJj5qvxv8Sen7syPP3Ld94DKumCaBe4 	72:3045...1581 33:0337...ce01
5 	9ad01adae3...:11 	100.001 	Xd4RSLiLGnxVmyZxzU6Cm931o24M8xFYXA 	72:3045...e981 33:036e...524b
6 	9ad01adae3...:8 	100.001 	XuLPnFQL99oHJQA7JVQqB4dxs983ZnfnPp 	71:3044...5a81 33:026d...d4b0
7 	9ad01adae3...:4 	100.001 	XhDJWj3WRbvKZKbkHGXA5VawPiim5o71b7 	71:3044...fb81 33:0264...8c60
8 	9ad01adae3...:13 	100.001 	Xd2TE5n8pkfh5NxCn88asQHpJMhTgjnm9z 	72:3045...4881 33:0203...3a83
9 	9ad01adae3...:12 	100.001 	XvtGzXSAyGefgwmSeny5SdTk8qUqd71JMN 	71:3044...ba81 33:0287...f8d2
10 	9ad01adae3...:10 	100.001 	XsdwsxQBiWWTw1BzVjH1cMdoCYjXNuMEGk 	71:3044...c881 33:020b...a057
11 	9ad01adae3...:3 	100.001 	XvpTpEMrEgGVgg7TMWnhH2e2njNkiAVEHu 	72:3045...6481 33:0341...53cb
12 	9ad01adae3...:15 	100.001 	XhE9NUbzP7bkJyrmgPkJeektVWZSPuRHdw 	71:3044...5581 33:0255...8d8f

Here we know that the outputs from the old transaction, which were at indices (5,1,19,17,9,11, and so on) were originally sorted in this order.
EDIT: additionally we know, that the outputs who here are "not yet redeemed" belong to an individual who has ended the dark-send process in this transaction. Here he did his last round.

3. Step

Go back to the original transaction, and sort these 13 outputs in the correct order.
Repeat this with all other transactions to receive the correct order of the inputs.

4. Step
Now you have n blocks which themselves are sorted correctly, however we do not know which order the block came in.
In this case it is harder because everyone put the same amout into coin join.
Actually, when you have different denominations and different amounts, there is only one way to put the blocks together.
Here, as all inputs are 100 DRK, we have to go further, and check the sub-sub sequent and previous transaction.

THIS WAY YOU CAN SUCCESSIVELY ESTABLISH THE ORIGINAL ORDER OF THE DARK SEND OUTPUTS WHICH ESSENTIALLY MEANS NO ANONYMIZATION AT ALL. THEN IT IS JUST A SIMPLE TRANSACTION WITH NO OBSCURITY

Quote from: eduffield on March 06, 2015, 10:42:14 AM

Interesting approach, although the input order isn't random, it's randomly generated from multiple transactions on the client side. Even if it was completely not random, that doesn't allow you to "jump" the mixing transaction and know which outputs belong to which inputs.

Source TX:

http://explorer.darkcoin.io/tx/9ad01adae3814abf9a9731f0003d95a0f9bf701d055152f7b54ee4b6be47bfca:

Notice the inputs reference 5 transactions, but there's 3 participants. You can't tell where one stops and the next begins. Also, it's possible that multiple clients in this transaction were actually in 5bafee7a5397ad505658b1e37af812e64ebb2834601224e4f6f6675b4a25728b or b4534361c8247abcc6b428fd85a17546f23413b2777f3e3f372578d100b20c4e for example.

http://explorer.darkcoin.io/tx/5bafee7a5397ad505658b1e37af812e64ebb2834601224e4f6f6675b4a25728b#o39
http://explorer.darkcoin.io/tx/b4534361c8247abcc6b428fd85a17546f23413b2777f3e3f372578d100b20c4e#o40
http://explorer.darkcoin.io/tx/1c1769d578f4632971dd699987931cf676a7356196a5b122c60d737fce3c836e#o76
http://explorer.darkcoin.io/tx/7e452c1c5229fbbfdc1b4fc1d8577a6b9d0932bf5f00030d28ec7759dd9273ea#o61
http://explorer.darkcoin.io/tx/3fba31e9cc32cd5e2c002ad4a8bd6908f3a76321e2d892f046265eb14352676e#o60

One more thing to note is that after coins are mixed through multiple sessions, there are "final" outputs that are just spent randomly. That can happen in any session, which causes more randomness. You most definitely can't map those randomly spent outputs to the inputs at all. That's what you should be trying to do, you need to be able to show anonymously spent coins and their original source funds.

Nice try though

PS. If you believe it's really a weakness you need to map the outputs to the inputs and show who's anonymously spending money on what. I'm not sure it's worth the time though, because masternode blinding randomizes the input order anyway.

Quote from: Evil-Knievel on March 06, 2015, 10:48:34 AM

Quote from: eduffield on March 06, 2015, 10:42:14 AM

Notice the inputs reference 5 transactions, but there's 3 participants. You can't tell where one stops and the next begins. Also, it's possible that multiple clients in this transaction were actually in 5bafee7a5397ad505658b1e37af812e64ebb2834601224e4f6f6675b4a25728b or b4534361c8247abcc6b428fd85a17546f23413b2777f3e3f372578d100b20c4e for example.

I do not agree on this actually.

From the transaction 5bafee... for example you can be sure that the inputs belong to one person only, as there is only one change output in the outputs list. (2 people would indicate two change outputs).
Other input transactions can be analyzed the same way.

Quote from: eduffield on March 06, 2015, 11:00:49 AM

Quote from: Evil-Knievel on March 06, 2015, 10:48:34 AM

Quote from: eduffield on March 06, 2015, 10:42:14 AM

Quote from: Evil-Knievel on March 06, 2015, 11:08:22 AM

Quote from: eduffield on March 06, 2015, 11:00:49 AM

It's possible that 1-3 participants are submitting funds from 4a067e00c76ccb554638c0d14d20e8f501f094ce9093fbf598c358c0835d77e5,
it's impossible to tell otherwise.

Then I just made the impossible possible,
I know that these are exactly 2 people.

When looking at
http://explorer.darkcoin.io/tx/b649ff67a9863a9757049e6d6acc722043030b386d052f75839410f1f32bf3e5

There are exactly two sorted blocks from the 4a06 transaction appearing in the sorted input list of b649ff... which do not appear directly under each other
They must have been submitted from two different people at two different times.

Code:

7 	4a067e00c7...:59 	0.100001 	XgVS4zvMm4ikZDtN2DSFgSgrrTrD2w5pq5 	71:3044...8081 33:03f3...d69d
8 	4a067e00c7...:11 	1.00001 	XmAEq7k7n2spMATZbN2CpyPT6U4hNiefbr 	72:3045...b981 33:03c4...ab69
9 	4a067e00c7...:41 	1.00001 	XmnDvUgBM8kQze5RATyozfkA9bazyWQ1W3 	71:3044...2181 33:021a...a289

and

Code:

12 	4a067e00c7...:55 	1.00001 	XvaXzvnWTwHRMfzLricVyxa3FtMqJvohRR 	72:3045...8881 33:02b1...33f4
13 	4a067e00c7...:20 	0.100001 	XmHZ4DvHbBLmrHTHWCXYahp4n2SfnxWugt 	72:3045...f081 33:02dd...b541
14 	4a067e00c7...:50 	1.00001 	XbXrsJLGZSeW839LEHQh4K8HS7AvDRXjr6 	71:3044...2d81 33:0231...538f
15 	4a067e00c7...:7 	0.100001 	XxdCZkeNWnUzkQfG13greKNXEzzQFwzxx9 	72:3045...5681 33:0358...d9ea
16 	4a067e00c7...:3 	0.100001 	XqvRbqBQMtxRdQMpJCCY3qYT62USrZtAqw 	72:3045...ef81 33:0271...3602

Quote from: eduffield on March 06, 2015, 11:23:46 AM

Quote from: Evil-Knievel on March 06, 2015, 11:08:22 AM

Quote from: eduffield on March 06, 2015, 11:00:49 AM

It's possible that 1-3 participants are submitting funds from 4a067e00c76ccb554638c0d14d20e8f501f094ce9093fbf598c358c0835d77e5,
it's impossible to tell otherwise.

Code:

7 	4a067e00c7...:59 	0.100001 	XgVS4zvMm4ikZDtN2DSFgSgrrTrD2w5pq5 	71:3044...8081 33:03f3...d69d
8 	4a067e00c7...:11 	1.00001 	XmAEq7k7n2spMATZbN2CpyPT6U4hNiefbr 	72:3045...b981 33:03c4...ab69
9 	4a067e00c7...:41 	1.00001 	XmnDvUgBM8kQze5RATyozfkA9bazyWQ1W3 	71:3044...2181 33:021a...a289

and

Code:

12 	4a067e00c7...:55 	1.00001 	XvaXzvnWTwHRMfzLricVyxa3FtMqJvohRR 	72:3045...8881 33:02b1...33f4
13 	4a067e00c7...:20 	0.100001 	XmHZ4DvHbBLmrHTHWCXYahp4n2SfnxWugt 	72:3045...f081 33:02dd...b541
14 	4a067e00c7...:50 	1.00001 	XbXrsJLGZSeW839LEHQh4K8HS7AvDRXjr6 	71:3044...2d81 33:0231...538f
15 	4a067e00c7...:7 	0.100001 	XxdCZkeNWnUzkQfG13greKNXEzzQFwzxx9 	72:3045...5681 33:0358...d9ea
16 	4a067e00c7...:3 	0.100001 	XqvRbqBQMtxRdQMpJCCY3qYT62USrZtAqw 	72:3045...ef81 33:0271...3602

I think you're misunderstanding the random behavior of the client. It takes multiple transactions and submits them like this. Masternode blinding makes this whole conversation meaningless though, inputs will be random.

Something like this:

(This isn't deanonymizing the TX, I don't know who submitted what, it's just an example)
Client 1:

Code:

0	396016fb9d...:19	0.100001	XmEdFdQi99xwqn4SvZ47GQTgGWrwr8wGCj	72:3045...ad81 33:0322...86ef
1	7fdd4b736c...:45	1.00001	Xrw1JYmX2DgQ3GZ6g4EzpqigWrN7PFgmre	71:3044...ac81 33:039e...cee5
2	396016fb9d...:21	0.100001	XhyqpyLSRFWQrP2LuZup5XqZQ7o5qP4jvq	71:3044...8c81 33:0261...21a2
3	aa87251f58...:12	10.0001	Xg9cD2y8UVviaFLst3xESqt1gNPzfHxq25	72:3045...e881 33:02a8...6d95
4	7098889f50...:50	0.100001	XqKzxHmJT1V2p4mUFQVp4tRMoKuiY5ooTU	72:3045...ed81 33:02fe...8220
5	50ce277e21...:35	0.100001	Xged1P2SQ9Ntdb4yFxpiMHmuDCUkFbcwwS	71:3044...f881 33:02bf...eda9
6	b46f161497...:13	0.100001	Xyrz9y6J7633ZMRdsh7r5gY9ZVjQLRr9UL	72:3045...e981 33:023e...07d2
7	4a067e00c7...:59	0.100001	XgVS4zvMm4ikZDtN2DSFgSgrrTrD2w5pq5	71:3044...8081 33:03f3...d69d
8	4a067e00c7...:11	1.00001	XmAEq7k7n2spMATZbN2CpyPT6U4hNiefbr	72:3045...b981 33:03c4...ab69
9	4a067e00c7...:41	1.00001	XmnDvUgBM8kQze5RATyozfkA9bazyWQ1W3	71:3044...2181 33:021a...a289
10	b4534361c8...:23	1.00001	Xmi5ZRQUhV5eBicMYg3kLeVtgUYFtdPuco	72:3045...0381 33:0364...0ed3
11	b4534361c8...:11	0.100001	XvjDt1hjmNeX8Te2BSHMMrx794S3RW2UBh	72:3045...5681 33:03fb...f75f
12	4a067e00c7...:55	1.00001	XvaXzvnWTwHRMfzLricVyxa3FtMqJvohRR	72:3045...8881 33:02b1...33f4
13	4a067e00c7...:20	0.100001	XmHZ4DvHbBLmrHTHWCXYahp4n2SfnxWugt	72:3045...f081 33:02dd...b541

Client 2

Code:

14	4a067e00c7...:50	1.00001	XbXrsJLGZSeW839LEHQh4K8HS7AvDRXjr6	71:3044...2d81 33:0231...538f
15	4a067e00c7...:7	0.100001	XxdCZkeNWnUzkQfG13greKNXEzzQFwzxx9	72:3045...5681 33:0358...d9ea
16	4a067e00c7...:3	0.100001	XqvRbqBQMtxRdQMpJCCY3qYT62USrZtAqw	72:3045...ef81 33:0271...3602
17	b4534361c8...:30	10.0001	XfKGmCRBgC7ihLjyLhu3yjcvyobZNXof96	71:3044...6281 33:0317...a427
18	e0891c5fbe...:8	0.100001	XjvmB3XF6tfQW4TpZHFmmb5VpSdJfz63VU	71:3044...3881 33:0342...8b7b
19	9d96213345...:22	1.00001	XwUav8pZke2CJCBwZNQJwQVqcsVfLT9J13	71:3044...1981 33:0303...94ca
20	9d96213345...:27	10.0001	XcCvifmjfKvqNSpF83k61QyEosAQaWTRAg	72:3045...d981 33:0206...99ac

Client 3

Code:

21	8410744e1a...:57	0.100001	Xkj7CsXf9umYCTGSXH36UMV15Uyb4bFR1Z	71:3044...b981 33:0357...185e
22	e0891c5fbe...:1	0.100001	XbNQNmpa7ewvXkx6hrZH6bnJd7u5wNxB6S	71:3044...e081 33:020e...afa2
23	8410744e1a...:37	0.100001	XtDvF85gLNht6hKJpTFqgttYLimp3QfTti	71:3044...9381 33:03dc...7413
24	396016fb9d...:49	0.100001	Xs677i24pRnNFDdTXJNdwRiD9Vxx9HqUsb	72:3045...3f81 33:0313...0491
25	e0891c5fbe...:4	1.00001	XvUis97P6tRiWKCwF7cKf2DdsNfhGhEELg	72:3045...2881 33:032d...386c

Example 2:

Client 1:

Code:

0	396016fb9d...:19	0.100001	XmEdFdQi99xwqn4SvZ47GQTgGWrwr8wGCj	72:3045...ad81 33:0322...86ef
1	7fdd4b736c...:45	1.00001	Xrw1JYmX2DgQ3GZ6g4EzpqigWrN7PFgmre	71:3044...ac81 33:039e...cee5
2	396016fb9d...:21	0.100001	XhyqpyLSRFWQrP2LuZup5XqZQ7o5qP4jvq	71:3044...8c81 33:0261...21a2
3	aa87251f58...:12	10.0001	Xg9cD2y8UVviaFLst3xESqt1gNPzfHxq25	72:3045...e881 33:02a8...6d95
4	7098889f50...:50	0.100001	XqKzxHmJT1V2p4mUFQVp4tRMoKuiY5ooTU	72:3045...ed81 33:02fe...8220
5	50ce277e21...:35	0.100001	Xged1P2SQ9Ntdb4yFxpiMHmuDCUkFbcwwS	71:3044...f881 33:02bf...eda9
6	b46f161497...:13	0.100001	Xyrz9y6J7633ZMRdsh7r5gY9ZVjQLRr9UL	72:3045...e981 33:023e...07d2
7	4a067e00c7...:59	0.100001	XgVS4zvMm4ikZDtN2DSFgSgrrTrD2w5pq5	71:3044...8081 33:03f3...d69d
8	4a067e00c7...:11	1.00001	XmAEq7k7n2spMATZbN2CpyPT6U4hNiefbr	72:3045...b981 33:03c4...ab69

Client 2

Code:

9	4a067e00c7...:41	1.00001	XmnDvUgBM8kQze5RATyozfkA9bazyWQ1W3	71:3044...2181 33:021a...a289
10	b4534361c8...:23	1.00001	Xmi5ZRQUhV5eBicMYg3kLeVtgUYFtdPuco	72:3045...0381 33:0364...0ed3
11	b4534361c8...:11	0.100001	XvjDt1hjmNeX8Te2BSHMMrx794S3RW2UBh	72:3045...5681 33:03fb...f75f
12	4a067e00c7...:55	1.00001	XvaXzvnWTwHRMfzLricVyxa3FtMqJvohRR	72:3045...8881 33:02b1...33f4
13	4a067e00c7...:20	0.100001	XmHZ4DvHbBLmrHTHWCXYahp4n2SfnxWugt	72:3045...f081 33:02dd...b541
14	4a067e00c7...:50	1.00001	XbXrsJLGZSeW839LEHQh4K8HS7AvDRXjr6	71:3044...2d81 33:0231...538f
15	4a067e00c7...:7	0.100001	XxdCZkeNWnUzkQfG13greKNXEzzQFwzxx9	72:3045...5681 33:0358...d9ea
16	4a067e00c7...:3	0.100001	XqvRbqBQMtxRdQMpJCCY3qYT62USrZtAqw	72:3045...ef81 33:0271...3602
17	b4534361c8...:30	10.0001	XfKGmCRBgC7ihLjyLhu3yjcvyobZNXof96	71:3044...6281 33:0317...a427

Client 3

Code:

18	e0891c5fbe...:8	0.100001	XjvmB3XF6tfQW4TpZHFmmb5VpSdJfz63VU	71:3044...3881 33:0342...8b7b
19	9d96213345...:22	1.00001	XwUav8pZke2CJCBwZNQJwQVqcsVfLT9J13	71:3044...1981 33:0303...94ca
20	9d96213345...:27	10.0001	XcCvifmjfKvqNSpF83k61QyEosAQaWTRAg	72:3045...d981 33:0206...99ac
21	8410744e1a...:57	0.100001	Xkj7CsXf9umYCTGSXH36UMV15Uyb4bFR1Z	71:3044...b981 33:0357...185e
22	e0891c5fbe...:1	0.100001	XbNQNmpa7ewvXkx6hrZH6bnJd7u5wNxB6S	71:3044...e081 33:020e...afa2
23	8410744e1a...:37	0.100001	XtDvF85gLNht6hKJpTFqgttYLimp3QfTti	71:3044...9381 33:03dc...7413
24	396016fb9d...:49	0.100001	Xs677i24pRnNFDdTXJNdwRiD9Vxx9HqUsb	72:3045...3f81 33:0313...0491
25	e0891c5fbe...:4	1.00001	XvUis97P6tRiWKCwF7cKf2DdsNfhGhEELg	72:3045...2881 33:032d...386c

Example 3:

Client 1:

Code:

0	396016fb9d...:19	0.100001	XmEdFdQi99xwqn4SvZ47GQTgGWrwr8wGCj	72:3045...ad81 33:0322...86ef
1	7fdd4b736c...:45	1.00001	Xrw1JYmX2DgQ3GZ6g4EzpqigWrN7PFgmre	71:3044...ac81 33:039e...cee5
2	396016fb9d...:21	0.100001	XhyqpyLSRFWQrP2LuZup5XqZQ7o5qP4jvq	71:3044...8c81 33:0261...21a2
3	aa87251f58...:12	10.0001	Xg9cD2y8UVviaFLst3xESqt1gNPzfHxq25	72:3045...e881 33:02a8...6d95

Client 2

Code:

4	7098889f50...:50	0.100001	XqKzxHmJT1V2p4mUFQVp4tRMoKuiY5ooTU	72:3045...ed81 33:02fe...8220
5	50ce277e21...:35	0.100001	Xged1P2SQ9Ntdb4yFxpiMHmuDCUkFbcwwS	71:3044...f881 33:02bf...eda9
6	b46f161497...:13	0.100001	Xyrz9y6J7633ZMRdsh7r5gY9ZVjQLRr9UL	72:3045...e981 33:023e...07d2
7	4a067e00c7...:59	0.100001	XgVS4zvMm4ikZDtN2DSFgSgrrTrD2w5pq5	71:3044...8081 33:03f3...d69d
8	4a067e00c7...:11	1.00001	XmAEq7k7n2spMATZbN2CpyPT6U4hNiefbr	72:3045...b981 33:03c4...ab69
9	4a067e00c7...:41	1.00001	XmnDvUgBM8kQze5RATyozfkA9bazyWQ1W3	71:3044...2181 33:021a...a289
10	b4534361c8...:23	1.00001	Xmi5ZRQUhV5eBicMYg3kLeVtgUYFtdPuco	72:3045...0381 33:0364...0ed3

Client 3

Code:

11	b4534361c8...:11	0.100001	XvjDt1hjmNeX8Te2BSHMMrx794S3RW2UBh	72:3045...5681 33:03fb...f75f
12	4a067e00c7...:55	1.00001	XvaXzvnWTwHRMfzLricVyxa3FtMqJvohRR	72:3045...8881 33:02b1...33f4
13	4a067e00c7...:20	0.100001	XmHZ4DvHbBLmrHTHWCXYahp4n2SfnxWugt	72:3045...f081 33:02dd...b541
14	4a067e00c7...:50	1.00001	XbXrsJLGZSeW839LEHQh4K8HS7AvDRXjr6	71:3044...2d81 33:0231...538f
15	4a067e00c7...:7	0.100001	XxdCZkeNWnUzkQfG13greKNXEzzQFwzxx9	72:3045...5681 33:0358...d9ea
16	4a067e00c7...:3	0.100001	XqvRbqBQMtxRdQMpJCCY3qYT62USrZtAqw	72:3045...ef81 33:0271...3602
17	b4534361c8...:30	10.0001	XfKGmCRBgC7ihLjyLhu3yjcvyobZNXof96	71:3044...6281 33:0317...a427
18	e0891c5fbe...:8	0.100001	XjvmB3XF6tfQW4TpZHFmmb5VpSdJfz63VU	71:3044...3881 33:0342...8b7b
19	9d96213345...:22	1.00001	XwUav8pZke2CJCBwZNQJwQVqcsVfLT9J13	71:3044...1981 33:0303...94ca
20	9d96213345...:27	10.0001	XcCvifmjfKvqNSpF83k61QyEosAQaWTRAg	72:3045...d981 33:0206...99ac
21	8410744e1a...:57	0.100001	Xkj7CsXf9umYCTGSXH36UMV15Uyb4bFR1Z	71:3044...b981 33:0357...185e
22	e0891c5fbe...:1	0.100001	XbNQNmpa7ewvXkx6hrZH6bnJd7u5wNxB6S	71:3044...e081 33:020e...afa2
23	8410744e1a...:37	0.100001	XtDvF85gLNht6hKJpTFqgttYLimp3QfTti	71:3044...9381 33:03dc...7413
24	396016fb9d...:49	0.100001	Xs677i24pRnNFDdTXJNdwRiD9Vxx9HqUsb	72:3045...3f81 33:0313...0491
25	e0891c5fbe...:4	1.00001	XvUis97P6tRiWKCwF7cKf2DdsNfhGhEELg	72:3045...2881 33:032d...386c

Quote from: Evil-Knievel on March 06, 2015, 11:27:02 AM

Okay, agreed on this.
However, as you have provided the original outputs sent by the clients we see that we at least have the correct order of them.
And the point is that I do not think that it is important to know whether it is 1,2 or 3 people. As long as we have the correct order, all three trails will eventually lead to the originator.

I am pretty sure that a transaction deanonymizer, which does this order reversal, could walk his way all the way back to the transactions where people started to denominating their funds, and get the # of users from the change outputs.

Also, what I just thought, you can surely know which outputs belong together. Its just a little bit of bruteforce work from now on.

As you said, those input belong together:

0 396016fb9d...:19 0.100001 XmEdFdQi99xwqn4SvZ47GQTgGWrwr8wGCj 72:3045...ad81 33:0322...86ef 1 7fdd4b736c...:45 1.00001 Xrw1JYmX2DgQ3GZ6g4EzpqigWrN7PFgmre 71:3044...ac81 33:039e...cee5 2 396016fb9d...:21 0.100001 XhyqpyLSRFWQrP2LuZup5XqZQ7o5qP4jvq 71:3044...8c81 33:0261...21a2 3 aa87251f58...:12 10.0001 Xg9cD2y8UVviaFLst3xESqt1gNPzfHxq25 72:3045...e881 33:02a8...6d95 4 7098889f50...:50 0.100001 XqKzxHmJT1V2p4mUFQVp4tRMoKuiY5ooTU 72:3045...ed81 33:02fe...8220 5 50ce277e21...:35 0.100001 Xged1P2SQ9Ntdb4yFxpiMHmuDCUkFbcwwS 71:3044...f881 33:02bf...eda9 6 b46f161497...:13 0.100001 Xyrz9y6J7633ZMRdsh7r5gY9ZVjQLRr9UL 72:3045...e981 33:023e...07d2 7 4a067e00c7...:59 0.100001 XgVS4zvMm4ikZDtN2DSFgSgrrTrD2w5pq5 71:3044...8081 33:03f3...d69d 8 4a067e00c7...:11 1.00001 XmAEq7k7n2spMATZbN2CpyPT6U4hNiefbr 72:3045...b981 33:03c4...ab69 9 4a067e00c7...:41 1.00001 XmnDvUgBM8kQze5RATyozfkA9bazyWQ1W3 71:3044...2181 33:021a...a289 10 b4534361c8...:23 1.00001 Xmi5ZRQUhV5eBicMYg3kLeVtgUYFtdPuco 72:3045...0381 33:0364...0ed3 11 b4534361c8...:11 0.100001 XvjDt1hjmNeX8Te2BSHMMrx794S3RW2UBh 72:3045...5681 33:03fb...f75f 12 4a067e00c7...:55 1.00001 XvaXzvnWTwHRMfzLricVyxa3FtMqJvohRR 72:3045...8881 33:02b1...33f4 13 4a067e00c7...:20 0.100001 XmHZ4DvHbBLmrHTHWCXYahp4n2SfnxWugt 72:3045...f081 33:02dd...b541

The blocks of the same color are in the correct order.
The only open question is which of the blocks comes first, which second.
For this we have 10*9*8*7*6*5*4*3*2 possibilities,

SO TO CHECK HOW THE OUTPUTS WERE ORDERED IN THE PREVIOUS TRANSACTION
... we have to think.

If the first input in the last transaction had a value of 0.10, only 5 of these blocks are candidates to come first.
... and so on!

It is really easy and in a simple python test most transactions could be uncovered this way.

Quote from: eduffield on March 06, 2015, 11:32:25 AM

Quote from: Evil-Knievel on March 06, 2015, 11:27:02 AM

You should try to build the python deanonymizer. I'd like to see what kind of results you get.

Topic: [DRK] Copy of Evil-Knievel's Darkcoin is NOT Anonymous? Moderated for clarity (Read 1328 times)