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

[GingerAle]

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:

<-- 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://bitcointalk.org/index.php?topic=978447.msg10681892#msg10681892

https://bitcointalk.org/index.php?topic=978447.msg10682106#msg10682106

summarized in this quote for archival purposes:

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.

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.

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://bitcointalk.org/index.php?topic=978447.0

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

But I gotta go grab dinner now.

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

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

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.  

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.

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.

Those transactions are a bad example of what I was saying.
5bafee7a5397ad505658b1e37af812e64ebb2834601224e4f6f6675b4a25728b and http://explorer.darkcoin.io/tx/b4534361c8247abcc6b428fd85a17546f23413b2777f3e3f372578d100b20c4e aren't mixing rounds at all. It's clients creating darksend compatible inputs.

For example, this transaction http://explorer.darkcoin.io/tx/b649ff67a9863a9757049e6d6acc722043030b386d052f75839410f1f32bf3e5#i16 has 11 source transactions:

http://explorer.darkcoin.io/tx/396016fb9d48cd648cbd46df016614128ca6ff71451548a64ef7cfd1bd6b86df#o19
http://explorer.darkcoin.io/tx/7fdd4b736c9a9a78e5d09bdd5137c87af5d82c20035cbb4cbaf9970ea7f4b129#o45
http://explorer.darkcoin.io/tx/aa87251f58213e5999d56fcd80fc5d4ddab0317af76bcb58751756fc27e05f7a#o12
http://explorer.darkcoin.io/tx/7098889f50598e8e385e8f6108bcffbe4b9284165fb14f3d435c42a6fad50552#o50
http://explorer.darkcoin.io/tx/50ce277e21dda233620163d2818a4998280381c937681d5ca1617ebc4d95ff9b#o35
http://explorer.darkcoin.io/tx/b4534361c8247abcc6b428fd85a17546f23413b2777f3e3f372578d100b20c4e#o11
http://explorer.darkcoin.io/tx/e0891c5fbebb9547cd86858646883fcd2d889c5a1f000b680ea06581a987f9c2#o8
http://explorer.darkcoin.io/tx/8410744e1ab1f7a4e992031cd8f023fb00f65cf8271aecbe3aae0056c034cf99#o57
http://explorer.darkcoin.io/tx/e0891c5fbebb9547cd86858646883fcd2d889c5a1f000b680ea06581a987f9c2#o4

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

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

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

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

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.

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.

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

[1713971383]

1713971383

[xxxgoodgirls]

Thank you. Gonna watch this with much interest.

[gnargnar]

Good idea. The original thread is already 10 pages long and no sign of stopping. This new thread will help focusing and taking action

[GingerAle]

all right, im just gonna mod the original post with the conversation between EK and ED

[Ultros]

Thanks. Much better that way.

[stonehedge]

Moderated by a total neutral too.  Great idea.

[GingerAle]

Moderated by a total neutral too.  Great idea.

I hope that was genuine Because I am trying to be neutral, despite my association with Monero.

[billotronic]

thank you. that other thread makes my head hurt

[GingerAle]

Tips are welcome! Because I'm subjecting my head to the pain of that thread instead of you.

lets see... i have a bitcoin address somewhere...

16pJUsLr8B6d2ueL4gzL6XgcxiJKRxaUVS


Also, additional bounties are welcome. I'll add 50 XMR to it (I don't have much).. and specifically I'm supporting the bounty for the testnet version. Though this might have to wait until they release it on mainnnet? I dunno.

Also, if any people want to commit to testing said block explorer if it is developed, that'd be cool.