01:01:38 <anon82347574> Can anyone answer this? https://monero.stackexchange.com/questions/12193/using-the-rpc-access-data-method-daemon-rpc
01:11:59 <moneromooo> IIRC, if you access it from the unrestricted port, it gives you "false" information since there are two RPC servers. I *think* you can't do it atm, it'd need some code change.
01:12:28 <moneromooo> Ideally by not starting two RPC servers, but just having one listen on two ports.
12:20:24 <azy> running multiple walletrpcs is fine, right? is there a limit to how many you can run?
12:23:44 <moneromooo> Yes. Only system limits.
12:23:55 <azy> great, ty
14:44:43 <selsta> moneromooo: #6556 no required for branch?
14:45:25 <selsta> ok looks like this is only fixes bad usage
14:45:28 <selsta> so probably not
15:30:19 <moneromooo> No, it's only a test thing, and it looks like memory layout makes it do the "right thing" in practice.
15:45:06 <moneromooo> Any other opinion on 6554 ? Looks like a typical "perfect is the enemy of good" thing, but I may be biased.
15:47:27 <moneromooo> woodser_: the "failed to die" errors you posted a while back are fine, I had them and understand why (and why it's fine).
15:48:06 <woodser_> ok cool
15:58:54 <hyc> why are GUI builds so slapdash random? https://old.reddit.com/r/Monero/comments/gm0b4g/latest_monero_gui_for_linux_other_currencies/fr0qddz/
15:59:11 <hyc> one release "oh we didn't build with trezor support"
15:59:18 <hyc> another "oh we didn't build with networking"
15:59:19 <hyc> come on
16:00:29 <selsta> because snipa did them and it was the first time he compiled then
16:01:07 <selsta> we asked for testers on Reddit and they didn’t find these things
16:01:18 <selsta> I can’t test everything :)
16:13:48 <moneromooo> ...networking ?
16:14:46 <selsta> qt networking is only used for fiat price conversion
16:18:05 <selsta> anyone who cares about it and can’t wait for the next release can compile themselves
16:43:12 <sarang> Windows CI currently failing?
16:44:54 <selsta> maybe, can you post logs?
16:45:20 <selsta> they update the Windows image every 2 weeks and things randomly break
16:47:33 <sarang> e.g. https://github.com/SarangNoether/monero/runs/686063757
16:47:40 <sarang> ^ current master
16:48:13 <selsta>  can you rerun?
16:48:40 <selsta> if it still fails it is some msys2 issue that will probably solve itself after some time
16:50:09 <sarang> Re-running now
16:51:34 <sarang> Nope, still fails
16:53:41 <selsta> sarang: https://github.com/msys2/MSYS2-packages/issues/1960
16:54:22 <sarang> delightful :D
17:35:08 <selsta> #6543 #6545 #6551 #6554 need reviews / approvals
17:35:21 <selsta> else we can’t tag
17:42:11 <rbrunner> How will the order be between rebasing my #6548 after moneromooo's PR it refers is merged, and that tag? Or, can you set the tag before everything is properly merged?
17:45:54 <luigi1111w> tag needs everything merged
17:55:02 <selsta> ty rbrunner two remaining
17:55:42 <rbrunner> Yeah, with stuff way over my head :)
17:55:53 <selsta> xiphon: would you be ok with 6554 for now and it can get improved later?
18:08:33 <selsta> moneromooo: can 6550 be merged now that rbunner approved it?
18:08:50 <selsta> (asking so that luigi can merge early so that rbunner can rebase)
18:17:33 <xiphon> selsta: commented on Github (i'm okay with 2/3 commits)
18:17:46 <selsta> ty
18:33:46 <moneromooo> I'll just make a little change to 6550, gimme a couple minutes.
18:38:45 <moneromooo> 6550 pushed (s/tolower/towlower/) but it'll be a bit before it's built it.
18:40:10 <rbrunner>  What do you think, after it's ready, maybe best for me to delete the version of that commit I have in branch first before rebasing?
18:40:20 <rbrunner> *in my branch
18:41:32 <moneromooo> Yes, since the commit is now slightly different, so you'd have to resolve a conflict.
18:41:48 <rbrunner> Alright, thanks.
18:48:33 <xmrpow> : Hello, im the op of xmrpow.de. I found out that other pools like supportxmr etc are having some small advantage concerning getting new blocks. For example: supportxmr is able to send jobs to its miners 2 sec earlier than xmrpow.de does. Although im closer to my own server when i tested that. I have seen worse but it's still improvable. Therefore I asked what supportxmr admin does to achieve that. He told me that he is operat
18:48:33 <xmrpow>  of nodes and these nodes do have a special messaging queue which they use to communicate with each other. Because we are a small pool we can not afford to host monerod in all regions of the world. Do you have some idea how I could solve the problem? Are there some special monerod optimizations?
18:49:40 <moneromooo> It might be they cheat by delaying blocks a bit when sending to others. Some pools do that.
18:49:54 <moneromooo> Well, it's not really cheating, just being a bit of an asshole.
18:50:03 <xmrpow> Might be possible ...
18:50:20 <moneromooo> Might be monerod's relay is being inefficient too, improvements welcome.
18:50:37 <moneromooo> 2 seconds seems a bit much for just inefficient.
18:50:52 <rbrunner> From all I heard and read about supportxmr it would be something of a surprise to me that they should play unfair.
18:50:59 <moneromooo> Could also be your link to that pool just goes through many network hops.
18:51:02 <xmrpow> So you mean wrong config?
18:51:21 <moneromooo> Or maybe you're wrong about the 2 second delay.
18:51:34 <xmrpow> Nope tested it multiple times..
18:53:37 <xmrpow> What do you think would be a normal delay?
18:54:18 <xmrpow> 50 ms?
18:55:55 <moneromooo> Sounds fast. The noncesense people probably have that data. Or ways to get at it.
18:57:41 <xmrpow> So no special monerod config....
18:59:04 <asymptotically> would it be bad/rude/dumb to make a new node that just relayed blocks and transactions and didn't store a chain? so that xmrpow could have nodes all over the world but without paying for nice enough machines to run a full monerod
18:59:18 <moneromooo> Yes.
18:59:42 <moneromooo> There's an option in moenerod which does this now,  which kinda sucks but there was a reason for it IIRC.
19:00:10 <moneromooo> The chain fits in ~25 GB though.
19:00:19 <selsta> you can run monerod on like $5 VPS
19:00:36 <xmrpow> Ok but if you need 30 of them per month
19:00:41 <xmrpow> not in our budget
19:00:45 <xmrpow> we are quite small
19:00:58 <moneromooo> You don't need, you want.
19:01:16 <moneromooo> As usual, pay more and get more performance.
19:02:14 <rbrunner> Well, if your daemon does not hear early about a block, that's it already, seems to me: It is blissfully unaware until the floodfill algorithm reaches it. How could you possibly improve on that?
19:02:18 <moneromooo> Block propagatoin might be worth going over, might be easy wins.
19:02:34 <asymptotically> ah found it. --no-sync was added so that wallets can join to find public rpc nodes
19:02:50 <moneromooo> Ah, yes. It makes sense for this use.
19:03:12 <moneromooo> Though I guess it also means public rpc nodes make everything suck.
19:03:53 <rbrunner> Sounds like wifi repeaters to me, daemons running with that option :)
19:04:50 <asymptotically> rbrunner: that's what i was thinking with the dumb nodes :D - although if there's more than a handful of them they'd probably just get in the way and slow things down
19:04:50 <sech1> each node has to verify PoW and transactions on the block, so block propagation is slowed down considerably compared to blind repeaters
19:05:19 <moneromooo> Txes are usually verified already.
19:05:54 <sech1> but PoW on a cheap VPS is easily 20+ ms delay
19:06:46 <xmrpow> @moneromoo We need it because otherwise we can not compete that well....
19:07:04 <rbrunner> Who knows, maybe the main Monero hashrate is somewhat geographically clustered, and with 2 or 3 nodes placed strategically in the centers of the clusters you are already a little faster
19:07:28 <rbrunner> See what I mean? If you place your nodes at the places where, on average, the most new blocks will pop up first?
19:07:53 <rbrunner> But then of course you need a mechanism for them to "phone home" the news fast enough
19:08:11 <xmrpow> @rbrunner understood but it s costly....
19:08:22 <rbrunner> 2, 3 nodes?
19:08:27 <moneromooo> And I need the latest ryzen monster because otherwise I can't compile that well...
19:08:36 <iDunk> True
19:08:38 <xmrpow> @rbrunner now?
19:08:39 <moneromooo> lol
19:09:14 <moneromooo> Anyway, I'll add "check block propagation for easy wins" in my list. But that'll be lowush priority.
19:09:15 <rbrunner> What do you mean with "now"? Maybe there are only 2 or 3 such Monero mining clusters worldwide where you would lurk for new blocks
19:09:23 <asymptotically> xmrpow: maybe you could ask m5m for the address of one of his nodes and then --add-priority-node it?
19:11:03 <xmrpow> @monermoo Miners currently dont care about network decentralization, so we have to get every plus point we can...
19:11:14 <xmrpow> @asymp maybe an idea
19:11:29 <moneromooo> Seriously, anyone else with an opinion on 6554 ? xiphon doesn't like one of the commits, I like it, so we need a tie breaker :P
19:11:53 <sech1> I would just collect as many node IPs as possible and then watch which one of them propagate blocks first. But that requires skill and a few modifications to monerod code
19:12:07 <Inge-> Knife Scissor Paper Lizard Spock?
19:12:45 <Isthmus> Hmm, I think I shared some updated block propagation histograms in a #monero-research-lab, lemme see if I dropped the plots on the GitHub agenda
19:12:46 <moneromooo> monerod logs received blocks, if that's what you're hinting at (net.p2p.msg).
19:15:19 <selsta> rbrunner: can you reapprove 6551? :)
19:15:27 <selsta> seems to compile
19:16:33 <xmrpow> @sech1 im not into c and c++. So no option for me
19:17:12 <rbrunner> @selsta, regarding 6551: Well, trying it again interactively in its updated version would be some work which I could not do today still.
19:17:50 <selsta> ok np
19:20:52 <selsta> ok maybe we can find a solution for #6554 until tomorrow :P
19:22:01 <moneromooo> Guess I could go and find the max bytes that can be requested before and after.
19:22:53 <moneromooo> xiphon: is your objection more about "it doesn't help that much" or "it breaks hypothetical spammy third party p2p code" ?
19:22:59 <moneromooo> Or both.
19:23:45 <xiphon> moneromooo: the main objection is that we break the p2p protocol
19:24:05 <xiphon> what was allowed yesterday becomes forbidden tomorrow
19:24:33 <moneromooo> OK, that's the thing I don't care about then ^_^
19:24:59 <xiphon> and we do this fo no good reason, but just beause it is" easir to implement the check the this way"
19:25:08 <xiphon> and it is not obivous that the check is necessary
19:25:20 <xiphon> do we have a PoC?
19:25:23 <moneromooo> Oh it's not necessary. It just allows mitigating.
19:25:33 <moneromooo> xnbya: do you have a PoC ?
19:26:19 <moneromooo> I mean, mitigating DoS is pretty much always going to be about preventing something that was allowed before, save for efficiency improvements on the server.
19:26:24 <xiphon> basically - is allowing 100 pre-v4 blocks per request a problem?
19:26:52 <moneromooo> Depends on your definition of problem I guess.
19:26:55 <xiphon> and if it is, the next question - does limiting it to 20 pre-v4 blocks per request solves the problem?
19:27:04 * moneromooo gives up
19:27:08 <xiphon> yep, that's it
19:27:54 <rbrunner> It's hard to say, but at least I think I understand xiphon's argument: You look from the outside, treat the daemon as a blackbox, you see a call that looks like you could pick block #0 and block #100 in one go, and then it balks. You are baffled.
19:28:16 <moneromooo> Yes, I understand the argument, I just don't care about it.
19:28:43 <moneromooo> There's probably no code that does it (except maybe spamming code).
19:29:39 <rbrunner> Hmmm, yes, but such "probably's" tend to make me slightly uneasy. It's a complex system overall.
19:30:25 <moneromooo> That makes me completely easy. I really do not give a shit about breaking third party code that's asking too much at once.
19:31:01 <moneromooo> Just because a sanity check was high before should not be a reason to never make it stricter it it causes trouble.
19:31:04 <rbrunner> I don't see the connection, my example is a call that gets exactly 2 blocks
19:31:15 <rbrunner> Or maybe I misunderstand
19:31:57 <moneromooo> No, you don't misunderstnad I think.
19:33:15 <moneromooo> So you care about such a use being newly restricted then ?
19:33:34 <moneromooo> Even though we never do it, and there's no evidence given anyone does ?
19:34:24 <rbrunner> A little bit :) Just a hunch after 30 years in IT where more than once I had my "Nobody uses this, out of the window" followed by "ooops" moments :)
19:34:54 <moneromooo> Alright. Then since I said we needed a tie breaker, I'll remove it then.
19:35:00 <moneromooo> (still sucks :P)
19:36:03 <selsta> lol, the last two commits before the tag
19:36:23 <selsta> had more discussions than all other in the last months
19:36:25 <moneromooo> done
19:44:35 <rbrunner> Alright, people, have to go, will be able to rebase my PR tomorrow morning UTC at the earliest
19:46:56 <rbrunner> Just saw vtnerd's review comments about it. Not sure what to do with them all ...
19:51:43 <moneromooo> All the ones about "utf8canonnical could change" you can ignore IMHO. It's not new code, if he wants it changed, he can patch it (or someone else can) later. No sense in putting that in those PRs.
20:35:46 <vtnerd_> it is new code, your modifying it, and the changes I requested of rbrunner are so damned easy
20:37:25 <vtnerd_> as-in, it was just modified to accept a `Transform` parameter, etc., already
20:39:27 <moneromooo> I'm just annoyed at some of the pedantry. I just move code around, I don't want to really get into modifying it beyond what's necessary.
20:39:47 <moneromooo> This really is its own PR. Don't mix it with the current one.
20:39:54 <vtnerd_> the code wasn't being processed by every log call though, it was tucked away in the wallet
20:40:35 <vtnerd_> which the rbrunner patch? my primary issue is understanding its purpose
20:40:35 <moneromooo> Sure. I'll check the profile to see if it shows up.
20:40:54 <moneromooo> I meant your comments on utf8canonical.
20:40:55 <vtnerd_> its not going to show up, we have death by 1000 cuts in this stuff
20:41:13 <vtnerd_> theres arbitrary copies all the time
20:41:47 <moneromooo> Then make a patch to remove some if it makes any difference. Piggy backing this on a PR that moves the code is just annoying.
20:41:48 <vtnerd_> I don't care too much, it will mostly be mitigated by the other check to skip the lock altogether at least
20:42:18 <moneromooo> Copies, here, not move, granted.
20:43:09 <moneromooo> I'll go and remove the copy later (which should be the vast majority of the time).
20:43:47 * moneromooo just has had enough yak shaving for now