01:47:22 <yyx> are there any reasonably sane estimates how much of the Monero hashrate is centralized/commercial/industrial vs. residential?
01:47:50 <yyx> or at least some upper/lower bounds?
01:49:30 <yyx> https://minexmr.com/pools.html
01:49:30 <yyx> stats like this establish some bounds but again we don't know who's in these pools 
01:49:30 <yyx> I'm sure someone has done thinking on this? 
02:05:52 <Rucknium[m]> y: This belongs more in #monero-research-lounge:monero.social 
06:08:27 <rbrunner> 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
06:08:34 <rbrunner> I will switch to that as well
06:09:23 <Elijah[m]> It took me hours to find that btw...
06:09:30 <Elijah[m]> s/It took me hours to find that btw.../It took me hours to figure it that out btw.../
06:09:54 <rbrunner> Hmmm. I hope you were rewarded by learning some things? :)
06:53:26 <rbrunner> 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.
09:03:16 <Halver[m]> <Rucknium[m]> "Those big guys should write a..." <- We see this pattern quite regularly.
09:03:16 <Halver[m]> There are some features which have truly **nothing** to do at the protocol level and can and should be implemented at the application level.
09:03:16 <Halver[m]> But yet peoples from the application level often ask, sometimes successfully, to have the feature done at the protocol level.
09:03:16 <Halver[m]> 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.
10:42:05 <ErCiccione> 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).
10:42:05 <ErCiccione> 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.
10:42:13 <ErCiccione> luigi1111 binaryfate fluffypony ^
11:04:23 <spirobel[m]> There is currently no way to sign something against subaddresses, am I right? https://www.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?
11:04:41 <spirobel[m]> s/addresses/wallets/
11:04:45 <spirobel[m]> *wallets
11:19:26 <moneromoooo> I think I added this not too long ago.
11:19:56 <moneromoooo> Vague recollection...
12:23:55 <spirobel[m]> <moneromoooo> "I think I added this not too..." <- https://github.com/monero-project/monero/blob/dcba757dd283a3396120f0df90fe746e3ec02292/utils/python-rpc/framework/wallet.py#L709 https://github.com/monero-project/monero/blob/dcba757dd283a3396120f0df90fe746e3ec02292/tests/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.
12:25:55 <spirobel[m]> Although I am still confused what ```               'account_index': account_index,
12:25:55 <spirobel[m]>                 'address_index': address_index, ``` is and how it relates to subaddresses. Guess I have to read more about subaddresses haha
12:26:52 <moneromoooo> A subaddress is a 64 bit number, with 32 interpreted as "account" and 32 as "alias within this account".
12:27:20 <moneromoooo> And a special case override for 0,0 using the standard address instead, for backward compatibility.
12:27:36 <moneromoooo> s/alias/address alias/
12:28:06 <moneromoooo> So default is 0,0. If you run "address new", you'll get 0,1, then 0,2, etc.
12:28:17 <moneromoooo> Creating a new account in the same wallet will get you 1,0.
12:30:16 <spirobel[m]> 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?
12:30:57 <spirobel[m]> * convenience for the user, right?
12:33:17 <moneromoooo> I think so.
12:33:51 <moneromoooo> You can also use it to assign an account per customer, if you're a merchant.
12:35:01 <spirobel[m]> 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.
12:35:15 <moneromoooo> Yes.
12:41:09 <spirobel[m]> 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?
12:48:46 <moneromoooo> Yes, you get that info in the RPC reply when you receive monero.
12:51:05 <selsta> rbrunner: did you solve your issue?
12:55:19 <binaryFate> 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.
12:56:01 <spirobel[m]> <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. 
12:56:12 * spirobel[m] uploaded an image: (357KiB) < https://libera.ems.host/_matrix/media/r0/download/matrix.org/sRGilzHhlpcmOwDJWmeCRZbI/image.png >
12:56:42 <spirobel[m]> in the current monero gui wallet it seems like its not possible to sign with subaddresses. only with with the primary account.
13:06:43 <moneromoooo> Well, you already know those in that case, no ?
13:06:58 <moneromoooo> Or if you mean:
13:07:28 <rbrunner> selsta: Thanks, yes, thanks to Elijah[m] it compiles now also for MacOS, after avoiding `time_t` in the RPC interface.
13:08:04 <moneromoooo> Alice makes a website where people can register addresses and later on login by signing, then.. hmm, not sure, let me have a look :)
13:08:39 <moneromoooo> Ah, verify doesn't take these as input. So I'm not sure what you think you're missing.
13:20:17 <ErCiccione> <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
13:20:17 <ErCiccione> just ask pigeons to give access to netrik if he is willing to also take care of that side of things
13:21:08 <ErCiccione> I also don't think that's a role that makes sense from random people "from the community as large" as you suggest
13:26:31 <spirobel[m]> <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. 
13:47:48 <Elijah[m]> <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. 
13:50:54 <spirobel[m]> Elijah[m]: I was talking about the signing function not the verify
13:51:36 <spirobel[m]> but you are right. I should be investigated if it works with subaddresses. I just assumed it does.
13:52:01 <Elijah[m]> Well signing would be down with the private key I'd assume 
13:52:02 <spirobel[m]> s/I/It/
13:52:11 <Elijah[m]> s/down/done/
13:53:43 <binaryFate> ErCiccione: ok thanks for clarification. Let's take that to translation channel, probably offtopic here
17:59:07 <Elijah[m]> Btw for anyone wondering, the message can only be signed be linked to the original public address. I tried it myself on the Gui. 
17:59:07 <Elijah[m]> 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. 
18:00:46 <moneromoooo> 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.
18:53:32 <selsta> moneromoooo: not sure how available you are, but is this expected behaviour with ringdb? https://github.com/monero-project/monero-gui/issues/3733
19:20:48 <moneromoooo> Yes.
19:21:02 <moneromoooo> That's the whole point of the ringdb.
19:21:31 <moneromoooo> Whether the tx is sent to the txpool or not is not relevant, unless I'm shown why it is.
19:22:30 <moneromoooo> 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.
19:22:52 <moneromoooo> The ringdb could be disabled with --trusted-daemon though.
19:23:13 <moneromoooo> Though I'm sure some poeple would add --trusted-daemon with untrusted dameons so...
19:55:31 <selsta> thanks, posted your reply on the issue
22:25:47 <hitomifujiko[m]> hey parrrtaaayy people
22:25:47 <hitomifujiko[m]> i have some questions about block verification, more so of the function handle_block_to_main_chain in blockchain.cpp
22:25:47 <hitomifujiko[m]> 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
22:25:47 <hitomifujiko[m]> what im having issue with is, im trying to find where it verifies the merkle root thats in the block hashing blob
22:26:48 <hitomifujiko[m]> 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)
22:28:11 <hitomifujiko[m]> 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
22:28:11 <hitomifujiko[m]> 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
22:28:29 <hitomifujiko[m]> anyway, thats whats been in my pot and if anyone can help me with this it would be greatly appreciated!!!
22:32:15 <sech1> Check get_tx_tree_hash() in src/cryptonote_basic/cryptonote_format_utils.cpp and tree_hash() in src/crypto/tree-hash.c
22:33:16 <hitomifujiko[m]> Merci merci, i will look at that now
22:36:39 <hitomifujiko[m]> sech1: Isnt that function just used essentially once in get_block_hashing_blob to calculate the merkle root?
22:36:39 <hitomifujiko[m]> 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?
22:37:37 <hitomifujiko[m]> 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?
22:37:57 <hitomifujiko[m]> If the latter, that would make much more sense as im trying to understand how all this works step by step
22:45:24 * Siren[m] uploaded an image: (61KiB) < https://libera.ems.host/_matrix/media/r0/download/kernal.eu/tQbdZmLVkdJNKhuStfoQceHz/image.png >
22:46:22 <Siren[m]> Is this normal? It seems like wallet rpc starts all over after it's done syncing.
22:46:41 <Siren[m]> It has been going on for hours now
22:47:25 <hitomifujiko[m]> 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?
22:48:11 <Siren[m]> json rpc is completely unreachable
22:48:29 <hitomifujiko[m]> thats certainly strange, your using the latest release right?
22:48:40 <Siren[m]> I am not sure if that's the latest height of chain
22:49:07 <hitomifujiko[m]> personally i havent used the rpc wallet in a while or looked at its code to help you out too much
22:49:11 <hitomifujiko[m]> Siren[m]: https://xmrchain.net/
22:49:47 <Siren[m]> hitomifujiko[m]: its version is `Monero 'Oxygen Orion' (v0.17.2.3-unknown)`
22:50:33 <hitomifujiko[m]> Ya it seems like your at the highest height...have you tried re-syncing and completely deleting your blockchain folder?
22:50:41 <hitomifujiko[m]> Siren[m]: thats also the latest, hmmmm
22:51:05 <hitomifujiko[m]> if you havent already i would try resyncing, sometimes things just get fucky wucky and a restart can help
22:53:44 <Siren[m]> hitomifujiko[m]: where is the foler?
22:53:47 <Siren[m]> s/foler/folder/
22:54:16 <hitomifujiko[m]> Im guessing your on a linux system, iirc its usually /home/.bitmonero
22:54:24 <hitomifujiko[m]> or /home/.monero
22:54:25 <Siren[m]> ah that
22:54:46 <hitomifujiko[m]> its a hidden folder its either in home or the directory you started wallet-rpc/monerod (usually home folder tho)
22:55:04 <hitomifujiko[m]> On windows its somewhere in %appdata% iirc if anyone needs that
22:56:13 <Siren[m]> I don't think it is persistent for me in the first place as it's running within docker without a volume or anything
22:56:53 <hitomifujiko[m]> ah i see, ive never used docker personally so i cant speak to that
22:57:11 <hitomifujiko[m]> but if its not persistent and you resync each time you reset the instance or whatever, does it still do this?
22:57:23 <Siren[m]> unfortunately it seems like it does
22:58:19 <hitomifujiko[m]> 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
22:58:34 <hitomifujiko[m]> 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
23:00:00 <hitomifujiko[m]> 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
23:10:49 * Siren[m] posted a file: (1322KiB) < https://libera.ems.host/_matrix/media/r0/download/kernal.eu/XIeTlLuwYmUWJWQKKZiFavjJ/wallet-rpc-logs.tar.gz >
23:10:59 <Siren[m]> Here are the logs
23:12:29 <Siren[m]> <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
23:17:48 <Siren[m]> It was running perfectly fine weeks ago :     (
23:23:24 <selsta> 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
23:26:10 <Siren[m]> Yes, but it has been going on for a few days. Can you confirm that the log output in the image is normal?
23:29:39 <Siren[m]> * few days. After my restart earlier today, it's still the same. Can you
23:36:03 <Siren[m]> * or anything (only the wallet file and its keys are in a volume).
23:42:11 <Siren[m]> 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.
23:49:20 <selsta> it should not happen but possible
23:49:32 <selsta> but I didn't hear about this issue before