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?

the primary could be hidden behind a command/menu item for the thankfully already rare case when subaddresses aren't accepted

IIRC you can't mine to a subaddress (not an inherent limitation, but IIRC the code changes to allow this were hairy).

we are trying something like this for the GUI (show subaddress by default), but not merged yet and is larger change

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?

Are you showing the 0,0 subaddress ? It's not accessible from monero-wallet-cli.

i.e. "click Menu | Item to see your 'mining address'"

i thought 0,0 was special cased to refer to the primary

if true, i mean showing 0,1 by default instead of 0,0/primary

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.

just to be extra clear, i'm proposing a UI-only change, nothing in the protocol

s/could/already does, so no change needed there/

see monero-project/monero-gui #2936

nice

is there any reason this shouldn't be done for cli also?

newly created wallets only, of course

There might be reasons in the issue and/or PR adding subaddresses.

If they boil down to "nobody supports subaddresses yet", then it could be done.

at least something like "get_fresh_address" command

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

what does fresh mean there?

forget what I wrote :) I think that exists already

just a new subaddress

Maybe show a random subaddr by default, from a pool of size determined by the lookahead

nvm, bad idea

it would seem this idea of coinbase only rings is just kicking the can down the road so to speak.

jtgrassie: how so

same question, coinbase txes already stand out so using a different address format in those txes doesn't seem to matter?

Looks like this command doesn't work anymore:

set inactivity-lock-timeout = 0

Am using monero-wallet-cli v0.16.0.0-release

Error: Invalid number of seconds

even positive numbers also get the same error

try without the =

That worked. Thaks

rbrunner: if I made some serialization changes to message_store, would you be able to check it didn't break anything ?

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?

rbrunner: yes. 6690.

(if load-deprecated-formats is set, otherwise it should not read it)

Alright. Probably tomorrow.

No rush. Thanks.

Things deprecate fast nowadays it seems :)

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

It was quite bizarre.

I then switched to boost serialization.

I think it did not only in release builds. Debug builds were ok.

*did it only in

Will check that, for sure.

rbrunner: the messages exchanged between users are short lived, right ?

(bitmessage messages)

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.

The MMS does not delete any message on its own, all deleting from the message store is active.

But if things move forward in a good way you are right that usually they become expendable over a short time.

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.

I think the MMS even deletes them, so they don't stack up, and for security reasons.

does anyone know what this is used for? github.com/monero-project/monero/bl…trib/depends/toolchain.cmake.in#L58

it's used in gitian builds at least

seen it twice now in the codebase but cmake.org/cmake/help/latest/module/FindOpenSSL.html does not have a `OpenSSL_DIR` so I was thinking it’s a typo

ah

same here: github.com/monero-project/monero/blob/master/CMakeLists.txt#L429

ask fluffy? see commit 058eed369b

ok have an idea what it could be used for, but kinda looks like a hack

came from unbound

setting OpenSSL_DIR in toolchain.cmake will have the effect that the system does not look for homebrew openssl

but the value of it is not used anywhere

or it came from here 2d43ae806359c89818c0519d81a65ded768746d8

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

because then you can also manually specify -DOPENSSL_ROOT_DIR and use non standard locations

well, as I recall, we authored the unbound CMakeLists.txt too

and it doesn't appear anywhere else in the unbound tree either

so perhaps it was a typo for OPENSSL_ROOT_DIR

doesn't say much here either monero-project/monero #578

this should work, will test it paste.debian.net/hidden/905ae4ec

or better this: paste.debian.net/hidden/5d199d94

good luck....

would still ask fluffypony if he remembers the actual problem being fixed

if there's an associated issue# with more description

might have been unbound specific

I mean, it's 30 Dec 2015 and I'm probably a whisky deep writing that PR

lol

is it unbound that doesn't have CMake or upnp?

coz one of the two we had to make our own CMake for it, I think it used autotools

unbound uses autotools

yeah so every time I updated it I had to fight with CMake for a day to get it to work

