03:21:53 anyone have a better recommendation for a hardware wallet other than the trezor? 04:00:44 ledger 07:25:48 Hey guys, a newb here. Currently getting into Monero. Not expecting to gain a ton of $$ but would like to help out since it is FOSS. 07:25:57 Been watching Mental Outlaws videos on Monero. He reccomends using https://github.com/fireice-uk/xmr-stak/releases over the offcial software https://www.getmonero.org/ it seems. 07:26:10 What do you guys reccomend? Is the 1st one legit? 07:26:49 I do not think it's a trojan per se, but it's made by an asshole who's been trying to destroy monero for years. I do not recommend it. 07:27:27 AFAIK, at least some of his miners (maybe this one, not sure) lied about hash rate and connected to his site. 07:28:01 So I would trust that one only if you read the source and build it yourself, if you relaly want to use it. 07:28:41 On the other hand, xmrig is the most used miner, and having variety is good. Just... other variety wluld be much better. 07:29:02 getmonero.org stuff is good. 07:29:25 hehe I appreciate you input. What do most people around here recommend? 07:29:36 Also, xmr-stak hasn't been update in over 2 years 07:29:37 I'd use xmrig, as I said. 07:29:50 Or p2pool actually. 07:29:51 ahhh thank you. I can check out getmonero.org 07:30:21 Though you do need xmrig for that too. 07:30:27 the best is to download the GUI wallet and mine using p2pool (available from GUI wallet) 07:30:49 but xmrig will give you more hashrate 07:31:01 yeah, p2pool seems to be the right fit for me. Because of my business I am consistently on the move and can't leave dedicated machine on 24/7 07:34:31 Also, I would assume mining on a small VPS is not recommended due to high CPU usage and power. Plus I can imagine most VPS provider have policies against such a thing.....? 07:34:55 most VPS don't allow mining 07:35:25 but you can run monerod and p2pool nodes on a VPS 07:36:51 I see, I assume they are low power/low resource options to mine on VPS + help strengthen monero security....? 07:38:29 They do strengthen Monero security if you run them 07:38:40 but don't mine on VPS itself, just run the nodes there 07:38:52 you can connect xmrig to your p2pool node 07:38:59 and run xmrig on your PCs 07:39:19 Ahhhh I see. This is getting interesting 09:12:47 Hey I have some Q about running nodes. Came from BTC / Lightning to XMR, got sold on the concept. Now I am all in XMR. I had some nodes out there in the BTC ecosystem to contribute. Re-puporsed them to XMR now and I think I didn't do a good job. There are conflicting stories out there about some of the settings. What I am observing is: 09:13:04 1) 2022-05-06 03:49:52.847 W There were 9 blocks in the last 60 minutes, there might be large hash rate changes, or we might be partitioned, cut off from the Monero network or under attack, or your computer's time is off. Or it could be just sheer bad luck. 09:13:30 Sometimes it was 30 blocks in 12 minutes or something too fast. Now its like this. Am I talking to fake peers and getting bullshit ? 09:14:26 You can do a quick check with a block explorer. If you also see there some unusual blocktimes your daemon is just warning you just in case 09:14:31 System clock is accurate. I think it ties into my other question... Some tutorials say we should pull a blocklist of bullshit nodes off github, other tutorials say use a directive to grab it via DNS, others say "Leave it alone it is no longer needed" 09:15:40 As far as I know the code is now so robust that it deals reasonably with those lying nodes without a need of an explicte blacklist 09:16:07 To do a test I stood up 3 nodes and added their .onion to each other and I also added sethforprivacy's two nodes .onion with add-peer and add-priority node and I observe tons of weirdness with the Tor bits 09:16:51 I constantly get "Unable to send transaction(s) to tor - no suitable outbound connections at height XYZ" even though I have a bunch of Tor peers connected. 09:17:34 Then it blacklists some nodes that "should" be legit, like sethforprivacy 09:17:35 2022-04-26 17:19:31.386 I Host sfpp2p7wnfjv3lrvfan4jmmkvhnbsbimpa3cqyuf7nt6zd24xhcqcsyd.onion unblocked. 09:17:35 2022-04-26 17:19:33.027 I Host sfpp2p2tlgpsjxygeknkkfq4ho5uco56zvp2whn7bz2v7xbyqoslofqd.onion unblocked. 09:17:35 2022-04-26 17:20:22.972 I Host sfpp2p7wnfjv3lrvfan4jmmkvhnbsbimpa3cqyuf7nt6zd24xhcqcsyd.onion blocked. 09:17:35 2022-04-26 17:21:15.654 W Unable to send transaction(s) to tor - no suitable outbound connections at height 2610502 09:19:35 When I check my node's Height it is the same I see on xmrchain and in my personal node on monero-gui so I think I can ignore those warnings but who knows lol. I want to support the ecosystem, not put nodes up that end up making us look bad. I think the Tor tx sending is especially troublesome when someone connects their wallet to my node and sends a transaction that ends up stuck 09:22:05 Are these config directives still a thing, and should be enabled: 09:22:34 enforce-dns-checkpointing and enable-dns-blocklist 09:22:57 and is it necessary to limit the number of Tor slots in tx-proxy= 09:23:59 I feel like I could just stop using tx-proxy altogether because I sufficiently shield users who connect via the node's .onion address and I do not care if it is known that the node itself has XMR involvement. It seems tx-proxy= is a bottleneck for my nodes 09:27:24 The docu says about enable-dns-blocklist "It is not recommended unless in emergency situations." But clearly I have some issues with my nodes blacklisting good nodes and freaking out 09:28:14 XMRpeasant: hashrate can fluctuate, seeing that message is nothing unusual 09:30:16 regarding tx-proxy, you can remove it if it causes issues 09:30:28 Cool so all I need to worry about then is tx-proxy "Unable to send transaction(s) to tor - no suitable outbound connections" and why the nodes are blacklisting good nodes 09:30:42 it seems to work fine for me when setting --add-priority-node but yes it's not perfect yet 09:31:01 I make my nodes p2p and RPC avaiable via clearnet and .onion. plenty of connections 09:31:18 and the nodes are connected to each other's .onion with 09:31:21 --add-priority-node 09:31:39 but yes, I'd remove it in your case 09:31:42 I thought this might fix the message about not having Tor connections, Node A would just tx to Node B 09:31:48 OK let me take it out 09:32:03 I still help people as they can connect their wallet via .onion and people can sync the chain via my .onions 09:32:20 I am doing 2 more nodes next weekend and want to get things right before I do. Not to inherit bad habits 09:32:55 so this ban-list off github. Is it still good practice or not ? I am banning sethforprivacy's .onion addresses - that cant be right LOL 09:32:58 add-priority-node=xwvz3ekocr3dkyxfkmgm2hvbpzx2ysqmaxgter7znnqrhoicygkfswid.onion:18083 09:33:13 that's what I have in my config with --tx-proxy 09:33:19 with a couple other .onion nodes 09:33:38 Yes my nodes have each other and 2 of seth's in there 09:33:55 but they ban seth and dont seem to use each other when theres a transaction. 09:33:58 ok, if you continue to have issues then remove tx-proxy 09:34:05 the bans have nothing to do with the ban list 09:34:20 the node can ban peers if they don't behave correctly, e.g. if they fail to reply correctly 09:34:36 I assumed the ban list is known fuckery and the automatic bans is when a node sends nonsense that doesnt match consensus ? 09:34:48 ah ok.. So the bans of these two might be Tor connectivity issues 09:35:01 it can have different reasons why a peer can get banned 09:35:08 I also manage 200Mbit/s of Tor nodes. I am starting to allow egress on 18080-18089 to help our cause 09:35:33 if you set log_level 2 it should say why, but that causes a lot of log spam 09:35:43 for now I'd just remove tx-proxy 09:35:48 yeah I tried that and my tiny brain exploded 09:36:09 haha tx-proxy gone and the .onion node you suggested is added now. lets see. 09:36:31 wait the .onion node doesn't make sense without tx-proxy 09:37:04 add-priority-node=snhurdf2egwjgdxchwgjrzehcfnruob2nqqqo7wzluukms55elf4kaqd.onion:18083 09:37:22 add-priority-node=4pixvbejrvihnkxmduo2agsnmc3rrulrqc7s3cbwwrep6h6hrzsibeqd.onion:18083 09:37:37 you can add all these 3 and together with tx-proxy and check if you continue to have issues 09:37:45 if yes remove tx-proxy and all onion priority nodes 09:37:48 hope that makes sense :D 09:37:50 oh I thought you can still maintain connections to .onion even if you dont use tx-proxy. If a node doesnt allow clearnet (behind CGNAT or something) 09:38:07 Yes perfectly clear. Thanks. I will try both 09:38:54 plenty of traffic so I think my nodes are helping sync 09:39:32 just the stuck tx are a user experience issue. I demo XMR to show the benefits and the tx is stuck during my demo... yikes :) 09:40:08 yes, I know that issue :P but I solved it after adding the priority nodes 09:40:28 one more thing, you should add `tx-proxy=tor,127.0.0.1:9050,disable_noise` 09:40:36 see the disable_noise option 09:44:04 ok so do not limit number of slots but do disable noise. got it 09:44:35 yes, that might also help with the message you saw and it will also mean that transactions show up instantly in the mempool 09:44:45 I only had 5 priority nodes, myself and sethforprivacy, maybe it wasnt enough to ensure something is available. Added the 3 you suggested now 09:45:02 I have 3 only 09:45:06 2 even 09:45:48 privacy wise it is from worst to best: clearnet -> tx_proxy with disable_noise -> tx_proxy 09:46:47 Last Q: The RPC port I have it on 18081 but I saw somewhere that theres a convention now to have public services on 10809. I have set restricted-rpc=1 there. But I want to play around with full RPC. Can I have a second section in the config and open an unrestricted RPC port on a wireguard IP or localhost only, and still offer public, restricted on another port ? Docu suggests it could work 09:48:02 I would want full RPC on 127.0.0.1:18081 and restricted on 0.0.0.0:18089, should work, right ? 09:48:29 --rpc-restricted-bind-ip, --rpc-restricted-bind-port, --rpc-bind-ip, --rpc-bind-port 09:48:33 it should work, yes 09:49:27 Awesome. I will play around with that. 09:49:40 Just happened again 2022-05-06 09:47:00.864 W Unable to send transaction(s) to tor - no suitable outbound connections at height 2617452 09:49:54 i will remove tx-proxy and prio nodes for now. 09:50:23 oh wait. I didnt restart after disable_noise. 09:50:56 yes, try with restart 09:51:29 I have also started --tx-proxy with disable noise and no priority nodes on one node now and I'm waiting to see if that message shows up 09:52:13 User experience is everything 09:53:40 how do wallets find nodes to use btw ? Is it all hardcoded or is it polling something like https://monero.fail/ 09:54:29 the GUI currently uses a p2p node scanner that checks if nodes have --public-node but that will be replaced with a hardcoded list 09:54:37 too many issues with people setting up malicious nodes and spy nodes 09:54:55 other wallets also use a list of predefined nodes 09:55:01 CLI requires you to set your own node 10:01:36 Right. This is very similar to what we experience in Tor security. Same concept. Same fuckery. 10:02:30 This is why I also try put up XMR nodes in places OTHER THAN OVH/Hetzner/BuyVM - Those ASN have plenty of market share. We need ASN diversity and nodes in good hands to balance the crap 10:04:19 If IPv6-only were a thing I could stand up nodes on a dedicated ASN. I just dont have IPv4 /24s on hand that can be burned. And Tor still requires Ipv4. Can clearnet monerod be IPv6-only ? 10:11:08 No stuck transactions yet, tx-proxy on, no connection limit, disable_noise on. And a few priority nodes added. Looking better now! Thanks! 11:00:23 There are no IPV6 seed nodes, but I think it should work on IPv6 only if you give it a (non malicious) node manually on first start. 11:00:47 There is a --p2p-ignore-ipv4 to ignore error setting up ipv4, which implies it works without it. 11:03:38 In fact my seed node runs on both IPv4 and IPv6, I guess I could add its IPv6. I have no clue about IPv6 though, so I could not fix any network issue with it. 11:38:09 I am so happy to see no more stuff stuck. tx-proxy=tor,127.0.0.1:9050,disable_noise and a couple mroe priority nodes added seemed to make a huge difference. Nice! 11:43:27 XMRpeasant: from what I can tell `disable_noise` does the trick, the priority nodes aren't necessary but also don't hurt 14:54:52 selsta: 5 hours now, not a single tx fail due to Tor: Height: 2617599/2617599 (100.0%) on mainnet, not mining, net hash 2.92 GH/s, v14, 128(out)+79(in) connections, uptime 0d 5h 2m 36s 15:50:46 yep seems to be a bug or side effect from noise