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

nvm found it, no clue why it wasn't showing up in search results before

it's unofficial but should be fine

vert3xo: web.getmonero.org/library web.getmonero.org/resources/research-lab

also monero.stackexchange.com

i have my monerod set up under tor and have setup anonymous-inbound, but how do I get a tor seed peer?

hi, I've found in log those line: ---block added as alternative on hight... reorganize success! What does it mean?

ok, it doesn't matter

erikd: Have a look on moneroworld.com, it might list tor peers.

Are v0.16 wallet compatible with v0.15 remote nodes?

i'm using an older wallet with my newer node (for ledger compatiblity) and there's no warning

And syncing etc. also works properly?

yeah ive made a few transactions too, no problems

It's the mirror case though. Not sure if it was picked up.

Ah I didn't even notice asymptotically answer was referring to the mirror case haha

asymptotically's*

oh whoops, sorry. i should probably work on my reading skills :P

dEBRUYNE: last time I tried yes

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.

whatever you prefer

Alright, then no delete. With this I can start right now, and wowario still has a contribution counted that gets smaller but not null

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?

It's common to joke about how something often gets missed in the process

pony has one.

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.

then perhaps errors could be reduced

Step 1. Check against the list.

"Checklist culture" is common in aviation and I hear is being applied more broadly in fields like medicine, to great effect

fluffypony: any chance you can paste your release todo list somewhere ?

Was also my first thought ... we would forget the list.

ooooh gosh, let me find it

While it might not make sense for everything, I think something like a release, which has a lot of moving parts, could benefit

Yes, obviously a list would need to be actually used

but perhaps it could avoid the little mishaps that show up from time to time

- DON'T FORGET TO UPDATE src/version.cpp.in with new version AND new name (if necessary)

- DON'T FORGET TO UPDATE Gitian YML files in contrib/gitian/ to the new version number

- DON'T FORGET TO UPDATE README.md with new fork table entry (or at least update the Recommended Monero version)

- DON'T FORGET TO UDDATE contrib/gitian/README.md so that the instructions reflect the current version

- DON'T FORGET TO UDDATE src/checkpoints/checkpoints.cpp with a recent hardcoded checkpoint

- DON'T FORGET TO UPDATE src/blocks/checkpoints.dat with ./monero-blockchain-export --output-file checkpoints.dat --block-stop <recent block height> --blocksdat

- DON'T FORGET TO UPDATE expected_block_hashes_hash in src/cryptonote_core/blockchain.cpp with checkpoints.dat sha256 hash

- DON'T FORGET TO POST ABOUT THE RELEASE ON THE MONERO-ANNOUNCE LIST

that one?

Final steps:

- Update hashes.txt on website

- Update downloads.yml on website

- Update auto-update DNS records

- Update redirects on downloads box

and then that

fluffypony: you write all those reminders on the back of your hand?

Anyway, this popped into my head after someone (binaryFate?) asked for a sanity check regarding the hash list signature

asymptotically: too much for the back of my hand, so inside of my arm :-P

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

for each release

Yes. I thought it was longer.

yeah that's not a bad idea - use the checklist feature

moneromooo: no I think that's it, it was mostly just a list of things I keep forgetting to do

keep / kept

ty

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

and a great way for newcomers to participate if they want

and it also means it's not tribal knowledge

but documented somewhere

Yeah

Keep the master list in the source tree so it can be modified and tracked over time

then use it as a one-off in a github issue or some other appropriate platform for each release

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

maybe a RELEASE.md

rbrunner: yeah, having lots of little things to do for a big task is precisely where checklists shine

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

sarang: and git is our black box?

:-P

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.

I wish we could put them out simultaneously

but until we have reproducible builds someone trusted (who is not anonymous) has to do builds

and thats fine but they can still be released at the same time.

I don’t see benefit in artificially delaying the CLI build

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 🤷‍♂️

If we did everything correct it is not knowable

you might be correct that theres no reason to hodl the CLI, technically, but id argue perception is one.

My brand new 0.16.0.0 Windows daemon tells me as output to the status command "update needed". Really? :)

Ah, no, sorry, strike that, wrong daemon started :(

I think I am just too tired. The 0.16.0.0 tells me the same ...

That's the time based system. Just needs removing too.

So it's known. Good.

Didn’t we remove that?

Not this one :)

I do not get that message from status using windows

hm, my v0.16 daemon is saying update needed

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

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.

(trivial, just cba atm)

dude... have a drink, chill out for a while

I've got the first one pat.

heh

Bottle's empty though.

I had wine & pizza tonight. well, still have wine, pizza's finished

Wine and pizza too :D

:- )

I am confirmed blind, mine does say update needed

I created wallet using monero wallet rpc....Why it does not gives mnemonic seeds when the wallet is created?

moneromooo, hycsnap

hyc: snap

that thing

I did chicken strips, peppadew, avo, feta, and mayo

perfetto

welcome to #monero-food

where do I post my nofilter pictures?

selsta, just remembered about the libc minimum version increase - I should have patched that, but did not get to it the past weeks.

lol. #monero-food should be a thing

TheCharlatan: what can you patch to tweak the libc min version?

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 : chromium.googlesource.com/native_cl…t/nacl-glibc/+/refs/tags/glibc-2.23

I'm still looking into what exactly we can do to force the old behaviour from glibc 2.2.5

TheCharlatan: yep, would be cool to fix

I can't seem to pinpoint what triggered this change in the first place.

hyc: 6588

hmmm

so no more warning about update needed on future hardfork?

is there a good solution if we will do irregular hardforks in the future?

add it to DNSSEC?

when we decide we are going to hardfork in next release

It'll still moan if it sees a newer version in DNS records.

Do you also want to PR against branch to avoid confusion / questions?

You're making a new release ?

If so, I'll also PR 6584.

We can also cherry pick things we want in the release later

probably better

No release planned yet

moneromooo: thanks. i have both onion and i2p peers now