that OpenSSL homebrew thing is definitely code from StackExchange or somewhere

the homebrew thing is ok

I'd be very surprised if I actually reasoned through that

the homebrew bit sets OPENSSL_ROOT_DIR, so it shortcuts the following find_package(OpenSSL REQUIRED)

but it implies that whoever was building on OSX set OpenSSL_DIR on their cmake invocation, manually

it shortcuts it? can you explain?

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

so if you would want a custom OPENSSL_ROOT_DIR you would have to do -DOPENSSL_ROOT_DIR="..." -DOpenSSL_Dir right now

Oh, fighting cmake... I want to punch it in the face almost every time I have to deal with it...

seconded

could be worse

could be autotools

I dunno. Last time I really used those was long enough I long for them when I use cmake. Not libtool though. Fuck libtool.

hyc: yep, works like expected now, the old code also worked by accident because `CMAKE_FIND_ROOT_PATH` was set.

cool

since I've never built OSX binaries besides with gitian, I've never run into whatever the original problem was

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

Looks like they're shipping an emulator for x86, but they highlighted that it's transitional only

and don't forget hyc, it's not ARM, it's "Apple Silicon (tm)"

You're legally required to write it in a pleasant font

sarang: it’s more like a translator, they translate it during install time

binary recompiler

apparently it also works with JIT, would be curious if monerod /randomx works

and the performance difference between native

interesting

I really like how "silicon" readily translates to "silly con".

sillycon valley, yep

But then I've always loved bad puns.

Well, there you go. I knew I couldn't be the first to like bad puns.

It'll be interesting to see what power efficiency they might get out of Apple Silicon (tm) devices

you're required to use the ™ symbol and not (tm) when talking about Apple Compute™

much like this: theverge.com/tldr/2020/6/25/2130283…nt-sans-criticize-disparage-license

(tm)™

So it'll be necessary to maintain the current Mac™ build in addition to a new AppleⓇ™ Silicon©℠™ build?

I may be missing a symbol or two

apologies to the overlords

Or just do the current build and rely on the translatorrecompilerthingy tool

that's a good question

I think we'll likely have a native Mac ARM build in short order since we're already ARM compatible

and pretty much all the underlying FOSS libs / tools we rely on are available for Apple's iOS silicon (eg. on jailbroken phones etc,)

You mean AppleⓇ™ Silicon©℠™ build

sorry yes

the latter

"It's not ARM... but it's not not ARM"

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?

elghosto: are you spending old pre-CT funds?

If not, you almost certainly don't need the spent-output list

I'm doing an EAE attack

maybe don't do that

There is no "official" spent-output list

sgp_ built one using the built-in tools (you could do the same)

Note that any spent-output list you obtain could have been generated adversarially

In theory it's possible to verify, but the tool doesn't currently do this

post-CT outputs are almost entirely unaffected

ugh sorry i got disconnected right after I joked about EAE attack so couldn't see responses

15:57 <sarang> sgp_ built one using the built-in tools (you could do the same)

15:57 <sarang> Note that any spent-output list you obtain could have been generated adversarially

15:58 <sarang> In theory it's possible to verify, but the tool doesn't currently do this

15:58 <sarang> post-CT outputs are almost entirely unaffected

thanks a lot

I can look up the link to sgp_'s list if you like

but again, it assumes some level of trust in the list

does it include post-ct outputs?

Yes, but there are negligible numbers of them

And all from chain splits

None from on-chain chain reaction analysis

Er, there's one small set from a preprint analysis

like 5 outputs

thanks sgp_

I got a tiny amount from chain splits

Yeah I recall it was quite small

and very centered around particular times

those also somewhat account for public pool data around that time

download links seem broken. try github.com/monero-blackball/monero-blackball-site

hmm, I don't actually know what I did with that site anymore lol

Well, the list wasn't verified once imported

So you have to trust whomever generated it

It could be verified, but isn't

What does Size threshold, Percent used, Percent threshold mean during monerod start? Someone reports the daemon getting stuck after precent threshold