The view wallet has only a privateViewKey and is able to recognize transactions sent to subaddresses of the wallet. When I query the view wallet rpc:... (full message at libera.ems.host/_matrix/media/r0/do…05f993017bee40fb358b32844f6504e61e1)

* The view wallet has only a privateViewKey and is able to recognize transactions sent to subaddresses of the wallet. When I query the view wallet rpc:... (full message at libera.ems.host/_matrix/media/r0/do…1ad03c19c61a3018e7f2d1de87e90a3e3d1)

I am not a c++ developer. I can barely read it. Can somebody point out, where in the monero repo is the code with which the view wallet parses the mumble jumble transaction data into readable data like this?... (full message at libera.ems.host/_matrix/media/r0/do…0c988eb98e05a3dccc98c13207a30171dac)

is where it does the check that an output goes to an account

it uses the secret view key there

and it's called from wallet2.cpp

but you're probably asking about getmonero.org/resources/developer-guides/wallet-rpc.html

Could someone leave an approval to this: monero-project/monero-site #1448 ? We reallyneed to merge it

I *think* next_seed_hash is set something like 64 blocks in advance, not just for the next block. sech1 might know for sure.

seed_hash is used for calculating PoW

next_seed_hash is what will be used starting from the next RandomX epoch (block N*2048+65)

and this is the hash of block N*2048

it was supposed to be used by miners to precalculate the next dataset, but de facto all miners just use seed_hash and update the dataset when it changes

done

yeah I can't see how pre-calculating the dataset is an advantage, it will eat RAM bandwidth while mining threads are still working

which is prob why no one has bothered to implement the precalc in production mining code.\

we can probably delete that from a future rpc version

next seed hash can be obtained from get_block_header_by_height RPC call anyway

precalculating dataset might be useful when it's required to calculate PoW hashes quickly all the time (not normal mining, but checking PoW for example)

yes, if they know the epoh calculation

the advantage of putting it in the rpc is that miner doesn't need to know what chain or algo variant it's talking to

miner needs to know algo variant though

yeah, true

but anyway, you can either take the delay all at once, by halting hashing to calculate a new dataset, or you can spread it out by precalcing a new dataset while still hashing on current one

it will actually be more efficient to just halt hashing and calculate dataset when needed

Does anyone know how is the status of the rpc-pay functionality? Are people using it? I believe that the savings in the maintenance of nodules is crucial for the health of the Monero network.

If not here, where is the best place to discuss the economic aspects of the network?

try #monero

Ok I will do same question there.

You likely did not, you might have asked in matrix's copy.

he did

ask in the matrix room

I think the IRC bridge for that room hasn't been working for a minute

Well, the big thing I did not really appreciate at the time is that spaying assholes will be there to supply nodes that do not charge, and so people who do not know better will use them because they'll see "free", same as people use google now because free and their whole digital life gets corporate recorded.

A similar argument applies to PoW FWIW. Prurient govts who want to fuck with us could just mine a lot to 51% us, because they don't care about the mining cost, they can just increase taxes so it's us who pay for it.

That's the utter injustice of it all. The more we spend effort to protect ourselves, the more we'll pay to fuck ourselves by way of taxes to pay to circumvent our efforts.

Fuck this fucking world.

I guess it's kind of chicken and egg. we could train users to some extent to avoid free rpc nodes but I personally haven't set it up precisely because it's not used. maybe if it were a default, idk

UkoeHB: what do you think is a realistic timeframe until multisig changes are reviewed/merged?

thinking about doing a GUI point release, not sure if I should wait or not

I think vtnerd can answer that better. My todo list is empty on that front.

ok

my guess is a couple weeks but we will see...

welp ok I will do a GUI point release

selsta: we have more translations I'd like to push

Squashed this time :)

netrik182: ok PR them soon please

Are you planning for this year yet?

OK, will do

Tomorrow morning if that's ok

I am young, and learning to code. I will be pursuing a bachelors in Computer Science. To be honest, trying to understand some of the Monero code seems way over my head but nevertheless I'm here. Can't say I'll add anything to the conversation or be of any help; but hopefully in the far future I will be able to contribute. For now, I just wanted to introduce myself and make sure that it was okay if I asked any questions here in

regards to the code... if not can someone direct me to another channel? Thanks.

cypherhunk[m]: hi, yes this is the dev channel so it's appropriate to ask code questions here.

<cypherhunk[m]> "I am young, and learning to code..." <- Welcome!

FYI, in addition to the work on Monero (and yes you can discuss code here), there's stuff going on on Haveno, which is a Monero-based Dex- their Matrix room is [Haveno](app.element.io/#/room/#haveno:haveno.network) and [Haveno Development](app.element.io/#/room/#haveno-dev:haveno.network) and there's an XMR<->ETH atomic swap project going on at: (github.com/noot/atomic-swap)

For good intro-to-monero guides, check out Zero-To-Monero v2 (web.getmonero.org/library/Zero-to-Monero-2-0-0.pdf) and Mastering Monero (masteringmonero.com <-free download on that page).

There are also a bunch of Monero Bounties with varying amounts of funding waiting for a dev to build them here: bounties.monero.social/

> <@crypto_grampy:monero.social> Welcome!... (full message at libera.ems.host/_matrix/media/r0/do…605e90e5381ae7aca3b1125fa7be4ba7bed)