00:50:17 <vert3xo> is there any documentation for monero? i'm working on a personal project and i want to create my own wallet but i don't even know what is the address format
00:51:29 <vert3xo> nvm found it, no clue why it wasn't showing up in search results before
00:52:35 <vert3xo> it's unofficial but should be fine
00:52:49 <UkoeHB_> vert3xo: https://web.getmonero.org/library/ https://web.getmonero.org/resources/research-lab/
00:53:24 <UkoeHB_> also https://monero.stackexchange.com/
02:32:51 <erikd> i have my monerod set up under tor and have setup anonymous-inbound, but how do I get a tor seed peer?
05:44:21 <fRit_^> hi, I've found in log those line: ---block added as alternative on hight... reorganize success! What does it mean?
05:47:04 <fRit_^> ok, it doesn't matter
11:02:33 <moneromooo> erikd: Have a look on moneroworld.com, it might list tor peers.
12:09:25 <dEBRUYNE> Are v0.16 wallet compatible with v0.15 remote nodes?
12:14:31 <asymptotically> i'm using an older wallet with my newer node (for ledger compatiblity) and there's no warning
12:16:41 <dEBRUYNE> And syncing etc. also works properly?
12:18:06 <asymptotically> yeah ive made a few transactions too, no problems
12:21:11 <moneromooo> It's the mirror case though. Not sure if it was picked up.
12:29:28 <dEBRUYNE> Ah I didn't even notice asymptotically answer was referring to the mirror case haha
12:29:36 <dEBRUYNE> asymptotically's*
12:31:42 <asymptotically> oh whoops, sorry. i should probably work on my reading skills :P
13:01:17 <selsta> dEBRUYNE: last time I tried yes
13:40:12 <rbrunner> selsta: I started to look into the "help_advanced" story. What would you propose, that the corresponding commit gets deleted on master as well first, or that I modify from the status quo? I don't mind either.
13:40:51 <selsta> whatever you prefer
13:42:11 <rbrunner> Alright, then no delete. With this I can start right now, and wowario still has a contribution counted that gets smaller but not null
14:26:40 <sarang> Possibly silly question: should there be a "community release checklist" that contains all the necessary steps and logistics that should happen prior to and during a release?
14:27:03 <sarang> It's common to joke about how something often gets missed in the process
14:27:15 <moneromooo> pony has one.
14:27:35 <sarang> But if there were literally a checklist on github with things like "someone verifies the hash list signature" and "filenames are correct as expected" etc.
14:27:46 <sarang> then perhaps errors could be reduced
14:27:55 <moneromooo> Step 1. Check against the list.
14:28:25 <sarang> "Checklist culture" is common in aviation and I hear is being applied more broadly in fields like medicine, to great effect
14:28:26 <moneromooo> fluffypony: any chance you can paste your release todo list somewhere ?
14:28:43 <rbrunner> Was also my first thought ... we would forget the list.
14:28:50 <fluffypony> ooooh gosh, let me find it
14:28:52 <sarang> While it might not make sense for everything, I think something like a release, which has a lot of moving parts, could benefit
14:29:17 <sarang> Yes, obviously a list would need to be actually used
14:29:34 <sarang> but perhaps it could avoid the little mishaps that show up from time to time
14:30:17 <fluffypony> - DON'T FORGET TO UPDATE src/version.cpp.in with new version AND new name (if necessary)
14:30:17 <fluffypony> - DON'T FORGET TO UPDATE Gitian YML files in contrib/gitian/ to the new version number
14:30:18 <fluffypony> - DON'T FORGET TO UPDATE README.md with new fork table entry (or at least update the Recommended Monero version)
14:30:18 <fluffypony> - DON'T FORGET TO UDDATE contrib/gitian/README.md so that the instructions reflect the current version
14:30:18 <fluffypony> - DON'T FORGET TO UDDATE src/checkpoints/checkpoints.cpp with a recent hardcoded checkpoint
14:30:18 <fluffypony> - DON'T FORGET TO UPDATE src/blocks/checkpoints.dat with ./monero-blockchain-export --output-file checkpoints.dat --block-stop <recent block height> --blocksdat
14:30:20 <fluffypony> - DON'T FORGET TO UPDATE expected_block_hashes_hash in src/cryptonote_core/blockchain.cpp with checkpoints.dat sha256 hash
14:30:21 <fluffypony> - DON'T FORGET TO POST ABOUT THE RELEASE ON THE MONERO-ANNOUNCE LIST
14:30:22 <fluffypony> that one?
14:30:49 <fluffypony> Final steps:
14:30:50 <fluffypony> - Update hashes.txt on website
14:30:50 <fluffypony> - Update downloads.yml on website
14:30:50 <fluffypony> - Update auto-update DNS records
14:30:51 <fluffypony> - Update redirects on downloads box
14:30:52 <fluffypony> and then that
14:31:00 <asymptotically> fluffypony: you write all those reminders on the back of your hand?
14:31:09 <sarang> Anyway, this popped into my head after someone (binaryFate?) asked for a sanity check regarding the hash list signature
14:31:16 <fluffypony> asymptotically: too much for the back of my hand, so inside of my arm :-P
14:31:37 <sarang> Things like that could be nice to have on some big github issue for which there's a list of what got done, when, and who did it
14:31:45 <sarang> for each release
14:32:14 <moneromooo> Yes. I thought it was longer.
14:32:17 <fluffypony> yeah that's not a bad idea - use the checklist feature
14:32:35 <fluffypony> moneromooo: no I think that's it, it was mostly just a list of things I keep forgetting to do
14:32:39 <fluffypony> keep / kept
14:32:49 <moneromooo> ty
14:33:32 <sarang> Even if the maintainers who do many of those items remember to do them, it's perhaps a way for interested community members to double-check when possible
14:33:43 <sarang> and a great way for newcomers to participate if they want
14:35:47 <fluffypony> and it also means it's not tribal knowledge
14:35:48 <fluffypony> but documented somewhere
14:36:04 <sarang> Yeah
14:37:43 <sarang> Keep the master list in the source tree so it can be modified and tracked over time
14:38:01 <sarang> then use it as a one-off in a github issue or some other appropriate platform for each release
14:39:41 <rbrunner> I like that, tribal knowledge (of the fluffy pony tribe I guess) :) No seriously, certainly useful stored somewhere, as the recent little thing with forgetting to change the release name string showed
14:39:56 <fluffypony> maybe a RELEASE.md
14:41:29 <sarang> rbrunner: yeah, having lots of little things to do for a big task is precisely where checklists shine
14:42:30 <sarang> It's still how every stage of every commercial flight you take is done, even when the pilots have been in the field for decades
16:00:03 <fluffypony> sarang: and git is our black box?
16:00:04 <fluffypony> :-P
17:07:49 <kinghat[m]> should the GUI and CLI be released in tandem? seems odd that they are not. i do realize that the GUI is usually not far behind and that everyones hard work wants to be out in the wild as fast as possible.
17:13:48 <selsta> I wish we could put them out simultaneously
17:15:36 <selsta> but until we have reproducible builds someone trusted (who is not anonymous) has to do builds
17:17:10 <kinghat[m]> and thats fine but they can still be released at the same time.
17:17:44 <selsta> I don’t see benefit in artificially delaying the CLI build
17:19:46 <kinghat[m]> to me the image looks like we dont really care about the GUI or its users when in reality its the opposite, which is unfortunate. i mean, i dont have any numbers but id say the majority of transactions, outside of exchanges/pools, are via the GUI. not sure if thats knowable 🤷‍♂️
17:22:35 <selsta> If we did everything correct it is not knowable
17:24:56 <kinghat[m]> you might be correct that theres no reason to hodl the CLI, technically, but id argue perception is one.
17:31:46 <rbrunner> My brand new 0.16.0.0 Windows daemon tells me as output to the status command "update needed". Really? :)
17:32:21 <rbrunner> Ah, no, sorry, strike that, wrong daemon started :(
17:33:55 <rbrunner> I think I am just too tired. The 0.16.0.0 tells me the same ...
17:34:16 <moneromooo> That's the time based system. Just needs removing too.
17:34:37 <rbrunner> So it's known. Good.
17:35:36 <selsta> Didn’t we remove that?
17:37:23 <moneromooo> Not this one :)
17:55:59 <niocbrrrrrr> I do not get that message from status using windows
19:56:25 <hyc> hm, my v0.16 daemon is saying update needed
19:56:27 <hyc> Height: 2105560/2105560 (100.0%) on mainnet, not mining, net hash 1.27 GH/s, v12, update needed, 8(out)+31(in) connections, uptime 0d 18h 18m 49s
19:59:26 <moneromooo> I'll fix when I'm not despondent about the state of privacy and how this world is going to shit after having banged us into the ground.
19:59:43 <moneromooo> (trivial, just cba atm)
20:00:01 <hyc> dude... have a drink, chill out for a while
20:00:19 <moneromooo> I've got the first one pat.
20:00:31 <hyc> heh
20:00:42 <moneromooo> Bottle's empty though.
20:00:48 <hyc> I had wine & pizza tonight. well, still have wine, pizza's finished
20:01:02 <moneromooo> Wine and pizza too :D
20:01:16 <SerHack> :- )
20:01:16 * moneromooo tiptoes out of -dev
20:11:53 <niocbrrrrrr> I am confirmed blind, mine does say update needed
20:18:08 <Guest59457> I created wallet using monero wallet rpc....Why it does not gives mnemonic seeds when the wallet is created?
20:43:51 <fluffypony> moneromooo, hycsnap
20:43:55 <fluffypony> hyc: snap
20:43:56 <fluffypony> that thing
20:44:38 <fluffypony> I did chicken strips, peppadew, avo, feta, and mayo
20:44:51 <fluffypony> perfetto
20:44:59 <fluffypony> welcome to #monero-food
20:52:42 <TheCharlatan> where do I post my nofilter pictures?
20:54:44 <TheCharlatan> selsta, just remembered about the libc minimum version increase - I should have patched that, but did not get to it the past weeks.
20:56:14 <hyc> lol. #monero-food should be a thing
20:56:34 <hyc> TheCharlatan: what can you patch to tweak the libc min version?
20:59:59 <TheCharlatan> from what I can see it's a single symbol "signgam", or rather just a single extern variable. It was changed in glibc 2.23 : https://chromium.googlesource.com/native_client/nacl-glibc/+/refs/tags/glibc-2.23
21:00:45 <TheCharlatan> I'm still looking into what exactly we can do to force the old behaviour from glibc 2.2.5
21:09:39 <selsta> TheCharlatan: yep, would be cool to fix
21:27:12 <TheCharlatan> I can't seem to pinpoint what triggered this change in the first place.
21:45:25 <moneromooo> hyc: 6588
21:49:16 <hyc> hmmm
21:49:32 <hyc> so no more warning about update needed on future hardfork?
21:50:21 <selsta> is there a good solution if we will do irregular hardforks in the future?
21:50:51 <hyc> add it to DNSSEC?
21:51:00 <hyc> when we decide we are going to hardfork in next release
21:53:26 <moneromooo> It'll still moan if it sees a newer version in DNS records.
21:58:26 <selsta> Do you also want to PR against branch to avoid confusion / questions?
22:01:08 <moneromooo> You're making a new release ?
22:01:42 <moneromooo> If so, I'll also PR 6584.
22:02:50 <selsta> We can also cherry pick things we want in the release later
22:03:03 <selsta> probably better
22:03:41 <selsta> No release planned yet
22:18:23 <erikd> moneromooo: thanks. i have both onion and i2p peers now