are there any reasonably sane estimates how much of the Monero hashrate is centralized/commercial/industrial vs. residential?

or at least some upper/lower bounds?

stats like this establish some bounds but again we don't know who's in these pools

I'm sure someone has done thinking on this?

y: This belongs more in #monero-research-lounge:monero.social

Elijah[m], hyc: Thanks for the tips. I could have sworn I had seen other, previous instances of `time_t` in the RPC interface, but you are right, it uses uint64_t

I will switch to that as well

It took me hours to find that btw...

s/It took me hours to find that btw.../It took me hours to figure it that out btw.../

Hmmm. I hope you were rewarded by learning some things? :)

I am thankful you did find it out, I was so convinced that `time_t` is the way to do it in the RPC interface, that could have taken a long time for myself to find out.

<Rucknium[m]> "Those big guys should write a..." <- We see this pattern quite regularly.

There are some features which have truly **nothing** to do at the protocol level and can and should be implemented at the application level.

But yet peoples from the application level often ask, sometimes successfully, to have the feature done at the protocol level.

It's understandable (better another than me coding the thing) but in the long run putting too much application specific things in the protocol level does not really help the project.

I try again: i've been working on stopping most of my volunteers contributions to the Monero project. This includes managing weblate's backend (translate.getmonero.org). I already asked the core team to find somebody else for the job, but i haven't received any answer. Now i ask them again to find somebody willing to take care of it (translations repositories management - like pushing strings-, management of weblate, management of the box, etc).

I'm still taking care of it, but i will not do it indefinitely. At one point i'll just stop. Note that the result would be the entire translations process to be stuck until somebody else takes over. I once again ask core to consider the issue and to contact me so we can find a replacement.

luigi1111 binaryfate fluffypony ^

There is currently no way to sign something against subaddresses, am I right? getmonero.org/resources/developer-guides/wallet-rpc.html#sign so using this feature and not linking accounts would mean that you would need to have multiple addresses?

s/addresses/wallets/

*wallets

I think I added this not too long ago.

Vague recollection...

<moneromoooo> "I think I added this not too..." <- github.com/monero-project/monero/bl…python-rpc/framework/wallet.py#L709 github.com/monero-project/monero/bl…ts/functional_tests/sign_message.py I found these tests. It seems like subaddresses are mentioned in there. Seems like its possible but not documented in the user guide.

Although I am still confused what ``` 'account_index': account_index,

'address_index': address_index, ``` is and how it relates to subaddresses. Guess I have to read more about subaddresses haha

A subaddress is a 64 bit number, with 32 interpreted as "account" and 32 as "alias within this account".

And a special case override for 0,0 using the standard address instead, for backward compatibility.

s/alias/address alias/

So default is 0,0. If you run "address new", you'll get 0,1, then 0,2, etc.

Creating a new account in the same wallet will get you 1,0.

moneromoooo: ahh okay. And account is something similar to how people use bank accounts atm? Like having a checking account, a savings account, etc? Its just like a convenience for user, right?

* convenience for the user, right?

I think so.

You can also use it to assign an account per customer, if you're a merchant.

moneromoooo: but wallets dont need to implement this feature necessarily, right? they could just hide the concept under the hood and just use 0,X all the time.

Yes.

I am still a bit confused by the api. In most cases the other side would ask for signing a message that only has the subaddress. So there is a need to go from subaddress -> to account index and address index. Is there an easy way to do this?

Yes, you get that info in the RPC reply when you receive monero.

rbrunner: did you solve your issue?

ErCiccione: I thought netrik182 was moving to that role? Anyway why not put that call to the community at large, I don't see it as being core team role to go out there and find/hire someone for various roles.

<moneromoooo> "Yes, you get that info in the..." <- hm...but what if I never receive monero? I want to use monero addresses to sign into websites by signing these messages. I have an idea but I dont know if its good. I would be glad to hear your take.

in the current monero gui wallet it seems like its not possible to sign with subaddresses. only with with the primary account.

Well, you already know those in that case, no ?

Or if you mean:

selsta: Thanks, yes, thanks to Elijah[m] it compiles now also for MacOS, after avoiding `time_t` in the RPC interface.

Alice makes a website where people can register addresses and later on login by signing, then.. hmm, not sure, let me have a look :)

Ah, verify doesn't take these as input. So I'm not sure what you think you're missing.

<binaryFate> "ErCiccione: I thought netrik182..." <- binaryfate: You are misunderstanding. Netrik182 is taking care of the translations and things on weblate, but doesn't have access to the backend. The backend is managed by core and access to that box is sensitive, especially because the maintainer needs admin permissions, like i have. I assumed core want to choose who has critical access to their infrastructure. If that's not a concern, i'll

just ask pigeons to give access to netrik if he is willing to also take care of that side of things

I also don't think that's a role that makes sense from random people "from the community as large" as you suggest

<moneromoooo> "Ah, verify doesn't take these as..." <- I mean verify takes a public address. I think it would be more straightforward if verify and sign had the same function signature. Its a bit of extra work to turn the address into account + index to do the signing.

<spirobel[m]> "I mean verify takes a public..." <- I'm just curious, what happens when you supply verify a subaddress? Does it fail? I'd try first before asserting that a public address definition does not include subaddress.

