<agentpatience> guys, how do i solo mine monero on my server without the GUI, the GUI is very slow?

<agentpatience> i want to use xmrig, it offers much faster speed?

<agentpatience> perhaps i need to leave my node open vi CLI and mine with xmrig, but I am uncertain of the instructions?

Wrong channel, try #monero-pools.

<agentpatience> IDunk, sorry.

<agentpatience> It might be a developer question as I can only attain half the rate of xmrig?

Well, if you're offering to speed up the monerod miner, sure, it is.

Double check the licence allows.

Also, keep an eye for bang for the buck. 1% speed increase for massive amounts of changes if not worth it.

<agentpatience> Moneromoo -- why do I experience half the hashrate within the Monero wallet GUI is there anything I can do to improve it I really want to use Moneros official software to mine on the node?

I suggested a couple things in #monero.

<agentpatience> I think it is a developer question still.

<agentpatience> moneromooo I thought was the expert in Monero.

Will the ban list for bad nodes be updated regularly and if so how will those updates be known so people can add the new list?

viperperidot[m], the strategies seem to be changing. im not aware of a way to identify new IPs .

Ok thanks I will stay tuned for any updates

target height > daemon height issue on fully synced nodes is back on v0.17.1.5

Height: 2242573/2242573 (100.0%) on mainnet, not mining, net hash 1.62 GH/s, v14, 64(out)+70(in) connections, uptime 4d 16h 35m 7s

looks fine on my node (0.17.1.5)

I use ban list though

yes, nodes have to apply the ban list when someone wants to transact with GUI

CLI and Feather are fine afaik

why would it affect only the GUI?

Lyza: programming oversight in libwallet

tobtoht: Any idea why this 'attack' is suddenly disruptive? I thought the recent releases included mitigations to curb it

Was the GUI supposed to 'reset' on the latest update?

Because I did the update and when I launched it opened the Welcome screen as if I had not run the app before

Are you using a hardware wallet?

and all my settings were reset

Now it will not connect to my remote node

<dEBRUYNE "Are you using a hardware wallet?"> Yes

cc selsta, xiphon

The weird thing is that I can connect to my node on other wallets but the Monero GUI is not connecting for some reason..

Do you use the --ban-list flag on your node?

Yes

Odd, can you check if it still works with .4?

It was working with .4 before I updated

viperperidot[m]: have a look at the proxy setting (Settings -> Interface tab)

Also nothing is showing up in the log for some reason

<xiphon "viperperidot: have a look at the"> Oh do I need to enable Socks5 proxy?

If so that must have got unchecked in the 'reset' and I forgot

"Oh do I need to enable Socks5 proxy?" -> yep, if you want to connect to remote node through socks

what OS do you use?

Ubuntu

Im not sure if I used this setting before or not

But I had my remote node connection working

Which IP and port am I entering into this field?

Sounds like you don't need a proxy

Is your remote note accessbile on the clearnet?

Its on the same network as me - LAN

No need for proxy then, disable the setting

So not accessible to the public but it is on clearnet not Tor

Ok

check whether the GUI is able to connect to some public remote node, for example, to node.xmr.to:18081

What the heck it is able to connect to that node

But I have a different wallet connected to my node using the same credentials....

Raise log level (Settings -> Log tab)

might shed some light on the issue

I checked log level 4 and nothing showed up

But I will check again

weird, but anyway, have a look at the log file

What he heck!!

Now it is connecting to my node

Still nothing in log level4 though.....

hm, did you download the gui from getmonero.org?

Yes

And verified signature

do you use portable mode?

I did not select portable mode

When I type status in the log it says

[2020-12-01 10:57 A.M.] 2020-12-01 17:57:25.295 I Monero 'Oxygen Orion' (v0.17.1.5-release)

Error: Couldn't connect to daemon: 127.0.0.1:18081

Even though the remote daemon is connected and syncing

yep, it tries to connect to local node

it doesn't work with remote nodes (yet?)

mean the particual error is expected

Wait it appears that the Wallet blocks remaining is not progressing

So maybe the GUI just hasn't updated from when I was connected to xmr.to

And I actually am not connected to my node..

Yes it doesn't look like anything is actually happening so I dont know that I am actually connected

do you use ipv4 address?

did you set the port correctly?

Yes port is correct, I am not sure about ipv4 but I had my node connected to the Monero GUI previously.

Same exact credentials that I have working in another wallet

