<k​ayabanerve:matrix.org> 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.

<b​oog900:monero.social> monero-book.cuprate.org/pruning.html

<b​oog900:monero.social> also this: github.com/Cuprate/cuprate/blob/main/pruning/src/lib.rs

<k​ayabanerve:matrix.org> boog900: Thanks but that doesn't answer most of my questions actually.

<k​ayabanerve:matrix.org> I'm unsure if a pruned node syncs historic blocks in full and then prunes, or syncs pruned blocks.

<k​ayabanerve:matrix.org> I do see the within tip lack of pruning.

<k​ayabanerve:matrix.org> I'm also unclear what exactly is pruned. Just the proofs in RctPrunable?

<b​oog900:monero.social> 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.

<k​ayabanerve:matrix.org> 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?

<b​oog900:monero.social> also V1 signatures, although `monerod` will still store these. So even pruned nodes will store v1 txs unpruned.

<b​oog900:monero.social> well yes but most of the syncing is done with embedded hashes by default anyway.

<b​oog900:monero.social> github.com/monero-project/monero/bl…yptonote_protocol_handler.inl#L2059

<b​oog900:monero.social> we also only sync pruned blocks if we are using embedded hashes^

<k​ayabanerve:matrix.org> So V1 signatures are prunable but monerod doesn't

<k​ayabanerve:matrix.org> And then Monero won't sync pruned blocks unless that flag is explicitly set, even if running a pruned node

<k​ayabanerve:matrix.org> 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?

<b​oog900:monero.social> 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.

<k​ayabanerve:matrix.org> Ah, weird, I see the distinction though.

<b​oog900:monero.social> Cuprate doesn't support pruning yet, so we only sync full blocks.

<b​oog900:monero.social> by we I meant `monerod` my bad

<k​ayabanerve:matrix.org> Oh, was "we" Monero, not "we" Cuprate?

<b​oog900:monero.social> yep

<k​ayabanerve:matrix.org> Got it

<k​ayabanerve:matrix.org> So Monero only syncs pruned blocks with the explicit flag and if checkpointed

<b​oog900:monero.social> yeah

<k​ayabanerve:matrix.org> Thanks for all the info :) If anyone has any corrections to throw in, please do so, but I'll otherwise trust boog

<b​oog900:monero.social> 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.

<b​oog900:monero.social> 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

<b​oog900:monero.social> 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)

<k​ayabanerve:matrix.org> wat

<k​ayabanerve:matrix.org> I'm sorry, Monero silently omits TXs? Which RPC route is this?

<b​oog900:monero.social> let me find the code it would be the get blocks by height bin

<b​oog900:monero.social> Yep just tested it `get_blocks_by_height.bin` will silently exclude pruned txs

<b​oog900:monero.social> ```

<b​oog900:monero.social> numb txs: 12

<b​oog900:monero.social> numb txs included: 9

<b​oog900:monero.social> ```

<b​oog900:monero.social> block: 1220558

<b​oog900:monero.social> on a pruned node

<b​oog900:monero.social> the block has 3 v2 txs and 9 v1 txs

<j​effro256:monero.social> Oooh that's weird

<j​effro256:monero.social> I'd venture to say that this is a bug

<j​effro256:monero.social> Definitely not expected behavior; usually I don't want *less* information when attempting to fetch full blocks instead of pruned blocks

.merges

.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

Added

<s​yntheticbird:monero.social> More PRs for the grinder

<r​ottenwheel:unredacted.org> Ah, yes. The mergeathon.

<s​yntheticbird:monero.social> 1 PR merged = 1 PR offered

<s​yntheticbird:monero.social> sold limited in time

.merges

conflicts: 9389 (cc jberman)

<a​ck-j:matrix.org> Can we get 7233 merged as well please?

You mean "reviewed" :P

.merges

what remains is mine / needs rebase / comments addressed

need clarification on whether it's ok to merge my prs if 2-3 approvals + queued + tagged with ci/build system

i don't see a point in delaying these, especially the simpler ones (e.g. 9648, 9644, 9653)

<h​into:monero.social> tobtoht: do you expect reviews to be a bottleneck for 9440?

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.

You can def merge 9644 - its just CI + reviewed

<s​yntheticbird:monero.social> tobtoht_ obey. Your king ofrnxmr grant you the honor of merging your own PR

<h​into:monero.social> 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.

<s​yntheticbird:monero.social> haha I discovered guix with these PRs. I was thinking about this as a topic for a cuprate meeting

ofrnxmr: thoughts on 9477? fixes a build issue, but isn't trivial

Has essentially 4 approvals, LGTM

.merges

<t​obtoht:monero.social> hinto: cool, feel free to dm me on matrix if you have any questions re guix

9679, 9639, 9539, 9528, 9470 look good as well

I think 9656 needs release pr jeffro256

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

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)

so it isn't forgotten about

Imo yes. 9664 is another example as well

ok, makes sense. i will do that from now on.

.merges

Does 9643 need release tobtoht_ monero-project/monero #9643#issuecomment-2589449792

<j​effro256:monero.social> ofrnxmr: 9656 has a release PR: 9657

Ty sir. I missed it

<h​into:monero.social> 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

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.

the two most important sections of code to understand are: github.com/monero-project/monero/bl…contrib/guix/manifest.scm#L224-L312 and github.com/monero-project/monero/bl…b/guix/libexec/prelude.bash#L45-L78

also github.com/monero-project/monero/bl…r/contrib/guix/guix-build#L366-L463 to learn how the build container is setup

useful for reference: guix.gnu.org/manual/en/html_node/Invoking-guix-environment.html

wondering if scan_tx has to be aware of the node being pruned/full or not after the earlier discussions

<h​into:monero.social> tobtoht: thanks

<j​berman:monero.social> would like to get woodser 's opinion on 9389 since it reverts to behavior woodser prior pointed out in 8566

<w​oodser:monero.social> referring to this comment? monero-project/monero #8566#issuecomment-1255299200

<w​oodser:monero.social> 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

<j​berman:monero.social> yep, sweet :) ty