08:40:13 tobtoht_: should we revert the patch that introduced the test failure? or does it appear easy to fix? 08:52:47 valldrac 11:45:52 selsta: it's an edge case that only affects those tests. we shouldn't use (mainnet) checkpoints there, because we're mining from genesis. 11:46:01 not initializing checkpoints if we're running tests or simply ignoring checkpoints below height 1k would fix the issue 11:47:45 Does it effect something like testnet? 11:56:25 (More specifically, an alpha testnet for fcmp (mined from genesis)) 12:25:37 no, realistically only affects regtest unless alpha testnet exceeds 1M blocks and checkpoints are never updated 12:28:35 thanks 13:19:29 Hey, what is the current status of reproducible builds with guix? 13:19:29 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? 13:20:27 Its on master only 13:22:16 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? 13:22:39 we'll branch from master somewhere in the coming months 13:23:33 no problems with it. backporting to release would have gotten too complicated 13:25:46 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? :( 13:27:25 nope, unfortunately. it depends on dozens of changes to contrib/depends 13:27:37 Just use master 13:27:40 Ah got it :( 13:27:41 Thanks for the info! 13:27:52 nothing wrong with using master for monfluo 13:29:10 I think I would rather just wait until guix gets into a release branch, it is not a huge priority for me right now :) 13:29:52 It will be branched from master when it does :P. only diff is a tag 13:31:38 (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) 15:43:31 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 15:43:31 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! 23:25:14 Randomly279: see https://github.com/monero-project/monero/pull/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 23:29:15 `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