it's compiling with, so far so good:... (full message at libera.ems.host/_matrix/media/r0/do…923596cda75ce565f7793b93f120e92f4df)

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?

woodser[m]: monero-project/monero #8371

this has some explanation

thx

> would the burnt amount ever be different from the output amount?

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

tagging kayabanerve too to sanity check^

jberman: yep!

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.

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:.

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

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.

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.

If you're curious the literal place they're filled in, I believe cryptonote_basic

It does most of the data handling for RCT

But in the function genrctsimple() there was nothing like this

Hlo where are you

Output commitment are created by bulletproof_PROVE() but for pseudo i am not getting which function builds them.

And i got nothing in cryptonote_basic i checked it.

There's a function to create commitments called `genC`

Yes actually i got it

Before only but thanks a lot for giving your timing and finding it.

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.

This community is great.

Sorry, was responding to another few messages :p

I re-opened the TX extra discussion and we've had a few comments there...

🤣

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.

Thanks a lot once again for giving your time.

Hi! Does monero Bulletproofs transactions still will be supported in monero blockchain after Bulletproofs+ release?

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

there should be roughly a day when both are accepted, which allows tx made around fork time to still go through

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

cause let's dont do that again lol

Lyza: we have a patch that avoids that this time

<3

sirs while using newest release

on unrestricted rpc I see "target_height": 0,

on my nodes

is this expected?

yes

assuming your node is synced

hopefully it is :D

thanks selsta

there should be a synchronized true field

yes I see it in the logs

though was used to seing smth in target_height before

no biggie if all is working :P

[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.

you mean this ^

no, I meant get_info has a synchronized field

duh!

"synchronized": true,

tks

target_height is valid if you're syncing. If you're not, its value is... not random, but not relevant.

ic

thanks guys :)

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