<h​into.janaiyo:matrix.org> Rucknium: was there a specific use-case you had in mind for using the DB outside of `cuprated` (maybe a block explorer?)

<h​into.janaiyo:matrix.org> as it looks now, cuprate's DB will have a stable byte-layout and use primitive types that C and most languages should be able to represent, it's just a matter of creating the schema in those languages (and if they have an LMDB wrapper)

<h​into.janaiyo:matrix.org> would a separate binary acting as a DB request/response middle-layer or a C schema so all(?) languages could read the DB directly be better? former would work out-the-box but be a separate binary, latter would be more flexible but it would be up to other people to create language mappings

<r​ucknium:monero.social> For statistical analysis of blockchain data. Now I have to go through `monerod` for everything: github.com/Rucknium/misc-research/b…tive-Ring-Size/xmr-ring-gathering.R

<r​ucknium:monero.social> IMHO, it's not a big priority to make sure cuprate database can be read by other programs. I was just interested if the planned implementation would allow that.

<r​ucknium:monero.social> So much for not posting the BP++ review progress on Reddit. Oh well: reddit.com/r/Monero/comments/1b8yuk…tandard_96_monero_hits_a_new_record

<a​aron:cypherstack.com> As before, I would caution any readers not to assume more completeness than exists with that incomplete draft

<a​aron:cypherstack.com> and as noted by Diego Salazar when he posted it, the findings are incomplete and could change at any time

if this were a flood attack are we actually looking at enough TXs to de-anonymize ring sigs? 100k TX implies they could own 75-80% of the recent outputs

100k per day vs the usual 20-25k

<h​into.janaiyo:matrix.org> ah, so reading `data.mdb` directly from R would be preferred, no other binaries?

<s​omeoneelse495495:matrix.org> I feel like my hard work at [documenting monerod db](github.com/Cuprate/old_book/blob/ma…monero/database/monerod_database.md) didn't payed off...

<s​omeoneelse495495:matrix.org> The [tables](github.com/Cuprate/old_book/blob/main/src/monero/database/tables.md) and [types](github.com/Cuprate/old_book/blob/main/src/monero/database/types.md)

<p​ndxmr:matrix.org> and which output spents does it hurt the most ? with current DSA ?

<r​ucknium:monero.social> "which output spents does it hurt the most ?" Assuming that the tx volume is from an adversary that is trying to reduce user privacy, txs that randomly select as decoys a higher number of outputs created by the adversary. The binomial distribution can tell you the rough probability of that.

<p​ndxmr:matrix.org> spending any recent output would have least privacy ?

<r​ucknium:monero.social> I don't think so. Could you explain your hypothesis or classifier?

<r​ucknium:monero.social> At least, I don't think the adversarial flood would affect that.

<r​ucknium:monero.social> Young/old spending privacy is mostly about how well the distribution of the decoy selection algorithm matches the real spend distribution in those segments of the age distribution.

<p​ndxmr:matrix.org> i did spend a output yesterday and 13 decoys were from last 24hrs, if attacker owns a high % of decoys then effective ringsize would be much lower

<r​ucknium:monero.social> The decoys are selected independently from the age of your real spend.

<p​ndxmr:matrix.org> with current dsa what percentage of recent outputs are useds as decoys ? if a attacker owns majority of it then how much would be effective ringsize ? a approx % would be good to know

<p​ndxmr:matrix.org> with current dsa what percentage of recent outputs are used as decoys ? if a attacker owns majority of it then how much would be effective ringsize ? a approx % would be good to know

<r​ucknium:monero.social> Ok let me see. I will try to give you something a little exact

<r​ucknium:monero.social> With some quick coding, I see 59% of the probability mass function of the DSA are outputs created by the suspected spammer if 75% of outputs created since March 4 are owned by the spammer.

<r​ucknium:monero.social> I will have to double check the script.

<s​packle_xmr:matrix.org> Trying to be lazy and use wolframalpha, I think this works for calculating how much of the decoy distribution is covered by a given amount of time:

<s​packle_xmr:matrix.org> wolframalpha.com/input?i=gamma+dist…2C++P%28X+%3C++ln%287+*+86400%29%29

<s​packle_xmr:matrix.org> The expression is taking ln() of the number of seconds in the time period you want calculated. So 'ln(7*86400)' is the percentage of decoys we can expect to be drawn from the last week (70.8357%). Just replace '7' with however many days you want to calculate for if you want something else.

<r​ucknium:monero.social> Yes, that's a good approximation. It will be inaccurate because the output flow amount, which is computed from the last year of blockchain data, does not represent real seconds when tx volume increases a lot

<s​packle_xmr:matrix.org> Got it. Makes sense.

<r​ucknium:monero.social> Here is the R script: gist.github.com/Rucknium/ce83a26ac99fb8debc0b725941340767

<r​ucknium:monero.social> I'm pretty sure it's correct. I construct compute the DSA probability mass function for all RingCT outputs. Then I multiply 0.75 by the part of the PMF since the suspected spam started. Then that is summed.

<r​ucknium:monero.social> I can't quite get the exact output index correct where the spam is supposed to start. It is off by 0.5% 🤷. Close enough

<r​ucknium:monero.social> You can adjust the assumptions if you want

<r​ucknium:monero.social> Then if you want to know the probability of each draw of decoys (0,1,2,3...decoys not controlled by an adversary, you input in your R console `round(100 * dbinom(0:15, size = 15, prob = 1 - 0.59), 1)`

<r​ucknium:monero.social> The most common number of non-adversary-controlled decoys to draw is 6. That means an effective ring size of 7.

<m​onerobull:matrix.org> matrix.monero.social/_matrix/media/…matrix.org/RDyMgugEzBVNjgljaTIbWKxS

<m​onerobull:matrix.org> are the "weird cases" just a result of the spam bcs its transactions sitting in mempool for longer than 10 minutes?

<m​onerobull:matrix.org> also rip to whoever paid nearly 4 xmr