08:52:54 <mj-xmr[m]> hyc: your 8031 is green on RPi4 64-bit :)
08:53:02 <mj-xmr[m]> bbl
14:16:00 <spackle[m]> <Rucknium[m]> "spackle: I think overall that it..." <- Agreed, though I do think it is an interesting place to start. Strictly for educational purposes, I'll list a few quick/rough stats I grabbed:... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/c2bbad02b6e97460db53994b7cad5f0e0850eac8)
14:24:08 <Rucknium[m]> >it is reasonable to say that patience should be on your side.
14:24:08 <Rucknium[m]> spackle What do you mean by this ^, by the way?
14:29:58 <spackle[m]> Rucknium: That timing churn transactions to match the decoy distribution, while setting the maximum period as high as you can tolerate, is the logical starting point for making a churn disappear into the block chain. By strictly decoy count, someone generating delay times up of to 1 week has twice as many decoys as someone working within a 12 hour window. Just seems worth noting.
14:31:43 <Rucknium[m]> >has twice as many decoys
14:31:43 <Rucknium[m]> spackle What do you mean by "has"?
14:39:19 <merope> More transactions on chain before you churn again => more decoys to pick from 
14:39:23 <spackle[m]> Rucknium: That the percentage of the total distribution of decoys included in the time frame doubles. Do you find that statement objectionable?
14:42:00 <Rucknium[m]> merope: How long you wait to re-spend outputs does not impact which decoys are selected by the reference implementation of the Monero wallet.
14:43:52 <Rucknium[m]> spackle: In what time frame? I mean, your statements are correct, but it seems to me that you may be relating them to defense against traceability in an incorrect way.
15:02:46 <spackle[m]> Rucknium: The observation that I'm making: The value of the CDF for Monero's gamma distribution at x=13.31(corresponding to 1 week) is approximately twice its value at x=10.68(corresponding to 12 hours).
15:02:46 <spackle[m]> I'm not trying to make a grand statement about traceability, but I think it is fair to say someone using the extended period to generate churning transaction delays will be less detectable for repeated transactions.. If there's something wrong or misleading about what I wrote please feel free to clarify.
15:09:00 <Rucknium[m]> Here are my initial thoughts on the timing of churns (not churning overall). I may revise my thoughts as more research is done, of course:
15:11:09 <Rucknium[m]> It seems reasonable that the time interval between churns should closely match the distribution that the decoy selection algorithm uses. That way, the "timing" metadata on the real spends looks the same as the decoys.
15:11:50 <Rucknium[m]> This could be accomplished by randomly drawing time intervals from the distribution that the decoy selection algorithm uses.
15:13:21 <Rucknium[m]> However, it seems to me that it would not be a good idea to consistently wait exactly a week, for instance, to churn, since that interval would be clearly identifiable in the blockchain data. Instead, a better approach may be to randomize the wait time for churns, as I stated just above.
15:14:27 <Rucknium[m]> >it is fair to say someone using the extended period to generate churning transaction delays will be less detectable for repeated transactions
15:14:27 <Rucknium[m]> spackle If the wait time is the same for every churn, then the churning would be fairly detectable, I think.
15:15:05 <spackle[m]> Rucknium[m]: Agreed, and that's what I meant. I didn't want to post it because it is amateurish and I don't think I implemented jberman's window correctly, but my thought was to use something like this to generate the delay you'd wait for a churn transaction: https://github.com/spackle-xmr/Nonsense/blob/main/gammaval.cpp
16:55:55 <hyc> moneromoooo: I vaguely recall you tweaked slow-hash recently to allow hasing at arbitrary heights instead of just chaintip
16:56:51 <hyc> did you add a new rpc to make use of that?
18:32:42 <selsta> .merges
18:32:42 -xmr-pr- 8023 8031 8032 8037
18:36:06 <hyc> now that randomx upstream has been patched we probably need a PR to update that too
18:37:01 <hyc> dunno if a randomx release tag is forthcoming or not
19:44:18 <selsta> hyc: A tag isn't strictly necessary but would be nice