00:00:05 <ForeverNoob[m]> I knew it! :p
00:00:14 <anchor[m]> well actually Artix
00:00:32 <anchor[m]> It's surprisingly stable though
00:00:49 <anchor[m]> anyway back on topic, let me check the downloads myself
00:02:25 <ForeverNoob[m]> yeah if I install Arch then it's going to be Artix, but I'm now looking into Alpine myself
00:03:22 <anchor[m]> that's funny. The appimage just contains a single line pointing to the binary right next to it
00:03:45 * anchor[m] uploaded an image: image.png (1KiB) < https://matrix.org/_matrix/media/r0/download/200acres.org/wKVoxefPoWiEEscExRuGdJSJ/image.png >
00:03:57 <anchor[m]> that's not how I remember AppImages...
00:04:07 <ForeverNoob[m]> now that you mention it yeah
00:04:24 <anchor[m]> haha what's the point
00:04:50 <ForeverNoob[m]> I guess the point is to point to the binary :D
00:04:58 <anchor[m]> one point for you :^)
02:39:25 <QuickBASIC> Has anyone had Minko eat a bet recently?
04:14:36 <viperperidot[m]> 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?
04:14:46 <viperperidot[m]> Is this related to the ongoing attacks and it not fixes with the latest release?
04:14:59 <viperperidot[m]> This seems different than before when it was always 2 blocks behind
04:15:24 <viperperidot[m]>  * Is this related to the ongoing attacks and it not fixed with the latest release?
04:15:31 <selsta> does not sound related
04:15:47 <selsta> can you post the output of "sync_info" ?
04:19:58 <viperperidot[m]> 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.
04:21:55 <selsta> wait, how do you know your target height?
04:22:15 <selsta> if you are synced it is normal that the target height is lower than your sync height
04:22:28 <selsta> it has no meaning if you are synced
04:23:55 <viperperidot[m]> 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?
04:24:46 <viperperidot[m]> Current sync height for me right now is 2251016
04:26:04 <viperperidot[m]> Looks like that is fully synced
04:26:10 <viperperidot[m]> So maybe I am ok?
04:31:24 <selsta> yes everything is okay
04:31:49 <selsta> in a future version we will make sure that target height is 0 when synced
04:34:49 <viperperidot[m]> Hmm ok sorry for my confusion
04:38:42 <viperperidot[m]> Thanks
10:29:22 <beoleg> Hello guys
10:29:29 <beoleg> what to do with monero orion oxygen
10:29:32 <anchor[m]> Hi
10:29:34 <beoleg> falls several blocks behind?
10:29:47 <anchor[m]> 1 sec
10:29:53 <Inge-> beoleg: add banlist?
10:30:00 <beoleg> {'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':
10:30:01 <beoleg> 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',
10:30:01 <beoleg> '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,
10:30:02 <beoleg> 'wide_cumulative_difficulty': '0x1179ae4ef876633', 'wide_difficulty': '0x2ce933a30a'}
10:30:08 <beoleg> I think we have it
10:30:26 <beoleg> how do I check?
10:30:30 <beoleg> I am not the main developer
10:30:36 <beoleg> just trying to help on the weekend :)
10:30:43 <anchor[m]> first make sure you're on 0.17.1.6, also add the ban list from https://gui.xmr.pm/files/block.txt
10:30:44 <beoleg> googline...
10:31:03 <anchor[m]> download it and run the daemon with --ban-list=/path/to/block.txt
10:31:11 <beoleg> we are on 17.1.5
10:31:15 <beoleg> is that a big difference?
10:31:18 <anchor[m]> Yes
10:31:31 <anchor[m]> .6 contains several mitigations to ignore misbehaving nodes
10:32:06 <anchor[m]> monero devs urge everyone to update
10:32:39 <sech1> the correct command line is --ban-list block.txt
10:32:46 <sech1> assuming it's in the same directory
10:33:03 <sech1> or --ban-list /path/to/block.txt
10:33:07 <sech1> if it's somewhere else
10:33:16 <anchor[m]> works with an equals sign too
10:33:49 <sech1> that's good
10:34:45 <beoleg> on startup?
10:34:49 <beoleg> ok will check
10:34:53 <beoleg> we run insdie a docker
10:35:21 <anchor[m]> Yes, on startup. I don't have much Docker experience though
10:37:48 <beoleg> can I have the new ban list again just in case
10:37:55 <beoleg> we have something but I will update it
10:37:59 <beoleg> thanks
10:38:05 <anchor[m]> You can always grab it from https://gui.xmr.pm/files/block.txt
10:38:14 <sech1> yes, that list gets updates frequently
10:44:23 <p0nziph0ne> anchor[m]: what makes the nodes in the banlist evil?
10:44:41 <anchor[m]> They are controlled by a certain individual who has been attacking the monero network for the past few months
10:45:25 <anchor[m]> by executing Sybil and Eclipse attacks, constantly pretending the real tip of the blockchain is 2 blocks away from you
10:45:49 <kayront> http://27blltx6kt26k65umbs2tme6rhv4i7rhagnzzljp3bsoqfkj6w364sqd.onion/an-intriguing-feeling.html
10:47:09 <beoleg> ok strange
10:47:16 <beoleg> well my ban list had 126 entries
10:47:19 <beoleg> the new one
10:47:27 <beoleg> has 143
10:47:30 <beoleg> so I have replace them
10:48:19 <beoleg> in my case config-monerod.conf
10:48:26 <anchor[m]> 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
10:48:51 <beoleg> indicated a ban-list
10:48:52 <beoleg> param
10:48:55 <beoleg> with a path
10:48:57 <anchor[m]> said individual is very presistent
10:49:03 <beoleg> is it sufficient?
10:49:10 <anchor[m]> Yes, should be good
10:49:15 <beoleg> thanks for your help guys hope it helps
10:49:18 <anchor[m]> Yep
10:52:42 <beoleg> {'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':
10:52:42 <beoleg> 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',
10:52:43 <beoleg> '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':
10:52:43 <beoleg> '0x1179d006a487fe5', 'wide_difficulty': '0x2d5ea04559'}
10:52:46 <beoleg> so
10:52:50 <beoleg> now target height is 0
10:52:51 <beoleg> interesting
10:53:20 <beoleg> is this normal?
11:00:24 <sech1> I think target height is filled only when you're syncing with the network
11:17:27 <shabash> is there something like xmr.to for ethereum
11:17:29 <shabash> ?
11:23:16 <Inge-> morphtoken
11:47:10 <beoleg> Ok so updating the ban list fixed the issue
11:47:15 <beoleg> but only temporarily
11:49:09 <beoleg> {'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':
11:49:10 <beoleg> 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',
11:49:10 <beoleg> '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':
11:49:11 <beoleg> '0x117a2836c597ba2', 'wide_difficulty': '0x2d71311679'}
11:49:13 <beoleg> what could this mean?
11:49:17 <beoleg> thanks in advance :)
11:49:50 <beoleg> @sench1
11:49:55 <beoleg> sench1
11:49:57 <selsta> which issue?
11:50:03 <beoleg> sech1
11:50:17 <beoleg> we have the following checks in the code to make sure that it is synced
11:50:20 <beoleg> makes sense?
11:50:57 <selsta> target height is a sync variable, it is undefined if you are synced
11:51:37 <beoleg>                 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
11:51:50 <beoleg> ```
11:51:51 <beoleg>                 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
11:51:54 <beoleg> ```                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
11:52:36 <beoleg> 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
11:53:20 <selsta> what exactly is the issue?
11:53:56 <beoleg> that the blocks are falling behind
11:54:07 <beoleg> and we cannot publish transactions
11:54:09 <beoleg> as a result of that
11:55:14 <beoleg> Hi
11:55:16 <beoleg> Sorry
11:55:19 <selsta> the status output you posted looks fine
11:55:35 <selsta> do you have access to the node?
11:56:27 <selsta> if yes post the output of "sync_info" to https://paste.debian.net
11:56:58 <beoleg> yeah
11:57:00 <beoleg> also 2251236
11:57:02 <beoleg> is our height
11:57:07 <beoleg> and on xmrchain it is only 2251235
11:57:16 <beoleg> doing thatnks
11:57:27 <selsta> xmrchain will always be 1 behind
11:57:48 <selsta> not sure why that is exactly but it is normal
11:58:47 <selsta> could be because xmrchain starts at height 0
11:58:49 <sech1> xmrchain show last mined block height. Current height is always last mined block height + 1
11:59:00 <selsta> ah makes sense
13:52:42 <anchor[m]> how do I get the 'click to pay' links on websites to work with the monero wallet?
13:54:56 <moneromooo> If you mean the monero:// scheme, you have to work out how your OS remembers associations.
13:55:16 <anchor[m]> So what's the command that should be associated with it?
13:55:19 <anchor[m]> I can figure the rest out myself
13:55:47 <anchor[m]> I use arch <del>btw</del>
13:55:49 <moneromooo> Drawing a blank. I remember looking at that before but I can't remember :D
13:55:57 <anchor[m]> Damn it
13:56:14 <anchor[m]> 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?)
13:57:38 <moneromooo> OK, I *think* this should work: monero-wallet-cli --wallet-file /path/to/your/wallet  transfer $URI
13:58:02 <moneromooo> You probably want to make sure you have set always-confirm-transfers to 1 first.
13:58:03 <Mochi102> anchor[m], https://monero.fandom.com/wiki/URI_formatting
13:58:06 <Mochi102> this?
14:00:07 <anchor[m]> moneromooo: I'll tinker with that and report back if it works. Any chance I can do this with monero-wallet-gui as well?
14:01:11 <anchor[m]> 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
14:04:18 <anchor[m]> It appears to work moneromooo thank you
14:04:47 <selsta> There was some work added to the GUI to support monero:
14:04:57 <selsta> not sure if it works
14:06:25 <anchor[m]> Could you elaborate? selsta
14:08:43 <rbrunner> The GUI wallet on Windows gets registered as a handler for "monero:" URL scheme, but only if you use the installer
14:08:44 <Quotes> fuck windows, use linux!
14:09:32 <selsta> https://github.com/monero-project/monero-gui/pull/2029
14:09:37 <anchor[m]> I am using Linux, and I know how to add handlers. I just don't know the command requried for the GUI wallet
14:09:52 <selsta> ok that is for monero://
14:28:17 <anchor[m]> I've got it working selsta  thank you
14:32:32 <hallucinogen[m]> Hi, i have downloaded the getmonero.org site from github, build a static version of it and copied it over to IPFS
14:32:32 <hallucinogen[m]> Are you interested? if so can i post the link here?
16:37:54 <Barbelo[m]> bros how big is the monero blockchain right now
16:38:22 <Barbelo[m]> i wanted to run my rasp pi as a node and i have 128 gb sd card in it
16:38:57 <selsta> 30GB pruned
16:39:01 <selsta> 100GB normal
16:39:26 <Barbelo[m]> can a pruned node be used as a public node?
16:40:28 <selsta> yes
16:41:03 <Barbelo[m]> awesome.  thanks for the info.
17:18:57 <Mochi102> Can a pruned node be used with RPC-Pay?
17:19:07 <moneromooo> Yes.
17:19:38 <Mochi102> 100% effectively?
17:19:49 <Mochi102> or are there downsides to having pruned it?
17:20:13 <moneromooo> Well, if you're asked for old txes, you might not have the full data for them.
17:28:47 <Mochi102> I see
19:14:09 <bobandback> Is the ongoing attack affecting remote nodes? I´ve been trying all day, can´t connect to a single remote node.
19:15:41 <bobandback> Always Node connection failed, check username/password.
19:20:05 <bobandback> 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
19:20:19 <bobandback> That doesn´t seem right, maybe my wallet is corrupted?
19:29:04 <Mochi102> bobandback, try node.xmr.to or node.supportxmr.com
19:32:03 <selsta> bobandback: which wallet are you using?
19:38:24 <bobandback> Monerujo, i think i fixed it by removing the wallet file but not the keys file.
19:38:31 <bobandback> It´s now connected and syncing.
19:46:57 <bobandback> 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.
19:47:06 <bobandback> I used the info provided on moneroworld
19:48:36 <bobandback> --restricted-rpc --rpc-bind-ip 192.168.0.13 --confirm-external-bind --public-node
19:49:23 <bobandback> 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.
19:50:11 <bobandback> log says: Error: Unsuccessful - json_rpc_request;
19:52:07 <bobandback> 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.
20:08:26 <bobandback> 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.
21:01:38 <bobandback> Local connections are extremely slow, but using my public address it is much faster.
21:01:49 <bobandback> Sometimes i even have to retry local connections.