02:35:19 Does anyone here have a link to the current pruning specification/experience with that code? I can only find entry-level posts on the concept of pruning. 02:39:42 https://monero-book.cuprate.org/pruning.html 02:41:01 also this: https://github.com/Cuprate/cuprate/blob/main/pruning/src/lib.rs 02:41:24 boog900: Thanks but that doesn't answer most of my questions actually. 02:41:59 I'm unsure if a pruned node syncs historic blocks in full and then prunes, or syncs pruned blocks. 02:42:32 I do see the within tip lack of pruning. 02:42:54 I'm also unclear what exactly is pruned. Just the proofs in RctPrunable? 02:44:08 by default it will sync full blocks but if you use `--sync-pruned-blocks` it will sync pruned blocks, from when bulletproofs are activated IIRC before that it will still sync full. 02:45:47 So a freshly synced pruned node can itself have validated the entire block chain, even if it can't convince others of validity, and can still completely service wallets? 02:48:02 also V1 signatures, although `monerod` will still store these. So even pruned nodes will store v1 txs unpruned. 02:49:16 well yes but most of the syncing is done with embedded hashes by default anyway. 02:52:32 https://github.com/monero-project/monero/blob/cc73fe71162d564ffda8e549b79a350bca53c454/src/cryptonote_protocol/cryptonote_protocol_handler.inl#L2059 02:53:19 we also only sync pruned blocks if we are using embedded hashes^ 02:53:53 So V1 signatures are prunable but monerod doesn't 02:54:37 And then Monero won't sync pruned blocks unless that flag is explicitly set, even if running a pruned node 02:55:05 And Cuprate won't sync pruned blocks unless the block is checkpointed and has that same flag. Is that flag default for pruned Cuprate nodes? 02:55:09 If you ask for a pruned V1 tx over RPC `monerod` will give the pruned tx (without signatures) but it will also be able to give a full tx if pruned. 02:55:37 Ah, weird, I see the distinction though. 02:55:44 Cuprate doesn't support pruning yet, so we only sync full blocks. 02:56:08 by we I meant `monerod` my bad 02:56:19 Oh, was "we" Monero, not "we" Cuprate? 02:56:23 yep 02:56:25 Got it 02:56:39 So Monero only syncs pruned blocks with the explicit flag and if checkpointed 02:57:47 yeah 02:58:11 Thanks for all the info :) If anyone has any corrections to throw in, please do so, but I'll otherwise trust boog 03:01:39 FWIW this is done as you can't reconstruct the hash like you can V2 txs, it reduces wallet traffic though so is till worth while to exclude the signatures there. 03:02:43 at least that's the explanation that makes sense to me that isn't actually documented. I ran into it while scanning all blocks using public nodes RPC 03:04:10 IIRC monerod just excludes the pruned txs if you ask for a full block so I was getting blocks with only some of the txs needed (only v1 txs) 03:04:59 wat 03:05:32 I'm sorry, Monero silently omits TXs? Which RPC route is this? 03:06:23 let me find the code it would be the get blocks by height bin 03:49:58 Yep just tested it `get_blocks_by_height.bin` will silently exclude pruned txs 03:50:21 ``` 03:50:21 numb txs: 12 03:50:23 numb txs included: 9 03:50:25 ``` 03:50:27 block: 1220558 03:50:35 on a pruned node 03:53:26 the block has 3 v2 txs and 9 v1 txs 05:38:01 Oooh that's weird 05:38:18 I'd venture to say that this is a bug 05:41:14 Definitely not expected behavior; usually I don't want *less* information when attempting to fetch full blocks instead of pruned blocks 10:11:11 .merges 10:11:11 -xmr-pr- 9389 10:15:47 .merge+ 9686 9685 9679 9666 9664 9663 9660 9659 9657 9656 9653 9650 9648 9646 9645 9644 9643 9639 9637 9633 9632 9628 9622 9621 9600 9544 9539 9528 9477 9470 9171 10:15:47 Added 10:18:24 More PRs for the grinder 10:21:17 Ah, yes. The mergeathon. 10:22:11 1 PR merged = 1 PR offered 10:22:13 sold limited in time 11:47:38 .merges 11:47:38 -xmr-pr- 9171 9389 9470 9477 9528 9539 9544 9600 9621 9622 9628 9632 9633 9637 9639 9643 9644 9645 9646 9648 9650 9653 9656 9657 9659 9660 9663 9664 9666 9679 9685 9686 12:28:04 conflicts: 9389 (cc jberman) 14:27:04

