Can anyone answer this? monero.stackexchange.com/questions/…e-rpc-access-data-method-daemon-rpc

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.

Ideally by not starting two RPC servers, but just having one listen on two ports.

running multiple walletrpcs is fine, right? is there a limit to how many you can run?

Yes. Only system limits.

great, ty

moneromooo: #6556 no required for branch?

ok looks like this is only fixes bad usage

so probably not

No, it's only a test thing, and it looks like memory layout makes it do the "right thing" in practice.

Any other opinion on 6554 ? Looks like a typical "perfect is the enemy of good" thing, but I may be biased.

woodser_: the "failed to die" errors you posted a while back are fine, I had them and understand why (and why it's fine).

ok cool

why are GUI builds so slapdash random? old.reddit.com/r/Monero/comments/gm…_for_linux_other_currencies/fr0qddz

one release "oh we didn't build with trezor support"

another "oh we didn't build with networking"

come on

because snipa did them and it was the first time he compiled then

we asked for testers on Reddit and they didn’t find these things

I can’t test everything :)

...networking ?

qt networking is only used for fiat price conversion

anyone who cares about it and can’t wait for the next release can compile themselves

Windows CI currently failing?

maybe, can you post logs?

they update the Windows image every 2 weeks and things randomly break

e.g. github.com/SarangNoether/monero/runs/686063757

^ current master

can you rerun?

if it still fails it is some msys2 issue that will probably solve itself after some time

Re-running now

Nope, still fails

sarang: msys2/MSYS2-packages #1960

delightful :D

#6543 #6545 #6551 #6554 need reviews / approvals

else we can’t tag

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?

tag needs everything merged

ty rbrunner two remaining

Yeah, with stuff way over my head :)

xiphon: would you be ok with 6554 for now and it can get improved later?

moneromooo: can 6550 be merged now that rbunner approved it?

(asking so that luigi can merge early so that rbunner can rebase)

selsta: commented on Github (i'm okay with 2/3 commits)

ty

I'll just make a little change to 6550, gimme a couple minutes.

6550 pushed (s/tolower/towlower/) but it'll be a bit before it's built it.

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?

*in my branch

Yes, since the commit is now slightly different, so you'd have to resolve a conflict.

Alright, thanks.

: 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

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?

It might be they cheat by delaying blocks a bit when sending to others. Some pools do that.

Well, it's not really cheating, just being a bit of an asshole.

Might be possible ...

Might be monerod's relay is being inefficient too, improvements welcome.

2 seconds seems a bit much for just inefficient.

From all I heard and read about supportxmr it would be something of a surprise to me that they should play unfair.

Could also be your link to that pool just goes through many network hops.

So you mean wrong config?

Or maybe you're wrong about the 2 second delay.

Nope tested it multiple times..

What do you think would be a normal delay?

50 ms?

Sounds fast. The noncesense people probably have that data. Or ways to get at it.

So no special monerod config....

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

Yes.

There's an option in moenerod which does this now, which kinda sucks but there was a reason for it IIRC.

The chain fits in ~25 GB though.

you can run monerod on like $5 VPS

Ok but if you need 30 of them per month

not in our budget

we are quite small

You don't need, you want.

As usual, pay more and get more performance.

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?

Block propagatoin might be worth going over, might be easy wins.

ah found it. --no-sync was added so that wallets can join to find public rpc nodes

Ah, yes. It makes sense for this use.

Though I guess it also means public rpc nodes make everything suck.

Sounds like wifi repeaters to me, daemons running with that option :)

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

each node has to verify PoW and transactions on the block, so block propagation is slowed down considerably compared to blind repeaters

Txes are usually verified already.

but PoW on a cheap VPS is easily 20+ ms delay

@moneromoo We need it because otherwise we can not compete that well....

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

See what I mean? If you place your nodes at the places where, on average, the most new blocks will pop up first?

But then of course you need a mechanism for them to "phone home" the news fast enough

@rbrunner understood but it s costly....

2, 3 nodes?

And I need the latest ryzen monster because otherwise I can't compile that well...

True

@rbrunner now?

lol

Anyway, I'll add "check block propagation for easy wins" in my list. But that'll be lowush priority.

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

xmrpow: maybe you could ask m5m for the address of one of his nodes and then --add-priority-node it?

@monermoo Miners currently dont care about network decentralization, so we have to get every plus point we can...

@asymp maybe an idea

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

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

Knife Scissor Paper Lizard Spock?

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

monerod logs received blocks, if that's what you're hinting at (net.p2p.msg).

rbrunner: can you reapprove 6551? :)

seems to compile

@sech1 im not into c and c++. So no option for me

@selsta, regarding 6551: Well, trying it again interactively in its updated version would be some work which I could not do today still.

ok np

ok maybe we can find a solution for #6554 until tomorrow :P

Guess I could go and find the max bytes that can be requested before and after.

xiphon: is your objection more about "it doesn't help that much" or "it breaks hypothetical spammy third party p2p code" ?

Or both.

moneromooo: the main objection is that we break the p2p protocol

what was allowed yesterday becomes forbidden tomorrow

OK, that's the thing I don't care about then ^_^

and we do this fo no good reason, but just beause it is" easir to implement the check the this way"

and it is not obivous that the check is necessary

do we have a PoC?

Oh it's not necessary. It just allows mitigating.

xnbya: do you have a PoC ?

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.

basically - is allowing 100 pre-v4 blocks per request a problem?

Depends on your definition of problem I guess.

and if it is, the next question - does limiting it to 20 pre-v4 blocks per request solves the problem?

yep, that's it

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.

Yes, I understand the argument, I just don't care about it.

There's probably no code that does it (except maybe spamming code).

Hmmm, yes, but such "probably's" tend to make me slightly uneasy. It's a complex system overall.

That makes me completely easy. I really do not give a shit about breaking third party code that's asking too much at once.

Just because a sanity check was high before should not be a reason to never make it stricter it it causes trouble.

I don't see the connection, my example is a call that gets exactly 2 blocks

Or maybe I misunderstand

No, you don't misunderstnad I think.

So you care about such a use being newly restricted then ?

Even though we never do it, and there's no evidence given anyone does ?

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 :)

Alright. Then since I said we needed a tie breaker, I'll remove it then.

(still sucks :P)

lol, the last two commits before the tag

had more discussions than all other in the last months

done

Alright, people, have to go, will be able to rebase my PR tomorrow morning UTC at the earliest

Just saw vtnerd's review comments about it. Not sure what to do with them all ...

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.

it is new code, your modifying it, and the changes I requested of rbrunner are so damned easy

as-in, it was just modified to accept a `Transform` parameter, etc., already

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.

This really is its own PR. Don't mix it with the current one.

the code wasn't being processed by every log call though, it was tucked away in the wallet

which the rbrunner patch? my primary issue is understanding its purpose

Sure. I'll check the profile to see if it shows up.

I meant your comments on utf8canonical.

its not going to show up, we have death by 1000 cuts in this stuff

theres arbitrary copies all the time

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.

I don't care too much, it will mostly be mitigated by the other check to skip the lock altogether at least

Copies, here, not move, granted.

I'll go and remove the copy later (which should be the vast majority of the time).