18:02:42 <Rucknium[m]> I am dipping my toes into a question brought up in #monero-dev : "What is the appropriate sample size for unit tests when the result is stochastic?"
18:03:23 <Rucknium[m]> For medians, which is the case-in-point, I am using this as a starting point:
18:03:23 <Rucknium[m]> https://stats.stackexchange.com/questions/45124/central-limit-theorem-for-sample-medians
18:03:44 <Rucknium[m]> ^ The second answer is extremely detailed.
18:16:51 <jberman[m]> my initial thought is something that would fail 1 in 100bn times would be ok, some extremely low probability failure rate. and get there via a combo of widening the range of the expected median + using as large of a sample size as possible that doesn't make the tests take forever. like say we want a test to take <5s on a particular machine, and then widen the range of the expected median to ensure the test passes 99.99999% of the
18:16:51 <jberman[m]> time
18:20:13 <moneromooo> Failing 1% of the time is just fine, since (1) you know whether code you changed has a chance of influencing the code under test and (2) running again a few times gets you confirmation of something off or not.
18:20:59 <moneromooo> (of course it failing 0.00001% of the time is easily done without spending 10 seconds on the test, it is even better)
18:21:29 <moneromooo> Actually...
18:22:09 <moneromooo> Make it so it runs as it does now, but if it would fail, it continues with x10 samples and reports that result instead.
18:22:33 <moneromooo> Then it usually stays fast, and only fails much more rarely.
18:22:48 <moneromooo> (All numbers above placeholders)
18:23:52 <Rucknium[m]> jberman: I am fairly confident that with a little theoretical work we could write out a mathematical function that tells us the exact value for what N (number of test iterations) should be, as a function of the parameters you mentioned (failure rate, expected median, probably others).
18:26:57 <Rucknium[m]> moneromooo: Overall I find this suggestion reasonable. My only (slight) hesitation is that it brings up multiple hypothesis testing issues, which can be a bit tricky. Or, alternatively "pre-testing" issues. The statistical theory on these is fairly well-explored, but it is more complicated than the "standard" single hypothesis testing issues.
19:35:44 <sblake01[m]> Currently starting my dissertation on the security vulnerabilities surrounding crypto currency transactions and central bank digital currencies (CBDC) transactions. However I am struggling to find enough security flaws with CBDC as it is new technology and hasn't been publicly adopted yet. If anyone is able to give me some more insight into Central Bank security flaws or anything similar to this topic, I'd appreciate it a-lot.
22:35:20 <zkao> "Have you investigated the possibility of a kind of Lightning Network in conjunction with Seraphis?" <- dEBRUYNE: Seraphis enables features that are required for building payment channels, thus take us a step closer, but not all the way
22:36:13 <zkao> It permits offchain transactions to be composed in series (i.e., dependent txos, forming a chain of txs emerging from an initial txo). That is a requirement for creating refund transactions (spending money not yet locked on chain on a multisig output, for example, "now i have the refund thus i can safely lock