<jpk68:matrix.org> vtnerd: Wouldn't deterministic encoding be necessary for peer authentication (if that's implemented in addition to encryption)?

<rhl39:matrix.org> i need Remote job, i have time, and i accept XMR as salary

<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)?

<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

<jpk68:matrix.org> Yeah, I was thinking about if the signature was over serialized bytes instead of just the data

<jpk68:matrix.org> TBH it kind of seems weird having multiple 'correct' encodings of the same object, but I get your point

<vtnerd> Fwiw I had to update tests and realized I already fixed the serialization order issue with the output (via brace initialization)

<vtnerd> Because I hard coded expected json+msgpack data to ensure it was written+read

<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

<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

<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

<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

<jpk68:matrix.org> Yeah, just making sure, for example, that I can use any old MessagePack library (i.e. in Python) for RPC

<vtnerd> Not sure of the perf difference, but there is a decent size difference obviously

<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

Is `transfer_details` serialized anywhere other than the wallet cache? It's currently unversioned here github.com/monero-project/monero/bl…2_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).

UkoeHB temporary remove the serialization definitions for this struct, and see which places in the code fail to compile?

<vtnerd> make could skip some cases due to earlier error

<ofrnxmr> @jpk68:matrix.org monero-project/monero #10670#issuecomment-4557939113

<jpk68:matrix.org> See linked issue

<jpk68:matrix.org> I can understand why some might not find it useful, but I personally disagree

<jpk68:matrix.org> I have seen this requested on multiple occasions

<jpk68:matrix.org> It also works in the config file, so you don't have to type the full command every time

<ofrnxmr> i see. So use case is to set it in config file

<jpk68:matrix.org> Not the only use case, but sure

<ofrnxmr> Well, setting it on command line doesnt really make sense ? What am i missing

<ofrnxmr> On command line, youre just typing the same info anyway, just with an extra flag

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

<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)

<ofrnxmr> But it doesnt make the requested use case realistic

<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 mrelay.p2pool.observer/e/ofnJo4cLZkFrYlNR ]

<jpk68:matrix.org> Maybe I'm just weird but it seems ergonomic to me

<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

<jpk68:matrix.org> </yapping>

<ofrnxmr> You can specify where tk save it by typing the path to save it (old) or the path to the config (new) :P

<ofrnxmr> Either way, youre typing a path

<jpk68:matrix.org> So basically, my argument is "I just like it"

<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

<jpk68:matrix.org> tobtoht: Related to 10672, is it not bad that the same file generally uses #ifdef __GLIBC__ to detect Linux/UNIX?

<jpk68:matrix.org> github.com/monero-project/monero/blob/master/src/common/util.cpp#L39

yea

<jpk68:matrix.org> How does this not have issues with musl?

<jpk68:matrix.org> I was thinking of this because of the StageX build

i was thinking the same, not sure yet

<jpk68:matrix.org> I can make a PR for this if it's fine with you

ofc

<jpk68:matrix.org> #if defined(__linux__) || defined(__unix__) || defined(__APPLE__) should be good, right

<jpk68:matrix.org> Wait, nevermind, just Linux and UNIX?

does hdd detection even work?

<jpk68:matrix.org> I have no idea

<ofrnxmr:xmr.mx> It detects vms as hdd, so i assume so

<ofrnxmr:xmr.mx> Or vps's, or both

<ofrnxmr:xmr.mx> Been a long time since i tried to sync on an hdd, but it does throw that warning on my vps

<jpk68:matrix.org> Does that not decrease sync speed, if it's actually using an SSD?

<jpk68:matrix.org> Or general read/write speed, rather

it only warns

yes always see the warning on vps' although they claim to be bare metal lol

<jpk68:matrix.org> It does seem a bit hacked together anyways (and has questionable utility)

<jpk68:matrix.org> Though perhaps that's better suited for a separate PR