<a​ntilt:we2.ee> wouldn't --add-priority-node (list) or even --add-exclusive-node (list) frustrate this Eclipse Attack?

--add-priority-node can help, but it's not a guarantee. --add-exclusive-node will help, as long as then node you use is not an attacker's node.

<a​ntilt:we2.ee> tx. was thinking of a "friends list" as backup, just in case (for myself, not as centralized solution)

<r​ucknium:monero.social> flip flop: The status quo DSA already does adjust for on-chain output production rate (over the last one year). Of course, that's _production_ instead of consumption (spending) of outputs. Making the DSA more dynamic is difficult because you also have to consider what an adversary might do to manipulate it. An adversary can spam txs, which would affect the DSA if it dynamically ad<clipped message

<r​ucknium:monero.social> apts. I'm not against shortening the current lookback window to be less than one year, FWIW. On the other hand, actual Monero tx volume has been stable for years.

<r​ucknium:monero.social> By the way, when you edit your comments on Matrix, it produces a double-post on the IRC side

<r​ucknium:monero.social> xmrack: I posted it to MoneroResearch.info a few weeks ago: moneroresearch.info/index.php?actio…n=resource_RESOURCEVIEW_CORE&id=248

<r​ucknium:monero.social> Was the issue they raised completed fixed by monero-project/monero #9218 , or is there more to do?

<r​ucknium:monero.social> They have a GitHub repo, but its empty: github.com/lab-520/Eclipse-Attacks-on-Monero-s-Peer-to-Peer-Network

<r​ucknium:monero.social> it's*

<b​oog900:monero.social> yeah part of their attack required causing disconnections, with that patch their method for causing disconnections no longer works. We could do more to harden the addressbook from the other stages of the attack, they mentioned some ways in the `COUNTERMEASURES` section.

<a​ntilt:we2.ee> my idea was to add "noise" to the gamma function, so an attacker can not be shure what he is looking at. I am not even sure if that would lead to a statistical advantage, but thats what I did routinely in my algos. Also, would be nice if a step-by-step rollout would be feasable. Can you estimate (quantitatively) the degradation if say 50% of wallets do upgrade ?

<r​ucknium:monero.social> > Can you estimate (quantitatively) the degradation if say 50% of wallets do upgrade ?

<r​ucknium:monero.social> Yes, but it will take some time to figure out the methodology for that. I'm working on it.

<r​ucknium:monero.social> On making the Gamma _parameters_ (or parameters of other parametric distributions) randomized by wallets, maybe it could help, or maybe not. Kumar et al. (2017) says moneroresearch.info/index.php?action=resource_RESOURCEVIEW_CORE&id=21 :

<r​ucknium:monero.social> > As we have seen the current sampling strategy for mix-ins fails drastically in preventing temporal analysis. There are two possible strategies towards mitigating the ensuing risks: (a) mimic users’ spending behavior or, (b) force mix-ins to be picked according to some “unknown” distribution. Solution (b) can be achieved by employing primitives such as ORAM [8] that will pr<clipped message

<r​ucknium:monero.social> ovide cryptographic guarantees on the impossibility to learn information from a passive analysis of the blockchain. However, their applicability to distributed cryptocurrencies seems to require either a trusted party [10] or NIZK proof. We consider them to be important future work. Here, we will focus on (a).

<r​ucknium:monero.social> Of course, at the blockchain aggregate level, randomizing the parameters would create (possible non-finite) mixture distributions of the Gamma distributions, which would be analyzable because the randomization procedure would be observable in the open source wallet code. But at the individual ring level, an adversary may find it harder to analyze. Maybe the adversary could perform<clipped message

<r​ucknium:monero.social> maximum likelihood estimation on the ring members to try to estimate the Gamma parameters that the wallet actually used. With 15/16 observations in a single ring, maybe the estimate would not be very precise.

<r​ucknium:monero.social> To elaborate:

<r​ucknium:monero.social> 1) The Patra-Sen inversion estimator could be used on the aggregate blockchain data to get the real spend age distribution (since the "standard" wallet distribution would be a known mixture distribution).

<r​ucknium:monero.social> 2) The BJR step may be more difficult since BJR only estimates the distributions when there is a (small) finite number of distributions. However, the decoy distributions that really present a problem are the nonstandard one, which would not use the "randomized parameters" distributions. So maybe those could be filtered out anyway and you would be left with the "standard" rings tha<clipped message

<r​ucknium:monero.social> t could be fed into the Patra-Sen estimator.

<r​ucknium:monero.social> 3) Executing the MAP Decoder attack against individual rings would be more difficult, but an adversary could try to estimate the parameters that the wallet used to select decoys in a particular ring by using Maximum Likelihood Estimation. Then they would use the MLE-estimated distribution as the decoy distribution in that particular ring, then run the MAP Decoder attack against it.

<r​ucknium:monero.social> Maybe it could help, but there may be ways around the randomized parameter obfuscation. Good suggestions :)

<r​ucknium:monero.social> Before, I have thought of a method to get a truly unknown distribution, but it breaks every rule in the cryptographic rulebook: Each time a tx is constructed, ask users to provide entropy from their minds, i.e. pick a number between 1 and 100. That would get you a biased random number generator, but the bias would be unknown. Since the human mind is not open source, an observer co<clipped message

<r​ucknium:monero.social> uld not know what the mixture distribution on the blockchain would actually be.

<r​ucknium:monero.social> Also, very bad UX

<a​surar0:unredacted.org> This reddit user made a [public poll](reddit.com/r/SampleSize/comments/fr…sked_you_to_choose_any_integer_from) asking to pick a number between 1 and 100, as well as random letter in the alphabet. This is the result with a sample size of 1380 answers.

<a​surar0:unredacted.org> matrix.monero.social/_matrix/media/…dacted.org/XkyTJiCNpTnUrbHSmTpOtlqG

<a​surar0:unredacted.org> According to [this research in psychology](nature.com/articles/s41598-021-98315-y.pdf), humans tend to create highly unique random sequence with decreasing entropy over time. This makes it easily identifiable.

<a​surar0:unredacted.org> > In the present study we address interindividual differences in the cognitive process of random number generation. We conclude that the mechanism by which humans generate random sequences is (a) highly unique and that (b) this uniqueness is driven by both individual preferences and individual inhibitions.

<a​surar0:unredacted.org> You may have proposed it jokingly, but I found the topic interesting.