17:08:17
boog900:monero.social:
meeting here in ~50 mins
18:00:19
boog900:monero.social:
!meeting
18:00:21
moo:monero.social:
Starting meeting: https://github.com/monero-project/meta/issues/1298
18:00:38
boog900:monero.social:
1. greetings
18:02:32
hinto:monero.social:
hello
18:02:44
boog900:monero.social:
2. Updates
18:07:25
boog900:monero.social:
me: I have been working on FCMP tree building still, trying to make sure it is as efficient as possible. Also added shutdown code to cuprated, as with database split across 2 systems it is a bit more fragile.
18:08:07
hinto:monero.social:
me: preparing `cuprated v0.0.8` and finishing up on PoWER tests to match C++/Rust output
18:08:38
boog900:monero.social:
current tree building is pretty much a background task and is only interacted with when needed, which is different to how monerod currently does it.
18:09:08
boog900:monero.social:
3) Project: What is next for Cuprate?
18:09:32
boog900:monero.social:
I intend to review the 0.0.8 PR today
18:09:39
boog900:monero.social:
I juts need to check the hashes
18:10:39
hinto:monero.social:
It assumes 562 is included as well
18:12:12
hinto:monero.social:
The killswitch for 0.0.7 activates tomorrow so hopefully we can release today?
18:13:57
boog900:monero.social:
yeah sure
18:15:07
boog900:monero.social:
how do you feel about the linear tape DB? I haven't marked it as ready for review yet but they is quite a bit of unsafe in there.
18:15:36
boog900:monero.social:
also atomics
18:16:18
boog900:monero.social:
I tried to add a loom test but loom doesn't like memory maps IIRC
18:17:34
boog900:monero.social:
also Miri doesn't like memory maps
18:19:21
boog900:monero.social:
I have thought about putting it in its own repo?
18:21:18
hinto:monero.social:
AFAIC if there is sufficient usage and testing then go wild
18:24:34
boog900:monero.social:
nice, is this something you have experience in for the review?
18:24:36
boog900:monero.social:
If not then no worries
18:29:14
hinto:monero.social:
both the memory map and atomic usage don't seem too complicated
18:31:34
rucknium:monero.social:
boog900: Do you have a rough estimate of how much database "overhead" there is in `monerod`'s database? In the scaling discussion, it would be good to know how much padding needs to be added to the FCMP tx size numbers.
18:33:46
boog900:monero.social:
ah thats good then, I should be able to mark it ready for review soon
18:36:18
boog900:monero.social:
here as the raw table sizes as of a couple weeks ago:
18:36:18
boog900:monero.social:
```
18:36:20
boog900:monero.social:
boog900:
18:36:22
boog900:monero.social:
4.0K ./lock.mdb
18:36:24
boog900:monero.social:
21G ./data.mdb
18:36:26
boog900:monero.social:
11G ./rct_outputs.tape
18:36:28
boog900:monero.social:
18G ./prunable/stripe2.tape
18:36:30
boog900:monero.social:
17G ./prunable/stripe1.tape
18:36:32
boog900:monero.social:
18G ./prunable/stripe6.tape
18:36:34
boog900:monero.social:
18G ./prunable/stripe3.tape
18:36:36
boog900:monero.social:
18G ./prunable/stripe7.tape
18:38:09
boog900:monero.social:
so we can just sum `pruned.tape` and the `stripeX.tape` for an estimate of the size of all the tx/block blobs in the DB, which comes to 170 GB
18:38:47
rucknium:monero.social:
Thanks! Is it reasonable to say "monerod's database is X GB, cuprate's is Y GB. We should pad FCMP tx sizes by (X/Y - 1)%"?
18:42:36
rucknium:monero.social:
What is the status of cuprate's RPC? If I can, I would like to make a cuprate-compatible version of https://stressnetnode1.moneronet.info/ for beta stressnet. These are the calls that I use: get_info, get_transaction_pool_stats, get_last_block_header, get_fee_estimate, get_connections, get_bans
18:43:13
rucknium:monero.social:
I don't necessarily have to have all those RPC methods available.
18:44:09
boog900:monero.social:
hmm, honestly I am not sure if it'll work out like that, it all depends on how LMDB deals with the values. Smaller values _should_ lead to less wasted space (I would think) and by just using the total DB sizes you are including all database tables, some of which have small values.
18:45:25
boog900:monero.social:
LMDB database size highly depends on it reclaiming old pages too, you can get a database huge by just holding open a read tx while monerod is syncing
18:46:30
hinto:monero.social:
This would be cleaner although you'll have to setup CI to be as strict as Cuprate/cuprate and maintain it over time
18:47:44
hinto:monero.social:
Rucknium: here's a list of the currently activated endpoints: https://user.cuprate.org/rpc.html
18:48:52
hinto:monero.social:
many of those are actually practically ready but the focus is on endpoints required by wallet2 for now, unless boog900 wants to change that :)
18:49:00
boog900:monero.social:
your best bet would probably be to note this and as a best effort you can make a calculation like that as an example?
18:51:16
rucknium:monero.social:
hinto: Thanks. Everything I need is available 😁
18:53:33
boog900:monero.social:
I think I would like to do this, for now, I think it will be easier to make changes to it especially as I am using it across multiple branches right now
18:53:48
hinto:monero.social:
boog900: perhaps we could enable certain "incomplete" endpoints for now, lots of them are not since misc fields aren't available / don't make sense for `cuprated` e.g. `get_info`: https://github.com/Cuprate/cuprate/blob/a9ef306bdbfee3b2ff11f11f3553cc645471dc57/binaries/cuprated/src/rpc/handlers/json_rpc.rs#L452
18:54:30
rucknium:monero.social:
Wait. I think I misread the table
18:54:46
rucknium:monero.social:
😅
18:54:52
boog900:monero.social:
I have a branch in waiting for wallet sync support
18:55:03
boog900:monero.social:
I'll PR that at some point
18:55:23
boog900:monero.social:
I wanted to make the changes to the DB first though
18:58:57
boog900:monero.social:
`get_info` is needed for wallet sync so I exposed it on that branch
18:59:37
boog900:monero.social:
`get_connections` would be the only one I am unsure if we could support quickly
19:00:32
boog900:monero.social:
anything else for today?
19:01:34
boog900:monero.social:
ok I think we can end here, thanks everyone!
19:01:43
boog900:monero.social:
!meeting
19:01:46
moo:monero.social:
- Logs: https://github.com/monero-project/meta/issues/1298#issuecomment-3577138534
19:01:46
moo:monero.social:
- Next meeting: https://github.com/monero-project/meta/issues/1302
19:14:23
boog900:monero.social:
hinto: with PoWER are you planing to change cuprate code or just add the new libs?
19:33:57
hinto:monero.social:
I planned to change the code
19:39:48
hinto:monero.social:
If `cuprated` eventually participates in the stressnet it would get banned/ignored on >8 input tx relays, so it's probably best to implement it sooner rather than later
19:41:01
boog900:monero.social:
fair, however if we didn't support it we would just add dropping for every >8 input tx
19:41:27
hinto:monero.social:
btw newer crates (linear DB) could start using `edition = "2024"`
19:41:28
boog900:monero.social:
there are a lot of changes we are going to need to make for FCMP lets hope we can get them all in
19:42:12
boog900:monero.social:
I have a draft PR changing them all IIRC
19:42:22
boog900:monero.social:
forgot why I didn't keep working on it
19:42:45
boog900:monero.social:
CI logs have been deleted
19:43:56
hinto:monero.social:
I give it 25% chance that edition 2026 comes out before that PR is ready
19:44:22
boog900:monero.social:
is that the next edition 👀
19:44:46
boog900:monero.social:
not 2027?
19:45:31
hinto:monero.social:
the Rust team will release it early to screw your PR
19:45:41
boog900:monero.social:
lol
19:45:57
boog900:monero.social:
tbf it is already so out of date starting fresh would be a good idea
19:46:33
boog900:monero.social:
2024 does bring some nice things too
19:46:47
boog900:monero.social:
allows us to remove some TODOs
20:45:54
kayabanerve:matrix.org:
Friendly reminder that any crate in the workspace having edition 2024 forces a MSRV on everything to a 2024-capable compiler.
20:46:38
kayabanerve:matrix.org:
I don't encourage Cuprate to care but oxide has been bitten by the MSRV bug due to Guix
20:46:38
boog900:monero.social:
TIL
20:46:40
boog900:monero.social:
even if you specify an older one on some crates?
20:46:49
kayabanerve:matrix.org:
You can workaround by defining two workspaces afaik
20:46:59
kayabanerve:matrix.org:
Yeah, because evaluating the crate requires evaluating the workspace
20:47:44
kayabanerve:matrix.org:
Serai, for our patched crates which largely just re-export a distinct version, defines each patch as within its own workspace specifically to avoid some such annoyances
20:48:38
kayabanerve:matrix.org:
Oh. If it was in the same workspace, it'd never get flagged as unnecessary. By giving each crate its own workspace, it would get flagged as an unused del.
20:48:46
kayabanerve:matrix.org:
Oh. If it was in the same workspace, it'd never get flagged as unnecessary. By giving each crate its own workspace, it would get flagged as an unused dep.
20:55:46
kayabanerve:matrix.org:
I'm not advocating this. I'm noting I wouldn't set edition 2024 for the hell of it. I'd either want a specific feat from it or already have sufficiently high MSRVs.
20:57:12
kayabanerve:matrix.org:
Same with MSRVs in general. I'd update the MSRV without minding when I pull in a feat. I wouldn't set the MSRV to 1.91 for the hell of it though.
20:58:03
kayabanerve:matrix.org:
Though the new RPC PR would be able to remove some explicit capture clauses with the 2024 edition, so I do regret that oxide has accepted some MSRV limitations...
21:01:24
kayabanerve:matrix.org:
core-json adopted 2024 when the MSRV was already high enough.
21:01:25
kayabanerve:matrix.org:
(as an anecdote)