18:51:42 /window 12 18:58:51 Dear sirs: 18:58:51 I extend the most convivial greetings to all. 18:58:51 Today I wanted to ascertain whether the use of multiple inputs could present a challenge to the ring signature scheme used by Monero. Consider the following: Alice wishes to send 1 XMR to another individual, Bob. Bob is a new user. For whatever reason, Alice decides to split up the 1 XMR into 10 individual outputs of 0.1 XMR. Alice subsequently transmits the transaction over the internet. After some time, the transaction is embedded into the 18:58:51 next block. 18:58:52 If Bob decides to spend an amount exceeding 0.1 XMR, two outputs of the prior transaction will be required as inputs. For example, if Bob sends 0.45 XMR, five outputs of his transaction with Alice will be spent. Naturally, Monero aptly selects numerous decoys (fifty). However, it remains true still that his transaction with Alice will appear five times, each time referencing another output of Alice's transaction, making correlational 18:58:57 inferences about the transactional history very plausible. Naturally, what happened before Alice's transaction remains unaffected. 18:59:00 I wrote a Python script to ascertain the gravity of the situation. It is available here: https://pastebin.com/BWZexpnu 18:59:03 When scanning the Monero blockchain from blocks 1990000 to 2016257, I found that of 287,192 transactions in total, 170,612 had more than one "proper" input (not counting decoys). Of those transactions, 7,373 (4%) referenced the same output transaction more than once as inputs/decoys, making the inference that the new transaction in fact derives from certain given outputs extremely likely and indeed reducing the power of the ring signature 18:59:08 scheme. 18:59:10 I am certain that you have previously considered this issue at length and that it has been discussed intensely, and that the conclusion was drawn that no further action is necessary. That I am posting here today is nothing more than an acknowledgment of my ignorance of your discussions, for which I apologize. Nevertheless, I wished to ensure that you are aware of this minor fact, and that Monero through its strong privacy protections remains 18:59:17 money of the people, by the people, and for the people. 18:59:19 Best regards, 18:59:21 SeventhAlpaca 19:03:08 You are right. The wallet warns when this happens, you can send an output to yourself and spend later, breaking the connection (though you could still have heuristics looking at a distance). 19:03:47 The wallet will also try to select inputs which aren't connected this way if it can, but it's not always possible (ie, if the only outputs you have are Alice's). 19:06:34 The long standing defense against this is the vague concept of "churning", which is a bodge, and not at all well defined. But basically sending to yourself like I said above. 19:06:37 but 4% is a lot 19:06:49 there is another way 19:07:12 you could select other txs with multi outputs as decoys in your tx 19:07:36 The wallet could plausibly scan history itself to make better picks based on each coins's history. It does not do so now. Like for instance not selecting change from a tx to Carol when sending back to Carol, etc. 19:07:57 You mean select outputs from txes which have more than two outs ? 19:08:56 yes lets say you got 10x 0.1 xmr and do a sweep all then you would know the key images that were used in this txs but if you select other decoys which are all part of another multi out txs there is no way in knowing 19:08:56 Feel free to suggest this and the attached reasoning to MRL. surae in particular is currently working on analyzing that problem. 19:09:04 Thank you. These are some very good points. If several outputs from individual txs were used as decoys, this would break the correlational connection (or at least make it worthless as it could not be determined who's who). 19:09:31 I didn't know that the wallet warns about this. Awesome! 19:17:02 Making inferences about true signers based on cross-input correlations is a known issue that's difficult to mitigate with small anonymity set sizes 19:17:18 The use of larger sets and/or binned inputs can be useful 19:17:26 but this does not solve everything, of course 19:34:27 Are you sure that the wallet warns about that? I just tested this on the cli wallet and there does not appear to be a warning (at least not before I confirm with "Y".) 19:38:05 I'm sure there is one for what I understood you to be saying :) 19:38:51 If you spend two outputs A and B, A was created at height HA, B at HB, and the difference HA and HB is less than 10. 19:39:08 Is that what you were saying ? HA==HB in your case. 19:41:44 i think he means if you receive a transaction with 10outputs and you do a sweep all now your tx contains all outputs in 10rings containing 11members but you can correlate the origin transaction with the sweep transaction 19:42:35 Thanks, Paule! Yes. So, in essence, that the same transaction id appars in several rings of a new tx. 19:42:37 and he says it happens in 4% of the time 19:46:15 Found it. You have to have print-ring-members set, and it seems to default to false. 19:47:04 "Warning: Some input keys being spent are from the same transaction, which can break the anonymity of ring signature. Make sure this is intentional!" 19:47:17 Thanks, moneromooo. That's a great option, and a great warning also! 19:47:55 I'll make it do the check regardless of the option. Thanks for making me find that. 19:48:50 Of course. And thank *you*! 20:05:04 SeventhAlpaca this article describes the same thing https://medium.com/@crypto_ryo/on-chain-tracking-of-monero-and-other-cryptonotes-e0afc6752527 20:14:20 Thanks, koe! 20:18:09 6301 23:41:36 I'm not convined that 4% intersection means anything. 23:42:04 Decoys are weighted toward recent so a fair bit of intersection on recent txs is expected. Exactly numbers I don't know 23:42:35 The older the tx with multiple outputs being used the less likely it is random, but again real numbers would need more work 23:45:25 The idea of deliberately sending multiple outputs in one tx as a form of a attack is worth considering 23:45:48 Maybe the wallet should warn about *that* and consider remedial measures