I knew it! :p

well actually Artix

It's surprisingly stable though

anyway back on topic, let me check the downloads myself

yeah if I install Arch then it's going to be Artix, but I'm now looking into Alpine myself

that's funny. The appimage just contains a single line pointing to the binary right next to it

that's not how I remember AppImages...

now that you mention it yeah

haha what's the point

I guess the point is to point to the binary :D

one point for you :^)

Has anyone had Minko eat a bet recently?

ever since upgrading to 17.1.6 my sync height has been at least a hundred blocks higher than my target block height, how is this possible?

Is this related to the ongoing attacks and it not fixes with the latest release?

This seems different than before when it was always 2 blocks behind

* Is this related to the ongoing attacks and it not fixed with the latest release?

does not sound related

can you post the output of "sync_info" ?

Hmm I am using a third party node software (pinodexmr) so I dont know how to enter the sync_info command right now, but there is a log page, not sure if this shows the information you need though. I am just asking the dev where I can input that command.

wait, how do you know your target height?

if you are synced it is normal that the target height is lower than your sync height

it has no meaning if you are synced

Oh really? I know the target height because it is one of the stats displayed on the pinodexmr, I would have thought the target height would always be equal or higher than your sync height. Isn't the target height the tip of the blockchain?

Current sync height for me right now is 2251016

Looks like that is fully synced

So maybe I am ok?

yes everything is okay

in a future version we will make sure that target height is 0 when synced

Hmm ok sorry for my confusion

Thanks

Hello guys

what to do with monero orion oxygen

Hi

falls several blocks behind?

1 sec

beoleg: add banlist?

{'adjusted_time': 1607855232, 'alt_blocks_count': 0, 'block_size_limit': 600000, 'block_size_median': 300000, 'block_weight_limit': 600000, 'block_weight_median': 300000, 'bootstrap_daemon_address': '', 'credits': 0, 'cumulative_difficulty': 78701826564122163, 'cumulative_difficulty_top64': 0, 'database_size': 102005473280, 'difficulty':

192891036426, 'difficulty_top64': 0, 'free_space': 18446744073709551615, 'grey_peerlist_size': 0, 'height': 2251190, 'height_without_bootstrap': 0, 'incoming_connections_count': 0, 'mainnet': True, 'nettype': 'mainnet', 'offline': False, 'outgoing_connections_count': 0, 'rpc_connections_count': 0, 'stagenet': False, 'start_time': 0, 'status': 'OK',

'target': 120, 'target_height': 2251192, 'testnet': False, 'top_block_hash': '7a19cabfac319a0ab98f18c5e6ce2f153766e68460afb8eb07d8134df71f64e5', 'top_hash': '', 'tx_count': 10282918, 'tx_pool_size': 38, 'untrusted': False, 'update_available': False, 'version': '', 'was_bootstrap_ever_used': False, 'white_peerlist_size': 0,

'wide_cumulative_difficulty': '0x1179ae4ef876633', 'wide_difficulty': '0x2ce933a30a'}

I think we have it

how do I check?

I am not the main developer

just trying to help on the weekend :)

first make sure you're on 0.17.1.6, also add the ban list from gui.xmr.pm/files/block.txt

googline...

download it and run the daemon with --ban-list=/path/to/block.txt

we are on 17.1.5

is that a big difference?

Yes

.6 contains several mitigations to ignore misbehaving nodes

monero devs urge everyone to update

the correct command line is --ban-list block.txt

assuming it's in the same directory

or --ban-list /path/to/block.txt

if it's somewhere else

works with an equals sign too

that's good

on startup?

ok will check

we run insdie a docker

Yes, on startup. I don't have much Docker experience though

can I have the new ban list again just in case

we have something but I will update it

thanks

You can always grab it from gui.xmr.pm/files/block.txt

yes, that list gets updates frequently

anchor[m]: what makes the nodes in the banlist evil?

They are controlled by a certain individual who has been attacking the monero network for the past few months

by executing Sybil and Eclipse attacks, constantly pretending the real tip of the blockchain is 2 blocks away from you

