06:37:31 <fluffypony> we could add more recent checkpoint hints to the MoneroPulse records
06:37:39 <fluffypony> not sure if it'd help in that case
12:24:50 <gingeropolous> knaccc, if there's a gingeropolous-friendly copypasta i can run a mipseed on the uwillrunanodesoon box
12:27:36 <selsta> gingeropolous: https://github.com/i2p-zero/i2p-zero/blob/master/mipseed.md
12:27:55 <gingeropolous> danke
13:56:09 <knaccc> gingeropolous ooh nice, thanks! if you need assistance, pls join #i2p-zero
16:47:26 <moneromooo> rehrar: does the ccs stuff still run on the monero gitlab ?
16:48:08 <rehrar> yes
16:48:12 <rehrar> you want to switch it over to github?
16:48:21 <moneromooo> No.
16:48:32 <moneromooo> Well, not particularly.
16:49:30 <ErCiccione[m]> we discussed a bit at the time and people preferred to leave it there. I agree
16:49:44 <rehrar> I do as the community demands.
17:07:48 <fluffypony> it's not a particularly expensive box, like 30 EUR a month, so I'm fine with leaving it
17:08:15 <fluffypony> 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
17:18:21 <sarang> How much automated build testing is done on GitHub/other free resources?
17:20:10 <fluffypony> previously with buildbot it had to be native
17:20:11 <fluffypony> so nothing
17:20:19 <fluffypony> that's changed since cross-compilation went in
17:20:57 * iDunk comforts selsta
17:29:32 <tevador> does it make sense to differentiate mnemonic seeds for mainnet/stagenet/testnet?
17:29:47 <tevador> I would think yes
17:31:03 <gingeropolous> yeah. plenty of times i've tried restoring testnet seeds on mainnet thinking i had found some treasure scribbles
17:34:43 <selsta> fluffypony: github has free mac and windows VMs for CI
17:34:51 <selsta> or maybe I misunderstood your comment :P
17:35:24 <fluffypony> selsta: the buildbot infrastructure dates back to like 2015
17:35:34 <fluffypony> when we had fewer options
17:35:36 <selsta> yep true
17:35:46 <selsta> probably best there was in 2015
17:36:01 <fluffypony> yeah
17:36:35 <fluffypony> definitely much better options now for open-source projects
17:37:36 <iDunk> Travis-ci is for depends bulds, gh-actions are native builds, AFAIK.
17:37:59 <selsta> yes
17:38:36 <selsta> both could be used for both theoretically
18:06:35 <moneromooo> vtnerd_: I think the matches(legacy) is probably wrong in the patch from a couple days ago.
18:07:52 <moneromooo> Hmm, wait, looking some more...
18:10:33 <moneromooo> 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.
18:10:57 <moneromooo> So it breaks up my tests but might actually be otherwise ok...
18:31:44 <knaccc> 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
18:31:46 <knaccc> because it's announcing txs to the mipseeds, and the mipseeds will silently never relay them
18:33:55 <moneromooo> If you're connected only to those, you'll likely never receive any tx/block, yes.
18:34:22 <knaccc> doh
18:35:16 <knaccc> 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?
18:35:45 <moneromooo> By default, 8 out and no limit (beyond OS limits) on in.
18:36:09 <knaccc> and is that 8 total between all network types, or 8 for ipv4 and 8 for i2p?
18:36:23 <moneromooo> It's kinda random. It'll try to avoid IP addresses in the same /24. Doesn't apply to I2P.
18:36:45 <knaccc> but 8 total?
18:37:01 <knaccc> so ipv4+i2p conns=8?
18:37:02 <moneromooo> I don't know. Ask... whoever did it.
18:37:10 <moneromooo> I think vtnerd ?
18:37:23 <knaccc> i think so, ok thanks mooo
18:38:46 <knaccc> what does -1 mean for out-peers/in-peers? unlimited?
18:39:02 <knaccc> or does that mean use the default of 8
18:39:59 <knaccc> 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?
18:41:04 <knaccc> and how often does monerod ask its peers about other known peers?
18:41:41 <knaccc> and is there a limit to how many peers monerod will inform other peers about?
18:44:46 <moneromooo> -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.
18:50:57 <knaccc> what would you recomment that out-peers/in-peers are set to, for a seed node?
18:51:00 <knaccc> recommend*
18:56:18 <moneromooo> Must I have a recommendation for that ?
19:01:07 <dEBRUYNE> Does anyone have verification performance figures for newly received block
19:01:22 <dEBRUYNE> i.e. a node runs 24/7, it receives a new block, how long does it take to verify?
19:02:33 <moneromooo> 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).
19:03:33 <dEBRUYNE> An average would be interesting. I am interested in making a comparison to Bitcoin, hence
19:03:34 <knaccc> ok cool, we'll see how it goes and adjust things if necessary
19:14:22 <binaryFate> 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.
19:15:17 <moneromooo> Might be useful for default settings (ie, always set ask-password to 0, etc).
19:15:59 <binaryFate> 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
19:17:13 <binaryFate> or create a non-persistent one as a pass-through, and then get hit by time-consuming options like ask-password
19:17:51 <binaryFate> maybe upon creation and/or as a menu command at any time, we could do <apply_global_config_to_this_wallet>
19:18:10 <binaryFate> so it remains explicit if you want to get rid of default safe choices
19:19:13 <binaryFate> might be better to use a template config file as a parameter then, no need for a global stuff on machine / user session
19:20:09 <binaryFate> curious if that sort of stuff would be useful to others? Well possibily overkill or too specific to some of my usage
20:06:55 <luigi1111w> moneromooo would you mind re-approving supercop 3
20:11:44 <moneromooo> Looks like I can't tell what's changed since the version I reviewed :/
20:12:05 <moneromooo> So if I still can't in a few minutes I'll just OK it blind.
20:12:26 <luigi1111w> oh, rip. ok
20:13:34 <moneromooo> I think github kinda GCed an old commit...
20:15:05 <moneromooo> done
20:16:24 <selsta> moneromooo: are you ok with 6637 to fix functional tests?
20:16:47 <moneromooo> Fixing tests is always good.
20:19:50 <selsta> ok luigi1111w please also merge 6637 (not sure if you will do CLI merges)
20:22:23 <moneromooo> Are you implying I'm not ok with all the other patches before it ?
20:22:49 <moneromooo> (not that I mind this one getting a free pass to the front)
20:24:12 <selsta> no, I changed something in the functional tests so I thought I would ask you
20:24:17 <selsta> though the change was trivial
20:28:25 <moneromooo> 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 ?
20:29:22 * moneromooo had a few reasons to be wary of people trying things with questionable arguments recently ^_^
20:30:05 <moneromooo> (the usual exception to the 10 day wait it when it's a compile fix)
20:39:45 <selsta> I wanted to get CI (and functional tests) fixed
20:40:27 <moneromooo> Ah, that sounds fine to me.
20:41:10 <selsta> 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.
20:42:12 <moneromooo> Sure. I did not think that it would show as an error on every PR, that's a good reason to merge it first.
20:52:07 <binaryFate> good spirit anyway moneromooo :)
21:31:51 <caralho> binaryFate, <3
21:38:44 <vtnerd_> knaccc : the in/out peers should be per zone. in other words out_peers=10 should mean 10 out peers per zone
21:38:55 <vtnerd_> I double checked, and the logic looks like that, but I didn't test to verify
21:40:15 <knaccc> vtnerd_ thanks, and 'zone' means ipv4/tor/i2p?