I restarted the GUI and it looks like it was just stuck from previous node

Not connecting again

Log level 4 is empty

"I am not sure about ipv4"

do you use a hostname?

No I enter the IP address given to the node device on my network

"I restarted the GUI and it looks like it was just stuck from previous node" -> so after restart you have node.xmr.to in the remote node address field?

No I have my local node entered

"Log level 4 is empty" -> even the gui log file?

But the connection to xmr.to worked and when I switched back to my local node it appeared like it was still connected but it wasn't

If you select local node on one machine you can’t also select local mode on the other machine to connect to the same node.

OK one sec I opened up the actual monero GUI log file instead of looking in the App

Lyza: "why would it affect only the GUI?" -> it should affect all the wallet implementations, cause they use the same libwallet library internally

dEBRUYNE: "tobtoht: Any idea why this 'attack' is suddenly disruptive? I thought the recent releases included mitigations to curb it"

^ just Monero GUI Simple mode mitigations and Dandelion-related change

v0.17.1.3 had peer list fixes that fixed it previously

"fixed it" as in it didn’t show up previously

with the exception of the CLI (uses wallet2 directly), wallets that use woodser's c++ library (idem dito) and Feather (uses libwallet, but patches in a fix)

xiphon: I'm looking into it. It had appeared the target height issue was fixed in v0.17.1.3, but none of the commits suggest that it was.

it was never fixed

Ok sorry everyone but here is what happened - I check the Monero GUI log file and it was saying that there was an incorrect username and password for the RPC...So I went back and I copied and pasted the RPC info directly from the other wallet that was connected to my node. It is now connected but just to be sure I compared the RPC info from the other wallet to the RPC info in my password manager (where I was

originally copying and pasteing from) and they are identical!! So I do not know why this was happening. But sorry about this, next time I will just open up the log directly to do some more digging myself.

"^ just Monero GUI Simple mode mitigations and Dandelion-related chang"

^ ... the core still don't drop the peers claiming higher height and not returning the blocks upon request

something like monero-project/monero #6944

this issue threw me off monero-project/monero #7029

<xiphon> it was never fixed <= Guess we need another release then

xiphon: Would 6944 have fixed the issue?

yep, we would need another release

maybe we will come with better solution

IMO adding a timeout is "good enough" for now

with some better solution in a further release

yeah

nodes that applied the ban list are starting to run into the target height issue again

using the most recent list from gui.xmr.pm/files/block.txt

do you have one of these nodes?

it is possible that he spun up new IPs

all of my nodes are fine with block list

if you know someone who has this issue please ask them to run `sync_info` and send you the output

yes it's a new IP, one moment

I have more IPs that are not included in block.txt because I want to avoid false positives

178.62.116.193

do you have a sync_info output?

thanks, updated the list

Hello everyone. This is not easy for me but here I am. When I first started studying programming I was told that most of it is because we never give up and some good luck helped us reach the goal. I'm not here to sermon or change anyone's way of thinking. I've seen how people are shut and I personally don't like it, that hurts and hurt people do

bad things. No drama, I'll pay the price, I myself got into this situation. We'll keep coming here as always.

Thank you for your reading and time.

<agentpatience> We all suffer our own demise.

<agentpatience> Since I have been a systems engineer I have become fat and ugly but I am paid well.

talk a walk each day and stop eating so much

good to know you're watching :)

I'm having a ton of hosts get blocked from 185.220.101.* and 185.220.100.*

does the block list or the ban command work on entire subdomains, cidr notation or smth?

Some asshole is sending bad data through tor, you're banning the exit nodes.

AFAIK no.

ah crap

I see

Sorry, ban does work with CIDR. Block list AFAIK does not.

got it ty. if they're tor exit nodes though I don't really want to do that anyway I guess

on another note somebody mentioned another point release. if we're lining one up, can I draw attention to #7010 and especially #7017? I thought they were gonna end up in the last point release

#7017 is a big deal for tor / i2p anonymity imo

#7010 still has not been reviewed by anyone

obviously I think it's fine to go in, I've been running it for over a month

done

.merge+ 6948 7010

Added

7017 needs a review from someone else

Looks good, approved.

vtnerd: please also PR 7017 against release branch

.merges

moneromooo: please rebase 6874

not rebase but update to put the seed in the correct location

oh wait, forget what I wrote, we have to merge 6984 first. sorry

.merge+ 6984

Added