01:58:46 <br-m> <jpk68:matrix.org> vtnerd: Wouldn't deterministic encoding be necessary for peer authentication (if that's implemented in addition to encryption)?
08:40:59 <br-m> <rhl39:matrix.org> i need Remote job, i have time, and i accept XMR as salary
16:07:27 <br-m> <vtnerd> jpk68: I don't see why? You just validate the signature, then unpack the blob and inspect the c++ data. Json web signatures also don't require determinism afaik > <@jpk68:matrix.org> vtnerd: Wouldn't deterministic encoding be necessary for peer authentication (if that's implemented in addition to encryption)?
16:08:55 <br-m> <vtnerd> Determinism is more critical when you pass around the hash as some important object, whereas digital signatures use the hash just for verification and is otherwise less important 
16:10:05 <br-m> <jpk68:matrix.org> Yeah, I was thinking about if the signature was over serialized bytes instead of just the data
16:11:28 <br-m> <jpk68:matrix.org> TBH it kind of seems weird having multiple 'correct' encodings of the same object, but I get your point
16:15:21 <br-m> <vtnerd> Fwiw I had to update tests and realized I already fixed the serialization order issue with the output (via brace initialization)
16:15:57 <br-m> <vtnerd> Because I hard coded expected json+msgpack data to ensure it was written+read
16:17:30 <br-m> <vtnerd> The only remaining problem is integer vs string keys for objects/maps. The output system can support either easily, but it's not so simple for deterministic output as adding a number will have different sort order than it's string name
16:18:22 <br-m> <vtnerd> We'd probably just pick integer keys for deterministic order, and I can 100% ensure at compile time that the order is validated by the base code
16:18:55 <br-m> <jpk68:matrix.org> This adheres to the MessagePack spec, yes? It would be a pain if all the libraries that exist for that format couldn't be used
16:19:51 <br-m> <vtnerd> Integer keys? Yes they are part of the spec, and cbor copied this. They're probably more common in cbor but I could be wrong
16:20:40 <br-m> <jpk68:matrix.org> Yeah, just making sure, for example, that I can use any old MessagePack library (i.e. in Python) for RPC
16:20:47 <br-m> <vtnerd> Not sure of the perf difference, but there is a decent size difference obviously 
16:22:23 <br-m> <vtnerd> Yes and cddl (for cbor) shines here as you can specify integer in schema. Doesn't look like you can list both as an either or thing though 
17:41:35 <UkoeHB> Is `transfer_details` serialized anywhere other than the wallet cache? It's currently unversioned here https://github.com/monero-project/monero/blob/56b176c6022faeb9db13fb6fb33bc23c55c4a81e/src/wallet/wallet2_basic/wallet2_serialization.h#L60 (the boost ser/de is versioned) and I'm trying to find a workaround to add versioning (since multisig needs to modify it).
17:54:46 <sech1> UkoeHB temporary remove the serialization definitions for this struct, and see which places in the code fail to compile?
18:23:50 <br-m> <vtnerd> make could skip some cases due to earlier error
19:28:29 <br-m> <ofrnxmr> @jpk68:matrix.org  https://github.com/monero-project/monero/pull/10670#issuecomment-4557939113
19:29:17 <br-m> <jpk68:matrix.org> See linked issue
19:29:35 <br-m> <jpk68:matrix.org> I can understand why some might not find it useful, but I personally disagree
19:29:52 <br-m> <jpk68:matrix.org> I have seen this requested on multiple occasions
19:31:18 <br-m> <jpk68:matrix.org> It also works in the config file, so you don't have to type the full command every time
19:31:28 <br-m> <ofrnxmr> i see. So use case is to set it in config file
19:31:37 <br-m> <jpk68:matrix.org> Not the only use case, but sure
19:33:49 <br-m> <ofrnxmr> Well, setting it on command line doesnt really make sense ? What am i missing
19:34:21 <br-m> <ofrnxmr> On command line, youre just typing the same info anyway, just with an extra flag
19:34:39 <selsta> since it exists for wallet-rpc it should be ok to also add it to wallet-cli, even though i agree outside config file use cases are limited
19:38:52 <br-m> <ofrnxmr> Seems sane to add, but still seems kinda strange / niche, considering that config files arent auto-detected, so the linked issue use case lf just sending ./monero-wallet-cli --wallet-file 123 wont work unless you also specify --config-file. There could be more config options than just wallet-dir (which is why i say its sane)
19:39:14 <br-m> <ofrnxmr> But it doesnt make the requested use case realistic
19:39:43 <br-m> <jpk68:matrix.org> To be clear, I added this partially because of the open issue, and also because I myself wanted the option to exist. My particular use case for this (though probably somewhat niche) would be the following: I store most wallet files in one folder (the one created by the GUI), and want this to be the default path, which is speci [... too long, see https://mrelay.p2pool.observer/e/ofnJo4cLZkFrYlNR ]
19:39:51 <br-m> <jpk68:matrix.org> Maybe I'm just weird but it seems ergonomic to me
19:41:52 <br-m> <jpk68:matrix.org> Also, the new option works with several other flags besides --generate-new-wallet and --wallet-file. For example, if you're multitasking and want to generate a new wallet from a device (or just a regular one) while in some random folder, you can specify where to save it, rather than in the current directory
19:42:12 <br-m> <jpk68:matrix.org> </yapping>
19:42:36 <br-m> <ofrnxmr> You can specify where tk save it by typing the path to save it (old) or the path to the config (new) :P
19:42:44 <br-m> <ofrnxmr> Either way, youre typing a path
19:43:09 <br-m> <jpk68:matrix.org> So basically, my argument is "I just like it"
19:43:30 <br-m> <ofrnxmr> Dont worry, im not debating that there are some cases where it may be helpful (like having a config file with multiple things in it), just not that it, in isolation, is helpful
19:53:50 <br-m> <jpk68:matrix.org> tobtoht: Related to 10672, is it not bad that the same file generally uses #ifdef __GLIBC__ to detect Linux/UNIX?
19:53:53 <br-m> <jpk68:matrix.org> https://github.com/monero-project/monero/blob/master/src/common/util.cpp#L39
19:54:12 <tobtoht> yea
19:54:43 <br-m> <jpk68:matrix.org> How does this not have issues with musl?
19:54:53 <br-m> <jpk68:matrix.org> I was thinking of this because of the StageX build
19:55:01 <tobtoht> i was thinking the same, not sure yet
19:55:44 <br-m> <jpk68:matrix.org> I can make a PR for this if it's fine with you
19:58:45 <tobtoht> ofc
20:00:48 <br-m> <jpk68:matrix.org> #if defined(__linux__) || defined(__unix__) || defined(__APPLE__) should be good, right
20:01:13 <br-m> <jpk68:matrix.org> Wait, nevermind, just Linux and UNIX?
20:02:57 <tobtoht> does hdd detection even work?
20:03:20 <br-m> <jpk68:matrix.org> I have no idea
20:03:48 <br-m> <ofrnxmr:xmr.mx> It detects vms as hdd, so i assume so
20:04:02 <br-m> <ofrnxmr:xmr.mx> Or vps's, or both
20:04:46 <br-m> <ofrnxmr:xmr.mx> Been a long time since i tried to sync on an hdd, but it does throw that warning on my vps
20:05:59 <br-m> <jpk68:matrix.org> Does that not decrease sync speed, if it's actually using an SSD?
20:06:08 <br-m> <jpk68:matrix.org> Or general read/write speed, rather
20:07:36 <tobtoht> it only warns
20:08:37 <plowsof> yes always see the warning on vps' although they claim to be bare metal lol
20:08:43 <br-m> <jpk68:matrix.org> It does seem a bit hacked together anyways (and has questionable utility)
20:08:58 <br-m> <jpk68:matrix.org> Though perhaps that's better suited for a separate PR