Can we get 7233 merged as well please? 14:28:01 You mean "reviewed" :P 14:40:10 .merges 14:40:10 -xmr-pr- 9171 9389 9470 9477 9528 9539 9544 9639 9643 9644 9645 9646 9648 9650 9653 9660 9663 9664 9666 9679 9685 9686 14:56:59 what remains is mine / needs rebase / comments addressed 14:57:13 need clarification on whether it's ok to merge my prs if 2-3 approvals + queued + tagged with ci/build system 14:57:25 i don't see a point in delaying these, especially the simpler ones (e.g. 9648, 9644, 9653) 15:21:46 tobtoht: do you expect reviews to be a bottleneck for 9440? 15:31:08 hinto: 9467 and 9453 could use reviews. i would like to get 9440 in a mergeable state as soon as possible, so we don't run into any delays for fcmp++ testnet. 16:07:17 You can def merge 9644 - its just CI + reviewed 16:09:05 tobtoht_ obey. Your king ofrnxmr grant you the honor of merging your own PR 16:09:35 Ok. I have been interested in learning Guix as getting FCMP++ online faster and bringing reproducible builds to Cuprate are large incentives. Having another active/liable reviewer for Guix PRs would also be good. 16:10:11 haha I discovered guix with these PRs. I was thinking about this as a topic for a cuprate meeting 16:10:20 ofrnxmr: thoughts on 9477? fixes a build issue, but isn't trivial 16:13:20 Has essentially 4 approvals, LGTM 16:16:04 .merges 16:16:04 -xmr-pr- 9171 9389 9470 9528 9539 9544 9639 9643 9645 9646 9648 9650 9653 9664 9666 9679 16:16:22 hinto: cool, feel free to dm me on matrix if you have any questions re guix 16:18:39 9679, 9639, 9539, 9528, 9470 look good as well 16:21:36 I think 9656 needs release pr jeffro256 16:32:40 Thats one thing we need to watch for. We have a number of "fix" prs that should be opened against release, but are hidden away on master for years 16:38:50 ofrnxmr: should i hold off on a merge to master if a pr against release is requested and isn't approved yet? (e.g. 9656) 16:38:56 so it isn't forgotten about 16:39:50 Imo yes. 9664 is another example as well 16:41:14 ok, makes sense. i will do that from now on. 16:46:44 .merges 16:46:44 -xmr-pr- 9171 9389 9544 9643 9645 9646 9648 9650 9653 9664 9666 16:51:01 Does 9643 need release tobtoht_ https://github.com/monero-project/monero/pull/9643#issuecomment-2589449792 17:46:52 ofrnxmr: 9656 has a release PR: 9657 18:00:14 Ty sir. I missed it 19:18:46 is #8929 and the documents added in it a good place to start? also if you are ok with it I think it could be beneficial to discuss things in here 19:29:02 hinto: yes, sure. the PR description for 8929 including the Q&A are a good place to start. the README goes in-depth on how to build and the associated security considerations. for the quickest way to get builds running refer to the PR description. 19:29:08 the two most important sections of code to understand are: https://github.com/monero-project/monero/blob/master/contrib/guix/manifest.scm#L224-L312 and https://github.com/monero-project/monero/blob/master/contrib/guix/libexec/prelude.bash#L45-L78 19:35:18 also https://github.com/monero-project/monero/blob/master/contrib/guix/guix-build#L366-L463 to learn how the build container is setup 19:36:55 useful for reference: https://guix.gnu.org/manual/en/html_node/Invoking-guix-environment.html 19:40:29 wondering if scan_tx has to be aware of the node being pruned/full or not after the earlier discussions 19:50:03 tobtoht: thanks 20:09:41 would like to get woodser 's opinion on 9389 since it reverts to behavior woodser prior pointed out in 8566 21:13:25 referring to this comment? https://github.com/monero-project/monero/pull/8566#issuecomment-1255299200 21:13:25 sounds like removing the call to refresh from scan_tx will fix the original issue, and compute the balance correctly, but a subsequent call to refresh is necessary to compute the number of confirmations or locked status? sounds like this fix is worth it then 21:14:32 yep, sweet :) ty