we could add more recent checkpoint hints to the MoneroPulse records

not sure if it'd help in that case

knaccc, if there's a gingeropolous-friendly copypasta i can run a mipseed on the uwillrunanodesoon box

gingeropolous: github.com/i2p-zero/i2p-zero/blob/master/mipseed.md

danke

gingeropolous ooh nice, thanks! if you need assistance, pls join #i2p-zero

rehrar: does the ccs stuff still run on the monero gitlab ?

yes

you want to switch it over to github?

No.

Well, not particularly.

we discussed a bit at the time and people preferred to leave it there. I agree

I do as the community demands.

it's not a particularly expensive box, like 30 EUR a month, so I'm fine with leaving it

plus we recently decommissioned one of the old buildbot VM boxes and all the Mac buildbot boxes, so our monthly costs are already quite reduced

How much automated build testing is done on GitHub/other free resources?

previously with buildbot it had to be native

so nothing

that's changed since cross-compilation went in

does it make sense to differentiate mnemonic seeds for mainnet/stagenet/testnet?

I would think yes

yeah. plenty of times i've tried restoring testnet seeds on mainnet thinking i had found some treasure scribbles

fluffypony: github has free mac and windows VMs for CI

or maybe I misunderstood your comment :P

selsta: the buildbot infrastructure dates back to like 2015

when we had fewer options

yep true

probably best there was in 2015

yeah

definitely much better options now for open-source projects

Travis-ci is for depends bulds, gh-actions are native builds, AFAIK.

yes

both could be used for both theoretically

vtnerd_: I think the matches(legacy) is probably wrong in the patch from a couple days ago.

Hmm, wait, looking some more...

Might be intended... But if the tx send via RPC does not get relayed by dandelion, then it won't get mined. I suppose it would get mined once the timeout triggers though.

So it breaks up my tests but might actually be otherwise ok...

if someone runs a mipseed with --no-sync due to lack of available storage space, is the connecting node blind to whether the mipseed is intentionally not sharing txs? If I tell people they can run mipseeds with no-sync and save money on their VPS, i'm wondering if that could mean that an end user might connect to 5 mipseeds, never receive any new txs from them via I2P, and end up shouting into the wind

because it's announcing txs to the mipseeds, and the mipseeds will silently never relay them

If you're connected only to those, you'll likely never receive any tx/block, yes.

doh

how many connections does monerod decide to keep open? does it basically just choose peers at random after it tries to find out about as many as it can?

By default, 8 out and no limit (beyond OS limits) on in.

and is that 8 total between all network types, or 8 for ipv4 and 8 for i2p?

It's kinda random. It'll try to avoid IP addresses in the same /24. Doesn't apply to I2P.

but 8 total?

so ipv4+i2p conns=8?

I don't know. Ask... whoever did it.

I think vtnerd ?

i think so, ok thanks mooo

what does -1 mean for out-peers/in-peers? unlimited?

or does that mean use the default of 8

and does it make sense that I should set out-peers and in-peers really high, so that it is aware of as many peers as possible?

and how often does monerod ask its peers about other known peers?

and is there a limit to how many peers monerod will inform other peers about?

-1: I'd have to grep. High limits: limits are actual connections, not peer list sizes. How often... I tihnk every couple minutes or so. Limit: 250 per message. Wait more to get more.

what would you recomment that out-peers/in-peers are set to, for a seed node?

recommend*

Must I have a recommendation for that ?

Does anyone have verification performance figures for newly received block

i.e. a node runs 24/7, it receives a new block, how long does it take to verify?

It depends a lot of how any txes are in, whether they were already in the txpool, how many outputs they have (and inputs to some lesser degree).

An average would be interesting. I am interested in making a comparison to Bitcoin, hence

ok cool, we'll see how it goes and adjust things if necessary

fun idea or stupid overkill? A global config for wallets (stored in ~/.bitmonero) on top of local one (stored as it is now in wallet). Similar to git config. With convenient way to define what takes precendence between global and local.

Might be useful for default settings (ie, always set ask-password to 0, etc).

yeah that'd be my use-case. I sometimes have quite some wallets on the same machine and they're never on the same options it's juggly

or create a non-persistent one as a pass-through, and then get hit by time-consuming options like ask-password

maybe upon creation and/or as a menu command at any time, we could do <apply_global_config_to_this_wallet>

so it remains explicit if you want to get rid of default safe choices

might be better to use a template config file as a parameter then, no need for a global stuff on machine / user session

curious if that sort of stuff would be useful to others? Well possibily overkill or too specific to some of my usage

moneromooo would you mind re-approving supercop 3

Looks like I can't tell what's changed since the version I reviewed :/

So if I still can't in a few minutes I'll just OK it blind.

oh, rip. ok

I think github kinda GCed an old commit...

done

moneromooo: are you ok with 6637 to fix functional tests?

Fixing tests is always good.

ok luigi1111w please also merge 6637 (not sure if you will do CLI merges)

Are you implying I'm not ok with all the other patches before it ?

(not that I mind this one getting a free pass to the front)

no, I changed something in the functional tests so I thought I would ask you

though the change was trivial

You might not know, so: PRs are usually merged in filing order, and not before 10 days available for review. So you asking me if I liked this PR then asking for it to get merged seemed a lot like "see, mooo said so, merge it now". Maybe I'm being too paranoid ?

(the usual exception to the 10 day wait it when it's a compile fix)

I wanted to get CI (and functional tests) fixed

Ah, that sounds fine to me.

Didn’t intend to sneak this in. Not sure if it appeared this way. The change is trivial anyway and has 2 core team approvals.

Sure. I did not think that it would show as an error on every PR, that's a good reason to merge it first.

good spirit anyway moneromooo :)

binaryFate, <3

knaccc : the in/out peers should be per zone. in other words out_peers=10 should mean 10 out peers per zone

I double checked, and the logic looks like that, but I didn't test to verify

vtnerd_ thanks, and 'zone' means ipv4/tor/i2p?