ok strange

well my ban list had 126 entries

the new one

has 143

so I have replace them

in my case config-monerod.conf

The new monero update (.6) has several methods of detecting misbehaving nodes, so the blocklist shouldn't be necessary. However I've still had to use it myself

indicated a ban-list

param

with a path

said individual is very presistent

is it sufficient?

Yes, should be good

thanks for your help guys hope it helps

Yep

{'adjusted_time': 1607856672, 'alt_blocks_count': 0, 'block_size_limit': 600000, 'block_size_median': 300000, 'block_weight_limit': 600000, 'block_weight_median': 300000, 'bootstrap_daemon_address': '', 'credits': 0, 'cumulative_difficulty': 78704143610970085, 'cumulative_difficulty_top64': 0, 'database_size': 102005473280, 'difficulty':

194861090137, 'difficulty_top64': 0, 'free_space': 18446744073709551615, 'grey_peerlist_size': 0, 'height': 2251202, 'height_without_bootstrap': 0, 'incoming_connections_count': 0, 'mainnet': True, 'nettype': 'mainnet', 'offline': False, 'outgoing_connections_count': 0, 'rpc_connections_count': 0, 'stagenet': False, 'start_time': 0, 'status': 'OK',

'target': 120, 'target_height': 0, 'testnet': False, 'top_block_hash': '221f5291b23a0714ae0303e037b484b09e2252d62d9d8dba6e26272eafa1e6b6', 'top_hash': '', 'tx_count': 10283159, 'tx_pool_size': 18, 'untrusted': False, 'update_available': False, 'version': '', 'was_bootstrap_ever_used': False, 'white_peerlist_size': 0, 'wide_cumulative_difficulty':

'0x1179d006a487fe5', 'wide_difficulty': '0x2d5ea04559'}

so

now target height is 0

interesting

is this normal?

I think target height is filled only when you're syncing with the network

is there something like xmr.to for ethereum

?

morphtoken

Ok so updating the ban list fixed the issue

but only temporarily

{'adjusted_time': 1607860001, 'alt_blocks_count': 0, 'block_size_limit': 600000, 'block_size_median': 300000, 'block_weight_limit': 600000, 'block_weight_median': 300000, 'bootstrap_daemon_address': '', 'credits': 0, 'cumulative_difficulty': 78710203844492194, 'cumulative_difficulty_top64': 0, 'database_size': 102005473280, 'difficulty':

195172570745, 'difficulty_top64': 0, 'free_space': 18446744073709551615, 'grey_peerlist_size': 0, 'height': 2251233, 'height_without_bootstrap': 0, 'incoming_connections_count': 0, 'mainnet': True, 'nettype': 'mainnet', 'offline': False, 'outgoing_connections_count': 0, 'rpc_connections_count': 0, 'stagenet': False, 'start_time': 0, 'status': 'OK',

'target': 120, 'target_height': 0, 'testnet': False, 'top_block_hash': '1c51720cb4c2974b3aaf736717565ef8535865ad3477182d39df9f0f96ba3ce8', 'top_hash': '', 'tx_count': 10283740, 'tx_pool_size': 28, 'untrusted': False, 'update_available': False, 'version': '', 'was_bootstrap_ever_used': False, 'white_peerlist_size': 0, 'wide_cumulative_difficulty':

'0x117a2836c597ba2', 'wide_difficulty': '0x2d71311679'}

what could this mean?

thanks in advance :)

@sench1

sench1

which issue?

sech1

we have the following checks in the code to make sure that it is synced

makes sense?

target height is a sync variable, it is undefined if you are synced

node_height = node.get('height') is_node_synced = node.get('target_height') <= node_height is_wallet_synced = wallet_block.get('height') == node_height return is_node_synced and is_wallet_synced

```

node_height = node.get('height') is_node_synced = node.get('target_height') <= node_height is_wallet_synced = wallet_block.get('height') == node_height return is_node_synced and is_wallet_synced

``` node_height = node.get('height') is_node_synced = node.get('target_height') <= node_height is_wallet_synced = wallet_block.get('height') == node_height return is_node_synced and is_wallet_synced