Elijah[m]: I was talking about the signing function not the verify

but you are right. I should be investigated if it works with subaddresses. I just assumed it does.

Well signing would be down with the private key I'd assume

s/I/It/

s/down/done/

ErCiccione: ok thanks for clarification. Let's take that to translation channel, probably offtopic here

Btw for anyone wondering, the message can only be signed be linked to the original public address. I tried it myself on the Gui.

spirobel I think what you could try to do is create wallets based on the original seed and using the domain as an offset for the seed.

I would not use the GUI to determine what can and cannot be done, it doesn't update as soon as new stuff gets added.

moneromoooo: not sure how available you are, but is this expected behaviour with ringdb? monero-project/monero-gui #3733

Yes.

That's the whole point of the ringdb.

Whether the tx is sent to the txpool or not is not relevant, unless I'm shown why it is.

If it were to select new fake outs if the tx was not sent to the txpool, it'd open a trivial attack if the dameon is not yours: fail once, but not twice. Then you know which outputs are the real ones.

The ringdb could be disabled with --trusted-daemon though.

Though I'm sure some poeple would add --trusted-daemon with untrusted dameons so...

thanks, posted your reply on the issue

hey parrrtaaayy people

i have some questions about block verification, more so of the function handle_block_to_main_chain in blockchain.cpp

from my digging this function essentially checks all the crap of a given block, like its weight, reward etc and thats all fine and dandy

what im having issue with is, im trying to find where it verifies the merkle root thats in the block hashing blob

now theres this function, get_block_hashing_blob in cryptonote_format_utils.cpp that basically smacks the merkle root + the tx length at the end of the block hashing blob and thats been pretty helpful for me to understand how all of these objects are constructed (get_block_hashing_blob is also called in a variety of functions like get_object_hash, etc)

but ive yet to find, or at least maybe im just stupid and overlooked it, anywhere that verifies the blob block hash info and the merkle root by extension

i was looking for something neat and clean like check_merkle_root_from_block_blob (if only ahahahahah) but it doesnt seem like theres anything like that, which leads me to believe that im misunderstanding how its verified in the first place

anyway, thats whats been in my pot and if anyone can help me with this it would be greatly appreciated!!!

Check get_tx_tree_hash() in src/cryptonote_basic/cryptonote_format_utils.cpp and tree_hash() in src/crypto/tree-hash.c

Merci merci, i will look at that now

sech1: Isnt that function just used essentially once in get_block_hashing_blob to calculate the merkle root?

If im understanding this correctly, does that mean that get_block_hashing_blob is the function used to verify the merkle root on a given incoming block?

I think I may be misunderstanding the syncing process, when a node recieves a block does it also get the completed block hash blob or is that all done client side when verifying the incoming block?

If the latter, that would make much more sense as im trying to understand how all this works step by step

Is this normal? It seems like wallet rpc starts all over after it's done syncing.

It has been going on for hours now

thats odd...does it have the latest height of the chain or does it just hang on there? are the other rpc functions of the wallet accessible?

json rpc is completely unreachable

thats certainly strange, your using the latest release right?

I am not sure if that's the latest height of chain

personally i havent used the rpc wallet in a while or looked at its code to help you out too much

Siren[m]: xmrchain.net

hitomifujiko[m]: its version is `Monero 'Oxygen Orion' (v0.17.2.3-unknown)`

Ya it seems like your at the highest height...have you tried re-syncing and completely deleting your blockchain folder?

Siren[m]: thats also the latest, hmmmm

if you havent already i would try resyncing, sometimes things just get fucky wucky and a restart can help

hitomifujiko[m]: where is the foler?

s/foler/folder/

Im guessing your on a linux system, iirc its usually /home/.bitmonero

or /home/.monero

ah that

its a hidden folder its either in home or the directory you started wallet-rpc/monerod (usually home folder tho)

On windows its somewhere in %appdata% iirc if anyone needs that

I don't think it is persistent for me in the first place as it's running within docker without a volume or anything

ah i see, ive never used docker personally so i cant speak to that

but if its not persistent and you resync each time you reset the instance or whatever, does it still do this?

unfortunately it seems like it does

hmmm well like i said i dont have a whole lot of experience with wallet-rpc and its code, but it would be good to set your wallet-rpc instance to the highest log level and grab a log file of the whole process, im sure someone here would be interested in taking a look at it since that would be the smoking gun

if you do send it here ill take a look at it but im kinda dumb as you can see from my merkle root woes earlier ahahaha

when i get some time, i might investigate that Pulling blocks, start_height line you have there, im sure theres something relevant in the codebase around there to your issue

Here are the logs

<hitomifujiko[m]> "if you do send it here ill..." <- Now it's going to be pretty funny if I missed something very obvious in the logs after you've said this

It was running perfectly fine weeks ago : (

Siren[m]: some docker misconfiguration maybe? if it can't save the wallet cache it would probably restart to sync the next time you open the wallet

Yes, but it has been going on for a few days. Can you confirm that the log output in the image is normal?

* few days. After my restart earlier today, it's still the same. Can you

* or anything (only the wallet file and its keys are in a volume).

Is there such thing as a bad wallet file? I tried opening the same wallet using monero-wallet-gui and got 100% load. I had to kill the processes.

it should not happen but possible

but I didn't hear about this issue before