00:17:10 <woodser[m]> 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 <woodser[m]> 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 <selsta> woodser[m]: https://github.com/monero-project/monero/pull/8371
00:32:40 <selsta> this has some explanation
00:33:43 <woodser[m]> thx
00:42:00 <jberman[m]> > would the burnt amount ever be different from the output amount?
00:42:00 <jberman[m]> 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 <jberman[m]> tagging kayabanerve too to sanity check^
05:32:46 <kayabanerve[m]> jberman: yep!
09:17:45 <kayabanerve[m]> 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 <kayabanerve[m]> 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 <yrt> 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 <yrt> 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 <kayabanerve[m]> 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 <kayabanerve[m]> If you're curious the literal place they're filled in, I believe cryptonote_basic 
10:34:54 <kayabanerve[m]> It does most of the data handling for RCT
10:37:02 <yrt> But in the function genrctsimple() there was nothing like this
10:40:04 <yrt> Hlo where are you
10:40:46 <yrt> Output commitment are created by bulletproof_PROVE() but for pseudo i am not getting which function builds them.
10:41:52 <yrt> And i got nothing in cryptonote_basic i checked it.
10:47:49 <kayabanerve[m]> There's a function to create commitments called `genC`
10:48:18 <yrt> Yes actually i got it
10:48:47 <yrt> Before only but thanks a lot for giving your timing and finding it.
10:48:54 <kayabanerve[m]> 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 <yrt> This community is great.
10:49:12 <kayabanerve[m]> Sorry, was responding to another few messages :p
10:49:25 <kayabanerve[m]> I re-opened the TX extra discussion and we've had a few comments there...
10:49:40 <yrt> 🤣
10:50:29 <yrt> 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 <yrt> Thanks a lot once again for giving your time.
17:58:21 <Guest57> Hi! Does monero Bulletproofs transactions still will be supported in monero blockchain after Bulletproofs+ release?
18:00:46 <rbrunner> 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 <luigi1112> there should be roughly a day when both are accepted, which allows tx made around fork time to still go through
18:45:06 <Lyza> 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 <Lyza> cause let's dont do that again lol
18:45:48 <selsta> Lyza: we have a patch that avoids that this time
18:45:55 <Lyza> <3
20:15:28 <kico> sirs while using newest release
20:15:38 <kico> on unrestricted rpc I see "target_height": 0,
20:15:42 <kico> on my nodes
20:15:46 <kico> is this expected?
20:16:43 <selsta> yes
20:16:55 <selsta> assuming your node is synced
20:17:33 <kico> hopefully it is :D
20:17:35 <kico> thanks selsta 
20:18:04 <selsta> there should be a synchronized true field
20:19:19 <kico> yes I see it in the logs
20:19:32 <kico> though was used to seing smth in target_height before
20:19:39 <kico> no biggie if all is working :P
20:21:26 <kico> [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 <kico> you mean this ^
20:23:09 <selsta> no, I meant get_info has a synchronized field
20:23:44 <kico> duh! 
20:23:47 * kico hides
20:23:50 <kico> "synchronized": true,
20:23:51 <kico> tks
20:27:21 <moneromooo> target_height is valid if you're syncing. If you're not, its value is... not random, but not relevant.
20:31:22 <kico> ic
20:33:11 <kico> thanks guys :)
20:34:08 <plowsof> 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