-
sgp_
knaccc: is this related to your recent idea?
-
knaccc
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
monero-project/research-lab #75
-
sgp_
Ah I didn't read the other comments there yet
-
sech1
knaccc is there any detailed writeup on why churning stands out on the blockchain?
-
gingeropolous
-
sech1
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
-
sech1
I actually see quiate a lot 1/2 transaction on the chain, I'm not sure how it could standout at all
-
knaccc
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,
-
knaccc
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
-
sech1
so 2-3 days between churns solves it?
-
moneromooo
A Poisson distributed delay between each.
-
moneromooo
Otherwise you get fishy results (arf arf).
-
knaccc
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
-
knaccc
because you need 5-7 churns before your anonymity set is enough
-
sech1
I have several output which are 1-2 years old in my wallet
-
sech1
*inputs
-
sech1
so you're saying I can't spend them safely?
-
tevador
for repeated churn, would it help to include as decoys the outputs of some transactions that used your previous churn as decoys?
-
knaccc
i think we thought about that a little, and surae's phd mathematical mind still had issues with that
-
knaccc
we kept coming back to the fundamental problem that your outputs just aren't ever used as decoys much, if at all.
-
moneromooo
Whyt not 10 or 11 times on average ?
-
moneromooo
Or is it that the distribution is so much long tailed that the mode is just a couple ?
-
knaccc
why not what happening 10 or 11 times? your outputs being used as decoys by others?
-
moneromooo
Yes.
-
moneromooo
For ouputs that are old enough anyway.
-
knaccc
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
-
knaccc
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
-
moneromooo
Can you estimate "tiny", roughly ?
-
moneromooo
order of magnitude
-
knaccc
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
-
moneromooo
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.
-
moneromooo
(also works on spent ones)
-
sech1
Is that command in v0.15 wallet or only newere ones?
-
moneromooo
incoming_transfers uses ? It's in 0.15. Probably also 0.14, not sure when I added that, it was a while ago.
-
sech1
I'm just lazy to update to 0.16, but I do have a wallet with lots of inputs
-
sech1
(from mining in 2017-2018)
-
knaccc
actually i apologize, i misremembered the stats. here is what i got in 2018:
-
knaccc
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
-
knaccc
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%
-
knaccc
maybe the issue we had was with the 17.6% of outputs that never get picked up as decoys ever
-
moneromooo
"last 7 days of blockchain" and "ever" ?
-
knaccc
good point
-
moneromooo
Also the last few blocks are unlikely to be selected just by virtue of being very young.
-
knaccc
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
-
moneromooo
You should run on a period that's at least a few days old.
-
knaccc
because of the amount of new txs vs amount of old txs
-
moneromooo
Unlikely. It's more likely due to the selection gamma distribution.
-
moneromooo
Oh, 2018. Might have been before gamma...
-
knaccc
yeah i'll have to re-run the code if i can find it
-
tevador
moneromooo re: "incoming_transfers uses"; if there is nothing after "Used at heights:", it means the output has never been used as a decoy?
-
moneromooo
Either that or your wallet hasn't been recording the data. It's optional IIRC. Somewhere in "set".
-
moneromooo
It might also have started recording at some height where it was added.
-
moneromooo
Ah, set track-uses 1
-
moneromooo
Hmm. It's off by default. So...
-
moneromooo
Would need a rescan :)
-
tevador
how can I rescan it retroactively?
-
tevador
without a full resync
-
moneromooo
Can't.
-
moneromooo
It has to go through all rings.
-
tevador
I understand that, but there is no need to scan for my outputs again
-
moneromooo
It is theoretically possible if you write code, if that's what you mean.
-
knaccc
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
-
knaccc
-
knaccc
so that's the last 7 days from now
-
knaccc
that "chain length" thing is for detecting churns
-
knaccc
and so i remember now
-
knaccc
the problem was specifically about chain lengths >=6 not being regularly observed
-
knaccc
and also that no one is interested in actually making it possible for users to easily, regularly or automatically churn
-
knaccc
because we know the consequences that would have on blockhain bloat
-
moneromooo
Again, don't do the last N days, it skews.
-
knaccc
yeah i'm running it again for 3 days. problem is it is a very slow script to run
-
knaccc
i mean 30 days
-
moneromooo
What is "chain length" exactly ?
-
moneromooo
7 days is fine. Just not the last 7.
-
moneromooo
Last 30 will also skew, though less so.
-
knaccc
it's detecting an output being spent, and then whether the resulting outputs from that tx being spent, and so on.
-
knaccc
so it's detecting churn chains or naturally occurring chains
-
moneromooo
So it's the distance to coinbase ?
-
moneromooo
If so, checking only 7 days will massively underestimate.
-
moneromooo
Oh, you might be purposefully only checking quick respends, nvm.
-
knaccc
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)
-
knaccc
in about an hour, the 30 days stats will be ready. i'll post and we can compare
-
moneromooo
THere are many paths to a coinbase. Do you pick the first you find ?
-
knaccc
i'll look at the code and see
-
knaccc
this is the code btw
-
knaccc
-
knaccc
`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.
-
knaccc
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:
paste.debian.net/plain/1156119
-
knaccc
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
-
knaccc
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.
-
knaccc
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.
-
knaccc
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
-
knaccc
because only outputs within the window are considered. the stats won't change as that 7 day window ages
-
knaccc
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
-
knaccc
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)
-
knaccc
this is the 10-day window from now backwards
paste.debian.net/plain/1156124
-
knaccc
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
-
knaccc
-
needmoney90
Is it possible to add a heuristic for picking a ring member with an explicitly high chain length when constructing the ring signature?
-
needmoney90
Muddy the waters for people churning by implicating most normal transactions with potential churns
-
needmoney90
I could see computational concerns, would be a pain to manage
-
knaccc
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
-
needmoney90
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"
-
needmoney90
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
-
knaccc
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
-
knaccc
and is not forced
-
needmoney90
Alternatively we can find a way to do protocol-level mixing
-
needmoney90
Letting you spend another person's outputs (and them spend yours), to sever the tx graph
-
knaccc
yeah, although there is a timing attack there
-
knaccc
so it could not be instant when you're ready to spend
-
knaccc
you have to sever things in advance and wait a while
-
knaccc
but what you're saying has potential i think
-
knaccc
just not sure how it could be done