tobtoht_: should we revert the patch that introduced the test failure? or does it appear easy to fix?

<o​frnxmr:xmr.mx> valldrac

selsta: it's an edge case that only affects those tests. we shouldn't use (mainnet) checkpoints there, because we're mining from genesis.

not initializing checkpoints if we're running tests or simply ignoring checkpoints below height 1k would fix the issue

<o​frnxmr:xmr.mx> Does it effect something like testnet?

<o​frnxmr:xmr.mx> (More specifically, an alpha testnet for fcmp (mined from genesis))

no, realistically only affects regtest unless alpha testnet exceeds 1M blocks and checkpoints are never updated

<o​frnxmr:xmr.mx> thanks

<a​non_contributor_xmr:monero.social> Hey, what is the current status of reproducible builds with guix?

<a​non_contributor_xmr:monero.social> I have tried it on two different machines and it successfully built the same binaries (also it was quite easy to setup and run, as opposed to gitian which I have tried a few times but gave up after a few failed attempts..), so I am wondering why is it not included in the release branch, are there any problems/blockers with it that I am unaware of?

<o​frnxmr:xmr.mx> Its on master only

<a​non_contributor_xmr:monero.social> Yeah I noticed that, hence my question - why is it only on master branch, and not in the release branch, are there any problems with it?

<t​obtoht:monero.social> we'll branch from master somewhere in the coming months

<t​obtoht:monero.social> no problems with it. backporting to release would have gotten too complicated

<a​non_contributor_xmr:monero.social> Good to know that there are no problem with it :) Why is backporting complicated? I wanted to use it to experiment with building Monfluo reproducibly, but I guess it will not be as easy as taking contrib/guix (plus dependencies like contrib/shell) from the master branch? :(

<t​obtoht:monero.social> nope, unfortunately. it depends on dozens of changes to contrib/depends

<o​frnxmr:xmr.mx> Just use master

<a​non_contributor_xmr:monero.social> Ah got it :(

<a​non_contributor_xmr:monero.social> Thanks for the info!

<o​frnxmr:xmr.mx> nothing wrong with using master for monfluo

<a​non_contributor_xmr:monero.social> I think I would rather just wait until guix gets into a release branch, it is not a huge priority for me right now :)

<o​frnxmr:xmr.mx> It will be branched from master when it does :P. only diff is a tag

<o​frnxmr:xmr.mx> (release hasnt been branched from master in years now. When guix hits release, it will be the first time we've branched master in yrs)

<k​eyur279:matrix.org> I'm implementing CLSAG and confused about z and C[l]. In Monero's clsag_gen there's a comment C[l] == z*G. I assumed C[l] is the Pedersen commitment of my UTXO and z = original_mask - pseudo_mask. But mathematically if original_mask*G + amount*H == (original_mask - pseudo_mask)*G then amount*H == -pseudo_mask*G which seems impossible. What exactly should C[l] and z be in CLSAG? Is<clipped message>

<k​eyur279:matrix.org> C[l] not the original UTXO commitment or is z something other than original_mask - pseudo_mask? Would appreciate if someone familiar with the CLSAG internals could clarify this!

<j​effro256:monero.social> Randomly279: see monero-project/monero #9605/files for a bit of help. `C_nonzero` is the "original" amount commitment which shows up in the transaction output. `Cout` is the "pseudo amount commitmernt" which shows up in the input. `C` is the "commitment to zero". Yeah the naming is pretty funky

<j​effro256:monero.social> `C_offset` is the other symbol used for `Cout` or the "pseudo amount commitment". So what the comment is saying when it says that `C[l] == zG` and `C[i] == C_nonzero[i] - C_offset` is that the `z`, at each `i`, you pass is the discrete log of the "commitment to zero", which is the difference in blinding factor between the original transaction output and the pseudo amount commitment