node_height = node.get('height')is_node_synced = node.get('target_height') <= node_heightis_wallet_synced = wallet_block.get('height') == node_heightreturn is_node_synced and is_wallet_synced

what exactly is the issue?

that the blocks are falling behind

and we cannot publish transactions

as a result of that

Hi

Sorry

the status output you posted looks fine

do you have access to the node?

if yes post the output of "sync_info" to paste.debian.net

yeah

also 2251236

is our height

and on xmrchain it is only 2251235

doing thatnks

xmrchain will always be 1 behind

not sure why that is exactly but it is normal

could be because xmrchain starts at height 0

xmrchain show last mined block height. Current height is always last mined block height + 1

ah makes sense

how do I get the 'click to pay' links on websites to work with the monero wallet?

If you mean the monero:// scheme, you have to work out how your OS remembers associations.

So what's the command that should be associated with it?

I can figure the rest out myself

I use arch <del>btw</del>

Drawing a blank. I remember looking at that before but I can't remember :D

Damn it

I can't find a thing about it online, closest thing I found was monero-wallet-rpc but that turned out to be unrelated (I think?)

OK, I *think* this should work: monero-wallet-cli --wallet-file /path/to/your/wallet transfer $URI

You probably want to make sure you have set always-confirm-transfers to 1 first.

anchor[m], monero.fandom.com/wiki/URI_formatting

this?

moneromooo: I'll tinker with that and report back if it works. Any chance I can do this with monero-wallet-gui as well?

If not, it might be a nice suggestion to be able to somehow send a URI to monero-wallet-gui and have it fill out the details in the send tab, so the user only has to confirm the transaction

It appears to work moneromooo thank you

There was some work added to the GUI to support monero:

not sure if it works

Could you elaborate? selsta

The GUI wallet on Windows gets registered as a handler for "monero:" URL scheme, but only if you use the installer

fuck windows, use linux!

I am using Linux, and I know how to add handlers. I just don't know the command requried for the GUI wallet

ok that is for monero://

I've got it working selsta thank you

Hi, i have downloaded the getmonero.org site from github, build a static version of it and copied it over to IPFS

Are you interested? if so can i post the link here?

bros how big is the monero blockchain right now

i wanted to run my rasp pi as a node and i have 128 gb sd card in it

30GB pruned

100GB normal

can a pruned node be used as a public node?

yes

awesome. thanks for the info.

Can a pruned node be used with RPC-Pay?

Yes.

100% effectively?

or are there downsides to having pruned it?

Well, if you're asked for old txes, you might not have the full data for them.

I see

Is the ongoing attack affecting remote nodes? I´ve been trying all day, can´t connect to a single remote node.

Always Node connection failed, check username/password.

I just tried my other wallet and it connects fine. If i go to Show Secrets, it says: Wallet.Status: (Status_Critical/std::bad_alloc, null

That doesn´t seem right, maybe my wallet is corrupted?

bobandback, try node.xmr.to or node.supportxmr.com

bobandback: which wallet are you using?

Monerujo, i think i fixed it by removing the wallet file but not the keys file.

It´s now connected and syncing.

I´m trying to speed up the process by using my local monero gui on pc, but when i run the commands to make it a public node the local GUI cannot connect to it and gives an rpc error.

I used the info provided on moneroworld

--restricted-rpc --rpc-bind-ip 192.168.0.13 --confirm-external-bind --public-node

i tested with monerujo and it connects and syncs. local gui also sees the daemon and syncs but after a minute or so it gives an error and stops syncing.

log says: Error: Unsuccessful - json_rpc_request;

popup error after a minute says: Daemon failed to start. Timed out, local node is not responding after 120 seconds. Please check wallet and deamon logs for errors.

When i run monerod like that from terminal GUI also doesn´t see it and wants to spawn its own instance. When i connect to remote node and select localhost it works fine though. Syncing is extreeeemely slow though, which quite opposite of what i wanted.

Local connections are extremely slow, but using my public address it is much faster.

Sometimes i even have to retry local connections.