00:17:10 it's compiling with, so far so good:... (full message at https://libera.ems.host/_matrix/media/r0/download/libera.chat/c8d6e923596cda75ce565f7793b93f120e92f4df) 00:29:48 I gather the new `burnt` field in on_money_received() represents the amount burned using the burn bug. since on_money_received() fires for each output, would the burnt amount ever be different from the output amount? 00:32:32 woodser[m]: https://github.com/monero-project/monero/pull/8371 00:32:40 this has some explanation 00:33:43 thx 00:42:00 > would the burnt amount ever be different from the output amount? 00:42:00 Receive output A for 1 XMR in tx A, receive output B with the same output pub key as output A at a later date for 5 XMR in tx B. You receive 5 XMR in tx B, 1 XMR is burnt in tx B, and your reflected increase in balance should be 4 XMR 00:42:11 tagging kayabanerve too to sanity check^ 05:32:46 jberman: yep! 09:17:45 I think BP+ proving can be made somewhat faster. There was a couple functions defined solely used in verification, notably sum_of_even_powers. BP+ providing independently calculates even_powers, fine, except it does it twice. It didn't feel as tightly knit as BP proving. 09:19:37 I would also like to say I despise the fact hash_cache_mash always returns a Scalar, which is also always the first arg in the next call, yet for some reason, the BP+ transcript DST is a point. It's never used as a point. It's just a point, relying on rct::key's untyped ambiguity, leading to manually having to impl a Point variation in any re-impls D:. 10:26:34 I am not getting which function is creating pseudo output commitment as given in ztm2 genrctsimple() is doing everything I searched in and i found a keyV Pseudooutput is filled with rv.p.pseudooputputs but i am not getting from where this rv.p is getting that value as Ringsig rv is declared inside the function so no chance it was filled by some 10:26:34 other functions nor do it gives its struct as pointer. So who actually filled value in rv.p.pseudooutputs or which function create pseudo commitments. 10:34:29 yrt: They used to be rv.pseudoOuts, but they were moved to rv.p.pseudoOuts as they're prunable. If you're going through the logical process of it, you can treat them as equivalent. 10:34:50 If you're curious the literal place they're filled in, I believe cryptonote_basic 10:34:54 It does most of the data handling for RCT 10:37:02 But in the function genrctsimple() there was nothing like this 10:40:04 Hlo where are you 10:40:46 Output commitment are created by bulletproof_PROVE() but for pseudo i am not getting which function builds them. 10:41:52 And i got nothing in cryptonote_basic i checked it. 10:47:49 There's a function to create commitments called `genC` 10:48:18 Yes actually i got it 10:48:47 Before only but thanks a lot for giving your timing and finding it. 10:48:54 My comment was that pseudoOuts, which I actually think are serialized with the overall structure on second thought, sorry, would be checked in cryptonote_basic, which also moves a few other pieces of data into RCT. 10:48:56 This community is great. 10:49:12 Sorry, was responding to another few messages :p 10:49:25 I re-opened the TX extra discussion and we've had a few comments there... 10:49:40 🤣 10:50:29 Actually when I gone through from where it is getting it's value i found actually it's getting zeros from rv.p.commitments and genC is wht filling the values in it. 10:50:42 Thanks a lot once again for giving your time. 17:58:21 Hi! Does monero Bulletproofs transactions still will be supported in monero blockchain after Bulletproofs+ release? 18:00:46 Don't think so, no. Having to use BP+ is probably part of consensus and enforced, a tx not using it being malformed and getting rejected 18:40:09 there should be roughly a day when both are accepted, which allows tx made around fork time to still go through 18:45:06 everyone remembers that one hard fork when there were still old style TXs in the mempool at the second fork boundary and nodes that were offline at the time couldn't sync, right :3 18:45:20 cause let's dont do that again lol 18:45:48 Lyza: we have a patch that avoids that this time 18:45:55 <3 20:15:28 sirs while using newest release 20:15:38 on unrestricted rpc I see "target_height": 0, 20:15:42 on my nodes 20:15:46 is this expected? 20:16:43 yes 20:16:55 assuming your node is synced 20:17:33 hopefully it is :D 20:17:35 thanks selsta 20:18:04 there should be a synchronized true field 20:19:19 yes I see it in the logs 20:19:32 though was used to seing smth in target_height before 20:19:39 no biggie if all is working :P 20:21:26 [P2P2] INFO global src/cryptonote_protocol/cryptonote_protocol_handler.inl:2482 You are now synchronized with the network. You may now start monero-wallet-cli. 20:21:35 you mean this ^ 20:23:09 no, I meant get_info has a synchronized field 20:23:44 duh! 20:23:47 * kico hides 20:23:50 "synchronized": true, 20:23:51 tks 20:27:21 target_height is valid if you're syncing. If you're not, its value is... not random, but not relevant. 20:31:22 ic 20:33:11 thanks guys :) 20:34:08 semi related but i had some confusion today with the wallet rpc call of 'get_height' which hangs indefinitely / only returns the height when the wallet is fully synced