00:15:39 <jeffro256[m]> In that PR, jberman "added logic to re-attempt the [select_outputs.gamma] test with a 10x larger sample size if the test fails on first try."
00:15:50 <jeffro256[m]> Isn't that data dredging? 
00:21:57 <UkoeHB> Rucknium[m]: 
00:27:49 <jeffro256[m]> Assuming the events are independent, you square the probability of the test failing b/c it has to fail twice in a row 
08:59:38 <jberman[m]> the point of that test in particular is to calculate a median. 10x'ing the sample size gets a more accurate median
09:01:10 <jberman[m]> it's not 10x higher by default because it takes longer to run IIRC
10:25:19 <one-horse-wagon[> Seraphis meeting today at 18:00 UTC in Matrix room--No Wallet Left Behind.  Everyone is cordially invited.
13:54:26 <Rucknium[m]> This issue came up before. I'll look into it.
15:43:09 <Guest4> Where can I get some reading/discussions on the growing size of Monero nodes? This is a big issue for other blockchains like BSC, and while Monero looks like it is not so far down the line, the issue of node size should eventually come up, right?
15:44:52 <selsta> blockchain size?
15:44:54 <moneromooo> Assuming you mean the size of the data on the chain, you can look at posts from ArticMine on bitcointalk and monero's meta repo issues.
15:47:12 <moneromooo> You can also experiment by syncing a new node and taking file size measurements every month or so. If you do that, beware the monero block time went from 1 minute to 2 minutes a few years ago.
15:47:34 <moneromooo> You can see the effect of various forks with that (ie, rct, bp...).
15:48:20 <Guest4> I got thrown out for a minute. Did you write something after the message about ArticMine and bitcointalk?
15:48:54 <moneromooo> < moneromooo> You can also experiment by syncing a new node and taking file size measurements every month or so. If you do that, beware the monero block time went from 1 minute to 2 minutes a few years ago.
15:49:19 <Guest4> Got it, thanks. Will take a look at the stuff you've suggested.
15:49:22 <moneromooo> "every month" here means when the sync reaches the block height corresponding to one extra month, ofc.
15:49:58 <moneromooo> You can lookup seraphis too, it'll likely be added to monero within a couple years, and will change tx size, and unprunable tx size.
15:50:38 <moneromooo> You can also look at the pruning patch (b750fb27b0f20e9443827732b69a504a76036430), which prunes 7/8 of the signature data.
15:50:50 <moneromooo> Which approximates to about 2/3 of the database size.
15:51:14 <moneromooo> This ratio will change based on the ratio of prunable vs unprunable size in a tx.
15:51:35 <moneromooo> Also with the total tx throughput.
16:20:25 <Rucknium[m]> tevador: Is select_outputs.density in master or now just in PR #8024?
16:23:33 <binaryFate> Guest4: quick ballpark http://moneroj.net/blockchainsize/
16:24:00 <Rucknium[m]> jeffro256: It is possible to do multiple or sequential hypothesis tests in a statistically valid way. I don't think the current software tests in the codebase are formal hypothesis tests. To do it in a statistically valid way you would first need to have p-values or something similar.
16:24:02 <Rucknium[m]> These are just "sanity checks"
17:20:58 <luigi1111w> .merges
17:20:58 -xmr-pr- 8691 8692 8693 8697 8699 8700 8705 8706 8712 8713 8714
17:22:35 <moneromooo> Hey Sysiphus1111w.
17:22:59 <luigi1111w> wat did I do
17:23:13 <moneromooo> Not enough, clearly.
17:23:57 <luigi1111w> agreed
17:26:49 <luigi1111w> oh I see I'm laborious and futile
17:28:18 <moneromooo> lol, it just felt like whatever you do, you always end up with a non empty list. Like Sisyphus. Or wherever the y is.
17:31:06 <xfedex[m]> I've noticed that monerod gets the number of already_generated_coins by doing a database call (`m_db->get_block_already_generated_coins`). Do you think this could slow down syncing on hard drives (where random reads take a relatively long time)?
17:33:34 <luigi1111w> :)
17:34:19 <xfedex[m]> This function is called quite often, without checking if tail emission has already started
17:39:42 <moneromooo> Is this a random read ? I'd think it's pretty much always the last block, no ?
17:40:14 <moneromooo> Also, this is in the block data, which is fixed length and there's a function to batch read the last N IIRC.
17:40:44 <moneromooo> You'd need to log the pages that get hit to see how random it is.
17:40:59 <moneromooo> It's also likely cached from one call to the next.
17:41:07 <moneromooo> (so not hitting disk)
17:41:31 <moneromooo> Now, if some of these calls are duplicative, removing is good.
17:41:50 <moneromooo> ie, two reads from the same txn with no write in between.
19:11:58 <someoneelse49549> Hi, why in the BlockchainDB class, sometimes functions return a bool and modify a mutable reference as the final data. And sometimes it just return the data?
19:12:29 <someoneelse49549> why is it mixed like that?
19:17:17 <rbrunner> Well, because a lot of people with a lot of different coding styles, and also level of experience, worked on the code.
19:17:28 <rbrunner> There are things much, much worse than that in the codebase.
19:18:23 <UkoeHB> someoneelse49549: sometimes you need a 'try_dosomething()', and sometimes you need a 'dosomething()'.
19:25:06 <someoneelse49549> alright. As an heretic i'm going to convert all this try & do into 'deal with Result<>' then.
19:28:02 <UkoeHB> are you writing a fork or something?
19:31:51 * someoneelse49549 uploaded an image: (280KiB) < https://libera.ems.host/_matrix/media/v3/download/matrix.org/fFWdJVBgDSYydbseRBdRnHuF/yes.png >
19:32:10 <someoneelse49549> UkoeHB: yes a naive attempt
19:33:08 <someoneelse49549> trying to rewrite it make me learn the codebase.
19:34:59 <ghostway[m]> wdym hidden btw? 
19:35:13 <ghostway[m]> you cant "hide" trait methods 
19:38:38 * someoneelse49549 uploaded an image: (33KiB) < https://libera.ems.host/_matrix/media/v3/download/matrix.org/sUnafhcJSOItFfgyorHnNyHp/yes1.png >
19:38:43 <rbrunner> That looks pretty experimental
19:38:46 <someoneelse49549> i didn't invent it
19:39:56 <someoneelse49549> rbrunner: Yes, but hopefully with enough effort it could turn into a working thing
19:41:09 <rbrunner> In any case, you will certainly learn a lot
19:45:11 <ghostway[m]> <someoneelse49549> "yes.png" <- _yes_.png and _yes1_.png are the best 
19:45:33 <shalit[m]> rust🤮🤮🤮
19:55:03 <someoneelse49549> <shalit[m]> "rust🤮🤮🤮" <- I don't understand why people hate Rust so much. And at this point i'm too afraid to ask
20:11:20 <rbrunner> It's a while ago I vomitted looking at some code. Seen too much :)
20:21:49 <someoneelse49549> hope my code doesn't bring u back a trauma
22:02:55 <someoneelse49549> what's the difference between tx, pruned_tx and prunable_tx?
22:32:55 <jeffro256[m]> The names are sort of confusing. A pruned_tx is basically only the tx_prefix part of the transaction. So input mixrings, outputs, amounts. Prunable_tx is the part of the transaction which is pruned: RCT sigs, bulletproofs, etc. A normal tx is both things
22:34:50 <jeffro256[m]> pruned = what is left after pruning. Prunable = what is dropped from a full transaction
23:11:54 <tevador> Functional tests failing on master: https://github.com/monero-project/monero/actions/runs/4106333492/jobs/7086477747#step:9:1100
23:30:12 <selsta> will try to get it fixed
23:37:49 <jeffro256[m]> Likely b/c of this PR: https://github.com/monero-project/monero/pull/8692
23:39:01 <UkoeHB> yeah merged with failing test luigi1111w ?