11:15:22 <endor00[m]> Do wallets check other transactions in the mempool when picking decoys for a new tx?
11:15:31 <moneromooo> No.
11:16:29 <endor00[m]> Oh, so there's a possibility for two (or more) transactions to pick the same decoys at [nearly] the same time
11:16:43 <moneromooo> Yes.
11:19:00 <endor00[m]> So an external observer will know that at most one of those transactions is the real spend of a given transaction input, and the more transactions are made in a short timespan, the greater the chances of overlap
11:20:02 <moneromooo> That... makes no sense. Rephrase it so it does.
11:20:54 <moneromooo> An example case would also help.
11:31:04 <endor00[m]> Let's say that you and I both make a transaction at the same time, and we both happen to pick output 'da63f2u[...]' as one of our decoys.
11:32:22 <endor00[m]> *one of our ring members
11:33:53 <endor00[m]> Assuming both our transactions get included in the same block, could an external observer infer any additional information from the fact that the same output shows up in two new transactions less than 10 blocks apart?
11:34:32 <endor00[m]> Any additional information compared to the case in which our transactions were more than 10 blocks apart
11:36:08 <endor00[m]> In other words: would there be any benefit in enforcing unique ring members for all transactions in the last 10 blocks + mempool?
11:36:55 <moneromooo> Nothing significant that I can think. The one thing that might be is guessing at when the tx was made, but that's probably a long shot.
11:37:09 <moneromooo> Since the likelihood of a fake out being picked decreases with age.
11:39:47 <endor00[m]> The greater the transaction throughput of the network, the more the chance of an overlap in ring members between transactions goes up
11:40:56 <endor00[m]> And I was wondering if this could allow an external observer to start 'crossing out' decoys from transactions based on the fact that the same decoys show up in multiple transactions at the same time
11:43:53 <sech1> even if you have an output in 10 different transactions, there is no guarantee it was actually spent
11:45:27 <endor00[m]> But if 50 transactions show up at the same time using 'da63f2u[...]', I could say that none of them are a real spend of that output and I'd be wrong only 2% of the time
11:45:50 <endor00[m]> Does that make sense? Or is there some logical fallacy in that line of reasoning?
11:46:52 <endor00[m]> <endor00[m] "But if 50 transactions show up a"> And doing this would 'degrade' those transactions down to a ring size of 10
11:47:46 <endor00[m]> Kinda reminiscent of the "snowball effect" I vaguely remember being mentioned in Breaking Monero
11:47:49 <moneromooo> I don't think you're wrong.
11:48:02 <moneromooo> This has nothing to do with time though, so that was confusing.
11:48:28 <moneromooo> (beyond the selection likelihood, which is unrelated but comes into play here)
12:07:21 <gingeropolous> afaik, there's no real time input to the random outputs being selected as inputs
12:08:17 <gingeropolous> so i think it just boils down to will 2 transactions select the same output at random?
12:08:47 <gingeropolous> i think n3ptune[m] could (or already has) investigated this
12:09:19 <gingeropolous> i.e., how often do transactions use the same ringmembers.
12:21:32 <sech1> I think quite often given that each transaction references 11 other transactions (each input to be precise)
12:22:48 <gingeropolous> and this will prolly follow the overall gamma distribution
14:17:44 <endor00[m]> <gingeropolous "i.e., how often do transactions "> But is there any difference between, say, 3 transactions that use the same input 1000 blocks apart, and 3 transactions that use the same output less than 10 blocks apart, or even the same block?
14:18:03 <endor00[m]> Or even 3 transactions sitting in the mempool at the same time
15:34:09 <gingeropolous> im not pickin up what you're putting down.... if the blockchain is the alphabet, a transaction created at N will have outputs selected from A-N, picked at random with a probability defined by some gamma distribution
15:34:44 <gingeropolous> A transaction at O will the same, but from A-O
15:35:29 <gingeropolous> i mean, except treat each letter as some n block epoch if you want to get finicky, because yeah, the tx can't select from the same block its being created in or [current block] - 10
15:36:17 <gingeropolous> so the most it could tell you is that a tx was created at the same time, but thats known from the fact that its included in a block which timestamps it
15:37:00 <gingeropolous> I mean, perhaps if output selection algos get real wonky and the chain has so much activity that the output selection could somehow increase the resolution of transaction formation ....
15:38:01 <gingeropolous> i mean, yeah, you could say be able to pinpoint a transaction created at block N, but not actually submitted to the network until block S
15:38:24 <gingeropolous> but one could also infer that because that delayed submission transaction doesn't include any inputs from N-S
15:39:04 <gingeropolous> so i guess its a convergent phenomena?