04:14:58 knaccc: is this related to your recent idea? 04:16:15 sgp_ you mean what i typed a while ago about the donation addresses? that looks half-baked. the github thread contains the notes from tevador on it https://github.com/monero-project/research-lab/issues/75 04:17:09 Ah I didn't read the other comments there yet 07:03:03 knaccc is there any detailed writeup on why churning stands out on the blockchain? 12:11:28 sech1, its discussed kinda here: https://www.monerooutreach.org/breaking-monero/metadata.html , maybe 12:18:09 hm, so the only problem mentioned there is that someone churns 8 times, it'll be a chain of 1in/2out transactions which stands out 12:18:48 I actually see quiate a lot 1/2 transaction on the chain, I'm not sure how it could standout at all 12:29:53 sech1 a couple of years ago i was looking at this with i think surae, i'm not sure. essentially, the point is that when you do an analysis of how often outputs actually get used as decoys by other transactions, it's actually not very often, if at all. therefore if you tkae an output and spend it in a churn, and then spend the results of that and repeat several times over a short period of time, 12:29:55 then statistically that's a very clear churn, because that pattern of a spend followed by the new outputs being spent, in quick succession, almost never happens unless it's intentional 12:30:43 so 2-3 days between churns solves it? 12:30:57 A Poisson distributed delay between each. 12:31:23 Otherwise you get fishy results (arf arf). 12:33:13 sech1 i think even putting time between churns doesn't help, because the older an output gets, the less likely it is to ever get used as a decoy by someone else. and the problem with waiting 2-3 days is that now you have to increase the time between receiving and then later spending funds from 20 minutes to weeks 12:33:31 because you need 5-7 churns before your anonymity set is enough 12:33:41 I have several output which are 1-2 years old in my wallet 12:33:49 *inputs 12:33:57 so you're saying I can't spend them safely? 12:34:48 for repeated churn, would it help to include as decoys the outputs of some transactions that used your previous churn as decoys? 12:37:43 i think we thought about that a little, and surae's phd mathematical mind still had issues with that 12:38:16 we kept coming back to the fundamental problem that your outputs just aren't ever used as decoys much, if at all. 12:38:47 Whyt not 10 or 11 times on average ? 12:39:08 Or is it that the distribution is so much long tailed that the mode is just a couple ? 12:39:14 why not what happening 10 or 11 times? your outputs being used as decoys by others? 12:39:25 Yes. 12:39:34 For ouputs that are old enough anyway. 12:40:22 well i wrote code to check how many times outputs were actually ever being picked up as decoys, and i think most were not, and you have some chance they'll be picked up once, and tiny chance it's >3 12:40:50 and the larger the blockchain gets, the much lower the chances of old outputs ever being used again as a decoy goes to zero rapidly 12:40:54 Can you estimate "tiny", roughly ? 12:41:05 order of magnitude 12:41:26 i'll see if i can dig up the code i used to count uses of outputs as decoys, it's been 2 years so i'm hazy 12:44:05 If you have a wallet with a fair number of outputs, you can run "incoming_transfers uses", and see if that roughly matches the expectation. 12:44:25 (also works on spent ones) 12:45:11 Is that command in v0.15 wallet or only newere ones? 12:45:43 incoming_transfers uses ? It's in 0.15. Probably also 0.14, not sure when I added that, it was a while ago. 12:46:04 I'm just lazy to update to 0.16, but I do have a wallet with lots of inputs 12:46:19 (from mining in 2017-2018) 12:49:41 actually i apologize, i misremembered the stats. here is what i got in 2018: 12:49:45 here are the stats I ran on output reference counts on the most recent 90k outputs (last 7 days of blockchain): count>=0: 90380 100.0%, count>=1: 74 12:49:47 501 82.4%, count>=2: 50914 56.3%, count>=3: 38534 42.6%, count>=4: 30908 34.2%, count>=5: 25509 28.2%, count>=6: 21313 23.6%, count>=7: 18047 20.0%, count>=8: 15504 17.2%, count>=9: 13485 14.9%, count>=10: 11744 13.0% 12:51:23 maybe the issue we had was with the 17.6% of outputs that never get picked up as decoys ever 12:51:42 "last 7 days of blockchain" and "ever" ? 12:51:51 good point 12:52:10 Also the last few blocks are unlikely to be selected just by virtue of being very young. 12:52:18 i think there was something else we did that showed that once an output got older it got massively less likely to ever be used as a decoy 12:52:25 You should run on a period that's at least a few days old. 12:52:37 because of the amount of new txs vs amount of old txs 12:53:05 Unlikely. It's more likely due to the selection gamma distribution. 12:53:24 Oh, 2018. Might have been before gamma... 12:53:36 yeah i'll have to re-run the code if i can find it 12:53:42 moneromooo re: "incoming_transfers uses"; if there is nothing after "Used at heights:", it means the output has never been used as a decoy? 12:54:09 Either that or your wallet hasn't been recording the data. It's optional IIRC. Somewhere in "set". 12:54:44 It might also have started recording at some height where it was added. 12:55:10 Ah, set track-uses 1 12:55:33 Hmm. It's off by default. So... 12:55:42 Would need a rescan :) 12:56:15 how can I rescan it retroactively? 12:56:26 without a full resync 12:56:46 Can't. 12:57:13 It has to go through all rings. 12:57:48 I understand that, but there is no need to scan for my outputs again 12:58:18 It is theoretically possible if you write code, if that's what you mean. 13:17:36 aha ok i found the code and ran it. i think the last time we tried, ring size was not 11, so the current stats looking better than before 13:17:38 https://paste.debian.net/plain/1156115 13:17:51 so that's the last 7 days from now 13:18:22 that "chain length" thing is for detecting churns 13:18:41 and so i remember now 13:19:34 the problem was specifically about chain lengths >=6 not being regularly observed 13:19:57 and also that no one is interested in actually making it possible for users to easily, regularly or automatically churn 13:20:18 because we know the consequences that would have on blockhain bloat 13:26:04 Again, don't do the last N days, it skews. 13:27:53 yeah i'm running it again for 3 days. problem is it is a very slow script to run 13:28:00 i mean 30 days 13:28:17 What is "chain length" exactly ? 13:28:31 7 days is fine. Just not the last 7. 13:28:58 Last 30 will also skew, though less so. 13:29:05 it's detecting an output being spent, and then whether the resulting outputs from that tx being spent, and so on. 13:29:14 so it's detecting churn chains or naturally occurring chains 13:29:22 So it's the distance to coinbase ? 13:30:11 If so, checking only 7 days will massively underestimate. 13:30:53 Oh, you might be purposefully only checking quick respends, nvm. 13:31:08 either distance to coinbase, or distance to the earliest link in the chain within the last 7 days (because the coinbase my have been outside of the 7 day window) 13:31:55 in about an hour, the 30 days stats will be ready. i'll post and we can compare 13:31:57 THere are many paths to a coinbase. Do you pick the first you find ? 13:32:15 i'll look at the code and see 13:33:54 this is the code btw 13:33:56 https://paste.debian.net/plain/1156117 13:36:24 `btw it says there week = day * 30 instead of week = day * 7. i edited it to span 30 days just now in the wrong place. 14:23:17 ok i have new stats, which are not for the last 7 days, but rather the 7 day window which ends 30 days ago. results here: https://paste.debian.net/plain/1156119 14:24:23 i figured out what the code is doing. It operates between a startBlockHeight and a (higher) endBlockHeight. Every time it encounters an output in a transaction, it records against that output a list of possible inputs that could have been spent to produce that output. After all blocks have been encountered and all possible inputs recorded for each output encountered, it then examines each output 14:24:25 encountered and looks backward to find the longest chain of possible input paths that could have lead to the creation of that output. The earliest that chain could have gone back to is startBlockHeight. 14:24:27 When the code reports e.g. "chain length>=4: 36266 16.1%", that means that out of all outputs encountered between startBlockHeight and endBlockHeight, 16.1% had a possible chain length of at least 4 when looking backwards within the startBlockHeight->endBlockHeight window. 14:26:59 what this means is there is no qualitative difference when running the stats between having the 7 day window end right now, and the 7 day window ending 30 days prior to now 14:27:22 because only outputs within the window are considered. the stats won't change as that 7 day window ages 14:28:32 so the stats i just pasted show that only 2.1% of outputs have a chain length>=6, which i think we concluded is a major problem for churn 14:48:25 also the recursive nature of the code that checks for chain lengths means that it's not even possible for me to run it with more than about 10 days of data (i get a stackoverflow if i try) 14:48:31 this is the 10-day window from now backwards https://paste.debian.net/plain/1156124 14:54:19 the biggest problem is what happens if we want churn to be routine, and not just for 1% of users that actually want untraceability at the cost of multi-day waits. because if you lower the churn window to just 24 hours, then the number of chains with any significant length that naturally occur gets even shorter 14:55:38 24hr stats: https://paste.debian.net/plain/1156126 22:40:07 Is it possible to add a heuristic for picking a ring member with an explicitly high chain length when constructing the ring signature? 22:40:43 Muddy the waters for people churning by implicating most normal transactions with potential churns 22:50:07 I could see computational concerns, would be a pain to manage 23:35:11 needmoney90 it's possible to 'attach' to a detected long chain, but the problem is you only have your outputs introduced mid-way down the chain, so you have ot hope that after you 'attach', someone else not only keeps churning, but then uses your churn output as a decoy 23:36:06 The goal here would be to introduce plausible deniability to a particular person, so they can say "ah, that chain length wasn't *my* churn, my tx was just constructed with it" 23:36:36 if many people are building off of long chain-length txes, that makes long chain-length txes more common in ring members, which means they're noisier 23:36:46 the two biggest issues with churn though are that 1) bloat, meaning no one wants to ever implement anything like this and 2) the churns can't be done in quick succession, or that's crazy crazy obvious. so if we do have churn, we have to start telling people that monero isn't private unless they space stuff out over days or weeks, so that their churns look like they are happening at random points 23:36:48 and is not forced 23:37:13 Alternatively we can find a way to do protocol-level mixing 23:37:45 Letting you spend another person's outputs (and them spend yours), to sever the tx graph 23:38:23 yeah, although there is a timing attack there 23:38:41 so it could not be instant when you're ready to spend 23:38:57 you have to sever things in advance and wait a while 23:39:04 but what you're saying has potential i think 23:39:08 just not sure how it could be done