00:03:50 https://unstoppableswap.net/ https://basicswapdex.com/ 00:10:32 Not true. Nioc is right 00:12:46 From btc <> xmr, probably unstoppabkeswaps. Its btc focused and has more liq on btc 00:14:09 What you want to do it type `sync_info` and have a look at what it shows. 00:14:10 It shows 1. peers that you are connected to 2. a line that says mooooooooo 3. blocks that are queued to be synced. 00:15:12 The top peer in the third section is probable a bad peer. You can `ban 152.169.161.37` to ban them and see if it proceeds 00:16:27 If youre truly stuck, `in_peers 0` then `out_peers 0` then `pop_blocks 1000` then restart monerod with `--add-exclusive-node=node.monerodevs.org:18080` 00:18:13 thanks im gonna try it. i did find some dirs of old blockchain that are around 199 GiB or 212 GiB or 200 GiB that I am trying to load into monerod and see which ones not corrupt 00:19:14 Okay, you know everything about monero 😅 00:20:12 Yea, manually ban then as ban list will save you time 00:20:29 Not really 00:20:31 how could i interact with a docker monerod process? and issue such a command 00:20:35 Banlist is a different set of nodes 00:20:58 ``` 00:21:00 docker exec -it monerod bash 00:21:02 OCI runtime exec failed: exec failed: unable to start container process: exec: "bash": executable file not found in $PATH: unknown 00:21:04 ``` 00:21:22 https://github.com/rblaine95/monero-banlist what does this consist of ? 00:21:28 1 of the reasons i stay away from docker 00:21:49 troubleshooting is difficult ag 00:21:55 s/ag/af 00:22:17 "not the node in question" 00:22:18 147.182.160.251 00:22:20 151.80.17.140 00:22:22 152.42.137.12 00:22:24 152.42.164.168 00:22:26 152.42.176.57 00:22:28 152.42.234.2 00:22:30 152.42.238.126 00:22:32 152.42.242.48 00:22:34 152.42.252.27 00:22:36 157.245.108.248 00:23:06 That is a mirror of the xmr.pm blocklists, which are also different than boog's list 00:24:57 Boogs list has proxy nodes ? are they causing sync issues or were they spying 00:26:36 The proxy nodes sync fine, they just spy on transactions 00:27:43 So which ban list is helps to keep out asshole nodes which cause sync issue ? 00:28:29 So which ban list helps to keep out asshole nodes which cause sync issue ? 00:28:30 none. Its hard to reproduce this 00:29:19 Okay, for most users I dealt with xmr.pm blocklist helped them and didn’t face any sync issue 00:29:20 You maybe unable to reproduce but it works 00:29:32 Using --proxy ive been pushed onto the wrong chain at a similar height, which seemed to be nodes that were targeting tor exit ips 00:30:25 Its hard to reproduce == it only happens very rarely. 99% of people sync w/o issue. Its the 1/100 that get cut off 00:30:36 Monerod auto corrects though? Or had to make any change 00:31:09 I the node sent me bad blocks and i had to reading the chain and sync from a good node 00:31:19 Yes 1/100th have their peerlist populated with these asshole nodes 00:31:31 It usually happens around 1.2-1.5m blockheight in my experience 00:31:55 Its not the banlist nodes... 00:32:13 Was there some fork around that height ? 00:32:17 Its some other entity, doing a random attack 00:33:06 I'm wondering if azizLIGHT was using tor? 00:34:21 i dont think so 00:35:14 im in the docker container using sh, but how do i send sync_info to the monerod process that is already running 00:35:52 its running with a --non-interactive switch 00:47:00 azizlight in the past, i've had to use completely different docker images, running shell alone (to stay running), where i could start the process myself in order to debug it 00:47:18 tl;dr -- docker complicates things 00:48:01 i see, so i would have to stop the running monerod process in the docker right now, and then run it in the docker container shell manually with the same switches except non-interactive, then issue sync_info 00:48:28 but before i stop the monerdo process, its currently running "pruning blockchain" is this omething that i can stop/start/resume and not lose time 00:48:55 if your storage is persistent, you won't lose time 00:49:20 i'm not of anywhere during sync where it cannot be force quit & not resume well later on 00:49:58 well i mean will it have to restart pruning from the beginning or something instead of resuming whereever it is right now... its been doing it for a while 00:51:03 i dont think it will start over. i doubt it's doing anything significant in memory alone 01:00:25 ./monerod sync_info 01:01:32 i think the process is nonresponsive when pruning blockchain? 01:01:34 ``` 01:01:36 ~ $ monerod status 01:01:38 2025-02-10 00:54:06.842 I Monero 'Fluorine Fermi' (v0.18.3.4-release) 01:01:40 Error: Couldn't connect to daemon: 127.0.0.1:18081 01:01:42 ~ $ curl http://localhost:18089/get_info 01:01:44 curl: (7) Failed to connect to localhost port 18089 after 0 ms: Could not connect to server 01:01:46 ~ $ monerod sync_info 01:01:48 2025-02-10 01:00:46.514 I Monero 'Fluorine Fermi' (v0.18.3.4-release) 01:01:50 Error: Couldn't connect to daemon: 127.0.0.1:18081 01:01:52 ~ $ 01:02:01 How are you pruning? 01:02:22 oh this is nice. " [WARNING] Trezor support cannot be compiled! Skipping Trezor compilation" thanks whoever did that 01:03:01 docker compose up -d on a docker-compose.yaml file that ran 01:03:02 ``` 01:03:04 version: '3' 01:03:06 services: 01:03:08 monerod: 01:03:10 image: ghcr.io/sethforprivacy/simple-monerod:latest 01:03:12 user: ${FIXUID:-1000}:${FIXGID:-1000} 01:03:14 restart: unless-stopped 01:03:16 container_name: monerod 01:03:18 volumes: 01:03:20 - /mnt/pve-raid1/docker/monerod/data/.bitmonero:/home/monero/.bitmonero 01:03:31 Using an old/unpruned blockchain? 01:03:32 docker compose up -d on a docker-compose.yml file that ran 01:03:34 ``` 01:03:36 version: '3' 01:03:38 services: 01:03:40 monerod: 01:03:42 image: ghcr.io/sethforprivacy/simple-monerod:latest 01:03:44 user: ${FIXUID:-1000}:${FIXGID:-1000} 01:03:46 restart: unless-stopped 01:03:48 container_name: monerod 01:03:50 volumes: 01:03:52 - /mnt/pve-raid1/docker/monerod/data/.bitmonero:/home/monero/.bitmonero 01:04:57 its a .bitmonero dir thats 200GiB i saved after a safe closure of monerod process, that i just placed as .bitmonero (replacing the old one) 01:04:57 gingeropolous: hasn't it been like that for a long time? 01:05:06 requires more effort 01:05:11 in hopes that it speeds up blockchain download 01:05:33 probably. it was just so frustrating before, im happy every time i see it i guess 01:07:15 so im just not sure if this is working because theres no info on the log besides pruning blockchain 01:07:59 ``` 01:08:00 2025-02-09 22:51:00.600 I Cryptonote protocol stopped successfully 01:08:02 2025-02-10 00:14:59.880 I Monero 'Fluorine Fermi' (v0.18.3.4-release) 01:08:04 2025-02-10 00:14:59.880 I Initializing cryptonote protocol... 01:08:06 2025-02-10 00:14:59.880 I Cryptonote protocol initialized OK 01:08:08 2025-02-10 00:14:59.881 I Initializing core... 01:08:10 2025-02-10 00:14:59.882 I Loading blockchain from folder /home/monero/.bitmonero/lmdb ... 01:08:12 2025-02-10 00:15:17.560 E Underflow in txpool weight 01:08:14 2025-02-10 00:15:17.561 E failed to find transaction input in key images. img= 01:08:16 2025-02-10 00:15:17.561 E transaction id = 01:08:18 2025-02-10 00:15:17.562 E Underflow in txpool weight 01:09:15 the 200 GiB .bitmonero dir isnt completely synced, just to be clear 01:09:16 That log isn't pretty 01:10:05 Btw, when you post logs, try to use a paste site like paste.debian.net or www.zerobin.net 01:10:26 (it spams the irc side) 01:10:47 oh im sorry 01:11:33 hrm, sigbus error 01:11:52 Ive dont recall pruning a full chain to print those errors. Are you sure the original blockchain isnt corrupt? 01:12:11 Ginger, what sort of wild setup are you running? 01:12:38 Ive buit Monero like 18 times over tge past few days and running test prs 01:18:48 i stopped monerod, got rid of the 200 GiB .bitmonero dir, and restored my other .bitmonero dir (the one that was stuck synchronizing and not updating the block number 1492064, and now its working. its syncing 01:19:57 so is it not advisable to save .bitmonero snapshots (after a monerod shutdown), for the purposes of having a non corrupt blockchain at a certain time 01:20:39 Wdym? Why not? 01:20:51 by .bitmonero snapshot i mean, stopping monerod, copying the noncorrupted .bitmonero dir somewhere for safekeeping, and then when an actual corruption occurs, to restore the saved one into the dir 01:21:11 That should work 01:21:32 then was the .bitmonero 200 GiB dir i saved already corrupted? is that why it was stuck pruning 01:22:36 azizlight if you view `top`, is monerod still processing? 01:23:14 i didnt bother continuing with the pruning because of nonindication of status, and not responding to ./monerod status or ./monerod sync_info commands 01:23:20 so i killed it 01:23:58 right now im just using a relatively new .bitmonero dir i started a bout a day ago, and its syncing normally with --prune-blockchain switch 01:24:50 i had stopped this one because it had gotten stuck synchronizing and i got frustrated because the number didnt increase 01:34:28 Yeah probably just bad peerq 01:44:41 so now that i can actually run sync_info and get a response. wrt to this statement, are you saying that i should set in_peers to 0 and out_peers to 0? and pop_blocks to 1000, and then restart with the add-exclusive-node switch 01:45:20 or thats the condition in which i should do pop_blocks to 1000 and add exclusive node, that when in_peers and out_peers are both 0, then do that 01:51:50 ofrnxmr ^ 01:54:05 If youre stuck, the disabling peers and poppibg blocks before restarting with a good node, is a solution 01:54:15 Youre syncing fine now, so no need 01:55:12 The second section of sync_info should say `mooooooooooooooo` . The mooo implies that everything is working ok 01:55:20 i do see it 02:07:05 🔥💨 Telegram Menu: Exclusive Premium Selections 02:07:06 https://t.me/+tb_L9H0WVVU1NWNk 02:07:08 🍃🌈 Flower & Mushrooms 02:07:10 • ⚪ White 02:07:12 • 💎 Molly 02:07:14 • 🌿 Flower (🔥 Premium Strains) 02:07:16 • 🍄 Mushrooms (Raw & Bars): 02:07:18 • 🍫 Bobby Bars: 4-mushroom blend by Big Thraxington 02:07:20 • 👻 Spooky Bars: 🎨 Dabman collab (✨ limited edition) 02:07:22 • 🚪 Golden Doors: Forbes #8 (2023 Top 10) 02:07:24 🧪🌌 Psychedelics 03:24:53 <321bob321:monero.social> Thanka mbll 03:55:09 oh, maybe its just a corrupted mdb file... 03:55:36 <0xchr1s:matrix.org> Anyone have any insight into why I receive this message? 03:55:38 <0xchr1s:matrix.org> `2025-02-10 02:00:55.061 W Invalid DNSSEC TXT record signature for updates.moneropulse.no: validation failure : covering NSEC3 was not opt-out in an opt-out DS NOERROR/NODATA case from 127.0.0.53 for DS moneropulse.no. while building chain of trust` 07:45:22 funny how people comes in here to sell their products of marijuana..... seems scammy like 08:23:06 The ones with some random telegram link? Probably 08:23:32 Then idk where to buy such and i dont care to find out 11:08:34 https://discuss.privacyguides.net/t/recommend-kraken-pro-specifically/24826 11:09:58 what were yoy guys experience when using Kraken Pro whether buying low fees coin to swap with real coin (Monero) or just buying Monero direcly (not that private) 11:10:15 what were your experience when using Kraken Pro whether buying low fees coin to swap with real coin (Monero) or just buying Monero direcly (not that private) 11:10:27 directly* 11:21:09 Good, low fees. No complaints. Afaik Pro comes with extra KYC and business accounts are also Pro. I use it for my business. 11:40:39 KYC questionnaire, which I'm sure u can fill it with anything, right? 11:43:27 We needed to submit full-KYC for every single board member as well as company registration documents 11:49:08 interesting, so this is probably the same case for individuals 12:19:42 IIRC Kraken Pro is available for individuals with "Pro Personal" account (ID verification + proof of address verification) 12:35:30 it is the same as intermediate (normal) account, right? 12:35:30 KYC is necessary in both cases 14:14:31 is Vthor here on the irc side ? 14:19:31 i need to talk to ask him about the xmrsigner project 14:23:34 yes he's here 14:29:37 i need to talk to him about the xmrsigner project 15:35:08 yes kevino 15:36:48 Can you see my dm 15:37:09 kevino: Nope, doesn't work over the bridge, but you can also write @vthor:nope.chat if you want 15:37:24 Is the issue with building xmrsigner fixed ? 15:37:33 I tried to compile it but had the same result as reported by somebody on GitHub. The `dev-device-install-requirements` command is not configured 15:38:24 Or if binaries were available for testing , i could test it out 15:40:29 No, haven't fixed it, because I'm will change in the comming days/weeks almost everything and the build will completely differ, and how I had not the perception that many build themselves, so I thought it will be better to prioritize first the the ongoing development. 15:41:10 Binaries should be there, but letme check - I don't rememeber where I dropped them, give me a moment. 15:41:16 Ohh i see 15:43:04 I am using pi zero 2w so don't know if you built it for them 15:45:16 will work also with pi zero 2w, tested it on both 15:45:23 curl -L -o Makefile https://github.com/DiosDelRayo/MoneroSigner/releases/download/v0.9/Makefile 15:45:25 make image 15:45:27 DEVICE= make flash 15:45:53 curl -L -o Makefile https://github.com/DiosDelRayo/MoneroSigner/releases/download/v0.9/Makefile && make image 15:46:54 Ohh 15:47:10 Okay thanks :) 15:47:16 it is the whole sd image based on PiOS (huge in comparation to <50MB buildroot(xmrsignerOS - but could get monero-wallet-rpc running there) 15:48:02 Okay 15:48:34 I do not rememeber much at the moment, because it is a long time ago, https://github.com/DiosDelRayo/MoneroSigner/releases But if you get stuck anywhere drop my name here or write via matrix and I will help you through. 15:49:05 I will try 15:49:16 So i need to build from the old repo 15:49:33 But in the next weeks it will change, how the redirect to wallet rpc will not be necessary anymore (but I'm always slower as I think I will be...) 15:50:18 Ohh yeah 👍 15:50:42 No, this is an image, I compressed and splitted, so I could store it on github, the Makefile is only to decompress and put the parts together again. 15:51:06 Ohh ok 15:51:42 you will need a 16GB sdcard for the image. 15:52:19 I can only imagine the difficultly in developing the OS for monero signing , with its complex cryptography and address types 😅 15:52:51 I have a 32gb sd card which are the standard ones available nowdays 15:53:20 you can use that one, will work. 15:56:13 I have the lib almost ready now, and it will be great :) The only headache in front I can imagine at the moment is to build in buildroot for the pi, but I will see that soon... But XmrSigner will then become smooth how it should be, when you will test it it will take ~3min to "open the wallet" at the moment, be warned. 15:57:51 Okay 15:58:33 Would be waiting for the updates too 😅 15:59:16 So everything works with the build you gave me ? 15:59:36 Obviously not using it with a lot of funds 15:59:44 Obviously not using it with a lot of funds right now 16:00:40 Today they should be already there, but it took me much longer then I planed for the library (which I expect to finish still today, maybe tomorrow). Hope then the rest will go much smoother. 16:02:02 Yes should work everything - but not a great experience with the waiting time. I made like 10 transactions on mainnet. 16:20:14 ```cat xmrsigner-dev-buster-16gb.img.xz.* > xmrsigner-dev-buster-16gb.img.xz 16:20:16 signify-openbsd -C -p xmrsigner.pub -x SHA256.sig xmrsigner-dev-buster-16gb.img.xz 16:20:18 make: signify-openbsd: No such file or directory 16:20:20