-
sarang
Hello all
-
sarang
Finishing up some effective anonymity set data today, woo
-
sarang
Also UkoeHB_ I have a finalized data set for transaction-output relationships
-
sarang
That can be run against any analysis we wish
-
sarang
It's a pretty huge file, but I can provide format details should you have particular code you wish to run against it
-
Inge-
< binaryFate> The wallet warns you when you spend old outputs that privacy is lessen and it's known you should churn in that case <-- is churning much different from a sweep_single of that output? is it best practice to sweep_single to yourself in order to churn, before spending ?
-
Inge-
(speaking of old outputs here
-
sarang
Churning individual old outputs before merging them would leave a likely fingerprint in the transaction graph
-
sarang
Merging into a new output would be likely used in many other rings, and therefore introduce some nice ambiguity in the graph
-
Inge-
so 1) how old should an output be to qualify as an "old" output?
-
Inge-
2) What IS the recommended approach for preparing to spend old outputs?
-
sarang
Well, a transaction spending pre-CT funds runs the risk of being deducible (due to old chain-reaction effects) and/or being susceptible to guess-newest (just a heuristic, not inherently testable)... but otherwise, the older a spent post-CT output is, the less likely it is to be a decoy according to the modern selection algorithm
-
sarang
that is not quite so cut-and-dry
-
sarang
I have data on the deducibility of pre-CT funds being spent in the post-CT world, and can put together a little plot on that
-
Inge-
My question is solidly planted in the post-CT era
-
sarang
post-CT funds are not at risk of deducibility using the same method (i.e. chain reaction no longer applies)
-
sarang
ok
-
moneromooo
maybe the wallet should try to select true spends with one ring spending an old out if there's one, and the rest spending recent ones.
-
Inge-
Ideally it should be fairly trivial for users to hold for a long time and then spend safely
-
sarang
True, but the entire point of the spend-age distribution is to match actual known spend patterns as close as possible
-
gingeropolous
ugh. just bump the ringsize to a bajillion and be done with it
-
sarang
s/11/1 bajillion/
-
sarang
done
-
sarang
someone please review that change for me
-
gingeropolous
lol
-
moneromooo
That will change a lot more than just ring size.
-
gingeropolous
i mean, cereal though, how much of this heuristic nonsense would be abrogated with massive ringsizes
-
kinghat[m]
how big of a ringsize is enough?
-
sarang
IMO being able to use ring epochs can mitigate a lot of this
-
sarang
Even in the event of a breakdown of the age distribution, an adversary still has to work within an entire epoch
-
kinghat[m]
sorry for being ignorant but its more than just plausible deniability, correct?
-
sarang
and if epochs contain many outputs from the same transactions, output merging is less useful
-
gingeropolous
the buckets or batching or bins or whatever its called?
-
sarang
aye
-
gingeropolous
i mean, a 1k ringsize does far less damage than when we moved to original ringct. Yes yes, i know, we're such a mature network now, but c'mon
-
kinghat[m]
is there a ballpark size or a size of diminishing returns? or is it more is always better?
-
sarang
kinghat[m]: that answer would depend highly on the particular risk model a user is considering,
-
sarang
(which is very much a non-answer...)
-
sarang
AFAIK it hasn't really been tested in the real world what "plausible deniability" looks like in the context of ambiguous signatures
-
kinghat[m]
ya we cant know that, but we probably can know that 1k is basically the same as 1.2k but is it the same as 2k?
-
sarang
Depends entirely on your threat model
-
kinghat[m]
ya i guess im not educated enough on the different threat models to be able to make a distinction.
-
sarang
If an adversary is spending funds repeatedly to a user and is colluding with their exchange to see how often those funds appear in the transaction graph when deposited, then that's probably a different metric for deniability than simply looking at patterns in the graph without such information
-
sarang
and if the adversary also colludes with the user's ISP, it could have more information still
-
kinghat[m]
damn, i always forget about the exchanges.
-
sarang
"Who is colluding with whom" is a tricky question
-
kinghat[m]
the ring size plays a role if there was collusion with an isp?
-
sarang
Depending on how the user interacts with the network, the ISP could know which transactions belong to the user
-
sarang
or at least provide an indication of when the user was online to potentially make a transaction
-
sarang
and that's useful information
-
kinghat[m]
got ya.
-
UkoeHB_
re: finalized data set for transaction-output relationships; sounds good sarang
-
sarang
The data is up to block 2.1 M, which extends to May 2020
-
niocbrrrrrr
-
niocbrrrrrr
-
gingeropolous
i don't think variables outside the scope of the blockchain should function as inhibitors of the security design of the blockchain
-
gingeropolous
just because Jimbo sends from the same IP to the exchange and the publishes his transaction has on twitter doesn't mean the chain should be super awesome
-
gingeropolous
*transaction hash
-
gingeropolous
i mean hell, if you take that philosophy to its maximum (and always crank to 11), then bitcoin's psuedonynmeueoiltuio is fine
-
sarang
I'm not sure I follow what view you're taking here gingeropolous...
-
gingeropolous
the threat models
-
sarang
Are you saying that the security design should take into account common likely user behaviors (e.g. interacting with exchanges)?
-
sarang
If so, I agree
-
sarang
Absolutely
-
sarang
Unfortunately, there's no clear line for where your assumption of entities colluding should be
-
sarang
"Everyone is colluding" seems to ruin most designs
-
gingeropolous
im saying the security design shouldn't be hindered by likely user behaviors
-
gingeropolous
ah, missed a negative in my original statement. my bad "doesn't mean the chain shouldn't be super awesome"
-
gingeropolous
well, a double negative was attempted, and missed. I'll work on my doublespeek. That was doubleplus ungood.
-
gingeropolous
not even these keys can keep up with these caffeinated manic comments!