00:18:26 <ndorf> selsta says "ideally everyone would use a subaddress," i think most of us agree. why not simply have newly created wallets show the first subaddress by default, instead of the primary?
00:19:00 <ndorf> the primary could be hidden behind a command/menu item for the thankfully already rare case when subaddresses aren't accepted
00:20:13 <moneromooo> IIRC you can't mine to a subaddress (not an inherent limitation, but IIRC the code changes to allow this were hairy).
00:20:35 <selsta> we are trying something like this for the GUI (show subaddress by default), but not merged yet and is larger change
00:20:52 <ndorf> isn't that ok though? if someone is setting up a miner they can be asked to take 1 step to see the primary address reasonably, no?
00:21:09 <moneromooo> Are you showing the 0,0 subaddress ? It's not accessible from monero-wallet-cli.
00:21:29 <ndorf> i.e. "click Menu | Item to see your 'mining address'"
00:21:46 <ndorf> i thought 0,0 was special cased to refer to the primary
00:21:59 <ndorf> if true, i mean showing 0,1 by default instead of 0,0/primary
00:24:07 <ndorf> actually that requirement applies only to daemon mining, unless i'm missing something. so the wallet could even handle it automatically when you issue start_mining from therein.
00:24:46 <ndorf> just to be extra clear, i'm proposing a UI-only change, nothing in the protocol
00:26:55 <ndorf> s/could/already does, so no change needed there/
00:27:58 <selsta> see https://github.com/monero-project/monero-gui/pull/2936
00:28:42 <ndorf> nice
00:29:06 <ndorf> is there any reason this shouldn't be done for cli also?
00:29:23 <ndorf> newly created wallets only, of course
00:29:39 <moneromooo> There might be reasons in the issue and/or PR adding subaddresses.
00:30:17 <moneromooo> If they boil down to "nobody supports subaddresses yet", then it could be done.
00:30:49 <selsta> at least something like "get_fresh_address" command
00:30:52 <ndorf> cool. i'll take a look and open a [Proposal] before doing anything. honestly it is so "obvious" i assumed i was missing something, that's why i asked here instead of just doing that
00:31:15 <ndorf> what does fresh mean there?
00:32:05 <selsta> forget what I wrote :) I think that exists already
00:32:09 <selsta> just a new subaddress
00:38:43 <dsc_> Maybe show a random subaddr by default, from a pool of size determined by the lookahead
00:39:08 <dsc_> nvm, bad idea
00:40:29 <jtgrassie> it would seem this idea of coinbase only rings is just kicking the can down the road so to speak.
01:02:16 <sarang> jtgrassie: how so
01:07:32 <ndorf> same question, coinbase txes already stand out so using a different address format in those txes doesn't seem to matter?
09:02:57 <nssy> Looks like this command doesn't work anymore:
09:02:59 <nssy> set inactivity-lock-timeout = 0
09:03:13 <nssy> Am using monero-wallet-cli v0.16.0.0-release
09:03:21 <nssy> Error: Invalid number of seconds
09:03:48 <nssy> even positive numbers also get the same error
09:05:04 <asymptotically> try without the =
09:17:51 <nssy> That worked. Thaks
12:01:31 <moneromooo> rbrunner: if I made some serialization changes to message_store, would you be able to check it didn't break anything ?
15:52:48 <rbrunner> moneromooo: No problem for me to check if you make serialization changes in the message store. I guess "breaking" would mean that it can't read anymore an *existing* store, right?
15:56:29 <moneromooo> rbrunner: yes. 6690.
15:57:05 <moneromooo> (if load-deprecated-formats is set, otherwise it should not read it)
15:57:24 <rbrunner> Alright. Probably tomorrow.
15:59:23 <moneromooo> No rush. Thanks.
16:17:07 <rbrunner> Things deprecate fast nowadays it seems :)
16:24:42 <rbrunner> I remember now that story about the serialization. I started with Monero serialization but then I had the absolutely strange effect that the optimizer completely optimized my code away and replaced it with a 1-x64-instruction endless loop
16:25:04 <rbrunner> It was quite bizarre.
16:25:22 <rbrunner> I then switched to boost serialization.
16:25:48 <rbrunner> I think it did not only in release builds. Debug builds were ok.
16:26:16 <rbrunner> *did it only in
16:26:25 <rbrunner> Will check that, for sure.
16:30:08 <moneromooo> rbrunner: the messages exchanged between users are short lived, right ?
16:30:45 <moneromooo> (bitmessage messages)
16:54:38 <rbrunner> It depends. The message contents are stored, for collecting them (waiting for *all* signers to send their data), for resending them if somebody reports to have received nothing etc.
16:54:58 <rbrunner> The MMS does not delete any message on its own, all deleting from the message store is active.
16:56:16 <rbrunner> But if things move forward in a good way you are right that usually they become expendable over a short time.
16:57:29 <rbrunner> But if you really mean the Bitmessage messages themselves: As soon as the MMS sees them and copies them over into the store, they are not interesting anymore.
16:58:14 <rbrunner> I think the MMS even deletes them, so they don't stack up, and for security reasons.
17:22:54 <selsta> does anyone know what this is used for? https://github.com/monero-project/monero/blob/master/contrib/depends/toolchain.cmake.in#L58
17:27:07 <hyc> it's used in gitian builds at least
17:27:13 <selsta> seen it twice now in the codebase but https://cmake.org/cmake/help/latest/module/FindOpenSSL.html does not have a `OpenSSL_DIR` so I was thinking it’s a typo
17:27:25 <hyc> ah
17:28:13 <selsta> same here: https://github.com/monero-project/monero/blob/master/CMakeLists.txt#L429
17:32:05 <hyc> ask fluffy? see commit 058eed369b
17:32:17 <selsta> ok have an idea what it could be used for, but kinda looks like a hack
17:32:23 <hyc> came from unbound
17:33:01 <selsta> setting OpenSSL_DIR in toolchain.cmake will have the effect that the system does not look for homebrew openssl
17:33:40 <selsta> but the value of it is not used anywhere
17:36:36 <hyc> or it came from here 2d43ae806359c89818c0519d81a65ded768746d8
17:37:36 <selsta> yep, the patch is ok but I think it should be OPENSSL_ROOT_DIR instead of OpenSSL_Dir, OpenSSL_Dir is probably something unbound specific
17:38:10 <selsta> because then you can also manually specify -DOPENSSL_ROOT_DIR and use non standard locations
17:39:49 <hyc> well, as I recall, we authored the unbound CMakeLists.txt too
17:39:59 <hyc> and it doesn't appear anywhere else in the unbound tree either
17:41:49 <hyc> so perhaps it was a typo for OPENSSL_ROOT_DIR
17:43:37 <hyc> doesn't say much here either https://github.com/monero-project/monero/pull/578
17:45:23 <selsta> this should work, will test it https://paste.debian.net/hidden/905ae4ec/
17:46:29 <selsta> or better this: https://paste.debian.net/hidden/5d199d94/
17:48:56 <hyc> good luck....
17:49:52 <hyc> would still ask fluffypony if he remembers the actual problem being fixed
17:50:51 <hyc> if there's an associated issue# with more description
17:53:34 <fluffypony> might have been unbound specific
17:53:49 <fluffypony> I mean, it's 30 Dec 2015 and I'm probably a whisky deep writing that PR
17:53:57 <hyc> lol
17:54:47 <fluffypony> is it unbound that doesn't have CMake or upnp?
17:55:05 <fluffypony> coz one of the two we had to make our own CMake for it, I think it used autotools
17:55:12 <hyc> unbound uses autotools
17:55:39 <fluffypony> yeah so every time I updated it I had to fight with CMake for a day to get it to work
17:57:14 <fluffypony> that OpenSSL homebrew thing is definitely code from StackExchange or somewhere
17:57:39 <selsta> the homebrew thing is ok
17:57:42 <fluffypony> I'd be very surprised if I actually reasoned through that
17:58:35 <hyc> the homebrew bit sets OPENSSL_ROOT_DIR, so it shortcuts the following find_package(OpenSSL REQUIRED)
17:59:03 <hyc> but it implies that whoever was building on OSX set OpenSSL_DIR on their cmake invocation, manually
17:59:12 <selsta> it shortcuts it? can you explain?
17:59:32 <selsta> if you don’t set OPENSSL_ROOT_DIR on macOS to the homebrew path, it will use system openssl and the linker does not allow that
18:00:43 <selsta> so if you would want a custom OPENSSL_ROOT_DIR you would have to do -DOPENSSL_ROOT_DIR="..." -DOpenSSL_Dir right now
18:01:31 <moneromooo> Oh, fighting cmake... I want to punch it in the face almost every time I have to deal with it...
18:02:04 <dsc_> seconded
18:02:14 <fluffypony> could be worse
18:02:16 <fluffypony> could be autotools
18:02:45 <moneromooo> I dunno. Last time I really used those was long enough I long for them when I use cmake. Not libtool though. Fuck libtool.
18:42:54 <selsta> hyc: yep, works like expected now, the old code also worked by accident because `CMAKE_FIND_ROOT_PATH` was set.
18:45:51 <hyc> cool
18:46:27 <hyc> since I've never built OSX binaries besides with gitian, I've never run into whatever the original problem was
18:47:05 <hyc> speaking of which, now that Apple has announced they're switching to all-ARM architectures, we'll need to adjust for that soon. ~1 year I suppose
19:05:10 <sarang> Looks like they're shipping an emulator for x86, but they highlighted that it's transitional only
19:05:58 <sarang> and don't forget hyc, it's not ARM, it's "Apple Silicon (tm)"
19:06:22 <sarang> You're legally required to write it in a pleasant font
19:06:55 <selsta> sarang: it’s more like a translator, they translate it during install time
19:08:27 <hyc> binary recompiler
19:09:01 <selsta> apparently it also works with JIT, would be curious if monerod /randomx works
19:09:15 <selsta> and the performance difference between native
19:09:24 <sarang> interesting
19:13:29 <moneromooo> I really like how "silicon" readily translates to "silly con".
19:13:45 <hyc> sillycon valley, yep
19:13:45 <moneromooo> But then I've always loved bad puns.
19:14:05 <moneromooo> Well, there you go. I knew I couldn't be the first to like bad puns.
19:16:29 <sarang> It'll be interesting to see what power efficiency they might get out of Apple Silicon (tm) devices
19:45:34 <fluffypony> you're required to use the ™ symbol and not (tm) when talking about Apple Compute™
19:45:52 <fluffypony> much like this: https://www.theverge.com/tldr/2020/6/25/21302831/goldman-sachs-font-sans-criticize-disparage-license
19:47:25 * sarang is clearly a rebel
19:50:10 <dsc_> (tm)™
19:51:10 <sarang> So it'll be necessary to maintain the current Mac™ build in addition to a new AppleⓇ™ Silicon©℠™ build?
19:51:48 <sarang> I may be missing a symbol or two
19:51:56 <sarang> apologies to the overlords
19:53:01 <sarang> Or just do the current build and rely on the translatorrecompilerthingy tool
19:54:36 <fluffypony> that's a good question
19:54:50 <fluffypony> I think we'll likely have a native Mac ARM build in short order since we're already ARM compatible
19:55:57 <fluffypony> and pretty much all the underlying FOSS libs / tools we rely on are available for Apple's iOS silicon (eg. on jailbroken phones etc,)
19:56:00 <sarang> You mean AppleⓇ™ Silicon©℠™ build
19:56:06 <fluffypony> sorry yes
19:56:10 <fluffypony> the latter
19:56:12 <sarang> "It's not ARM... but it's not not ARM"
19:56:14 <elghosto> hey the Monero GUI says there's a list of known spend outputs on the Monero website but I can't find it. Can anybody point me to it?
19:56:28 <sarang> elghosto: are you spending old pre-CT funds?
19:56:36 <sarang> If not, you almost certainly don't need the spent-output list
19:56:42 <elghosto> I'm doing an EAE attack
19:56:55 <sarang> maybe don't do that
19:57:34 <sarang> There is no "official" spent-output list
19:57:47 <sarang> sgp_ built one using the built-in tools (you could do the same)
19:57:59 <sarang> Note that any spent-output list you obtain could have been generated adversarially
19:58:10 <sarang> In theory it's possible to verify, but the tool doesn't currently do this
19:58:24 <sarang> post-CT outputs are almost entirely unaffected
20:01:35 <elghosto> ugh sorry i got disconnected right after I joked about EAE attack so couldn't see responses
20:02:09 <sarang> 15:57 <sarang> sgp_ built one using the built-in tools (you could do the same)
20:02:09 <sarang> 15:57 <sarang> Note that any spent-output list you obtain could have been generated adversarially
20:02:09 <sarang> 15:58 <sarang> In theory it's possible to verify, but the tool doesn't currently do this
20:02:09 <sarang> 15:58 <sarang> post-CT outputs are almost entirely unaffected
20:02:22 <elghosto> thanks a lot
20:02:38 <sarang> I can look up the link to sgp_'s list if you like
20:02:46 <sarang> but again, it assumes some level of trust in the list
20:02:52 <elghosto> does it include post-ct outputs?
20:03:01 <sarang> Yes, but there are negligible numbers of them
20:03:05 <sarang> And all from chain splits
20:03:12 <sarang> None from on-chain chain reaction analysis
20:03:26 <sarang> Er, there's one small set from a preprint analysis
20:03:29 <sarang> like 5 outputs
20:14:33 <sgp_> https://moneroblackball.com
20:14:45 <sarang> thanks sgp_
20:14:59 <sgp_> I got a tiny amount from chain splits
20:15:13 <sarang> Yeah I recall it was quite small
20:15:25 <sarang> and very centered around particular times
20:15:27 <sgp_> those also somewhat account for public pool data around that time
20:16:36 <sgp_> download links seem broken. try https://github.com/monero-blackball/monero-blackball-site
20:17:56 <sgp_> hmm, I don't actually know what I did with that site anymore lol
20:20:20 <sarang> Well, the list wasn't verified once imported
20:20:28 <sarang> So you have to trust whomever generated it
20:20:33 <sarang> It could be verified, but isn't
23:59:54 <selsta> What does Size threshold, Percent used, Percent threshold mean during monerod start? Someone reports the daemon getting stuck after precent threshold