<p​lowsof:matrix.org> unstoppableswap.net basicswapdex.com

<o​frnxmr:xmr.mx> Not true. Nioc is right

<o​frnxmr:xmr.mx> From btc <> xmr, probably unstoppabkeswaps. Its btc focused and has more liq on btc

<o​frnxmr:xmr.mx> What you want to do it type `sync_info` and have a look at what it shows.

<o​frnxmr:xmr.mx> It shows 1. peers that you are connected to 2. a line that says mooooooooo 3. blocks that are queued to be synced.

<o​frnxmr:xmr.mx> 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

<o​frnxmr:xmr.mx> 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`

<a​zizlight:matrix.org> 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

<e​longated:matrix.org> Okay, you know everything about monero 😅

<e​longated:matrix.org> Yea, manually ban then as ban list will save you time

<o​frnxmr:xmr.mx> Not really

<a​zizlight:matrix.org> how could i interact with a docker monerod process? and issue such a command

<o​frnxmr:xmr.mx> Banlist is a different set of nodes

<a​zizlight:matrix.org> ```

<a​zizlight:matrix.org> docker exec -it monerod bash

<a​zizlight:matrix.org> OCI runtime exec failed: exec failed: unable to start container process: exec: "bash": executable file not found in $PATH: unknown

<a​zizlight:matrix.org> ```

<e​longated:matrix.org> github.com/rblaine95/monero-banlist what does this consist of ?

1 of the reasons i stay away from docker

troubleshooting is difficult ag

s/ag/af

<o​frnxmr:xmr.mx> "not the node in question"

<o​frnxmr:xmr.mx> 147.182.160.251

<o​frnxmr:xmr.mx> 151.80.17.140

<o​frnxmr:xmr.mx> 152.42.137.12

<o​frnxmr:xmr.mx> 152.42.164.168

<o​frnxmr:xmr.mx> 152.42.176.57

<o​frnxmr:xmr.mx> 152.42.234.2

<o​frnxmr:xmr.mx> 152.42.238.126

<o​frnxmr:xmr.mx> 152.42.242.48

<o​frnxmr:xmr.mx> 152.42.252.27

<o​frnxmr:xmr.mx> 157.245.108.248

<o​frnxmr:xmr.mx> That is a mirror of the xmr.pm blocklists, which are also different than boog's list

<e​longated:matrix.org> Boogs list has proxy nodes ? are they causing sync issues or were they spying

<o​frnxmr:xmr.mx> The proxy nodes sync fine, they just spy on transactions

<e​longated:matrix.org> So which ban list is helps to keep out asshole nodes which cause sync issue ?

<e​longated:matrix.org> So which ban list helps to keep out asshole nodes which cause sync issue ?

<o​frnxmr:xmr.mx> none. Its hard to reproduce this

<e​longated:matrix.org> Okay, for most users I dealt with xmr.pm blocklist helped them and didn’t face any sync issue

<e​longated:matrix.org> You maybe unable to reproduce but it works

<o​frnxmr:xmr.mx> Using --proxy ive been pushed onto the wrong chain at a similar height, which seemed to be nodes that were targeting tor exit ips

<o​frnxmr:xmr.mx> Its hard to reproduce == it only happens very rarely. 99% of people sync w/o issue. Its the 1/100 that get cut off

<e​longated:matrix.org> Monerod auto corrects though? Or had to make any change

<o​frnxmr:xmr.mx> I the node sent me bad blocks and i had to reading the chain and sync from a good node

<e​longated:matrix.org> Yes 1/100th have their peerlist populated with these asshole nodes

<o​frnxmr:xmr.mx> It usually happens around 1.2-1.5m blockheight in my experience

<o​frnxmr:xmr.mx> Its not the banlist nodes...

<e​longated:matrix.org> Was there some fork around that height ?

<o​frnxmr:xmr.mx> Its some other entity, doing a random attack

<o​frnxmr:xmr.mx> I'm wondering if azizLIGHT was using tor?

<a​zizlight:matrix.org> i dont think so

<a​zizlight:matrix.org> im in the docker container using sh, but how do i send sync_info to the monerod process that is already running

<a​zizlight:matrix.org> its running with a --non-interactive switch

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

tl;dr -- docker complicates things

<a​zizlight:matrix.org> 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

<a​zizlight:matrix.org> 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

if your storage is persistent, you won't lose time

i'm not of anywhere during sync where it cannot be force quit & not resume well later on

<a​zizlight:matrix.org> 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

i dont think it will start over. i doubt it's doing anything significant in memory alone

<o​frnxmr:xmr.mx> ./monerod sync_info

<a​zizlight:matrix.org> i think the process is nonresponsive when pruning blockchain?

<a​zizlight:matrix.org> ```

<a​zizlight:matrix.org> ~ $ monerod status

<a​zizlight:matrix.org> 2025-02-10 00:54:06.842 I Monero 'Fluorine Fermi' (v0.18.3.4-release)

<a​zizlight:matrix.org> Error: Couldn't connect to daemon: 127.0.0.1:18081

<a​zizlight:matrix.org> ~ $ curl localhost:18089/get_info

<a​zizlight:matrix.org> curl: (7) Failed to connect to localhost port 18089 after 0 ms: Could not connect to server

<a​zizlight:matrix.org> ~ $ monerod sync_info

<a​zizlight:matrix.org> 2025-02-10 01:00:46.514 I Monero 'Fluorine Fermi' (v0.18.3.4-release)

<a​zizlight:matrix.org> Error: Couldn't connect to daemon: 127.0.0.1:18081

<a​zizlight:matrix.org> ~ $

<o​frnxmr:xmr.mx> How are you pruning?

oh this is nice. " [WARNING] Trezor support cannot be compiled! Skipping Trezor compilation" thanks whoever did that

<a​zizlight:matrix.org> docker compose up -d on a docker-compose.yaml file that ran

<a​zizlight:matrix.org> ```

<a​zizlight:matrix.org> version: '3'

<a​zizlight:matrix.org> services:

<a​zizlight:matrix.org> monerod:

<a​zizlight:matrix.org> image: ghcr.io/sethforprivacy/simple-monerod:latest

<a​zizlight:matrix.org> user: ${FIXUID:-1000}:${FIXGID:-1000}

<a​zizlight:matrix.org> restart: unless-stopped

<a​zizlight:matrix.org> container_name: monerod

<a​zizlight:matrix.org> volumes:

<a​zizlight:matrix.org> - /mnt/pve-raid1/docker/monerod/data/.bitmonero:/home/monero/.bitmonero

<o​frnxmr:xmr.mx> Using an old/unpruned blockchain?

<a​zizlight:matrix.org> docker compose up -d on a docker-compose.yml file that ran

<a​zizlight:matrix.org> ```

<a​zizlight:matrix.org> version: '3'

<a​zizlight:matrix.org> services:

<a​zizlight:matrix.org> monerod:

<a​zizlight:matrix.org> image: ghcr.io/sethforprivacy/simple-monerod:latest

<a​zizlight:matrix.org> user: ${FIXUID:-1000}:${FIXGID:-1000}

<a​zizlight:matrix.org> restart: unless-stopped

<a​zizlight:matrix.org> container_name: monerod

<a​zizlight:matrix.org> volumes:

<a​zizlight:matrix.org> - /mnt/pve-raid1/docker/monerod/data/.bitmonero:/home/monero/.bitmonero

<a​zizlight:matrix.org> 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)

gingeropolous: hasn't it been like that for a long time?

requires more effort

<a​zizlight:matrix.org> in hopes that it speeds up blockchain download

probably. it was just so frustrating before, im happy every time i see it i guess

<a​zizlight:matrix.org> so im just not sure if this is working because theres no info on the log besides pruning blockchain

<a​zizlight:matrix.org> ```

<a​zizlight:matrix.org> 2025-02-09 22:51:00.600 I Cryptonote protocol stopped successfully

<a​zizlight:matrix.org> 2025-02-10 00:14:59.880 I Monero 'Fluorine Fermi' (v0.18.3.4-release)

<a​zizlight:matrix.org> 2025-02-10 00:14:59.880 I Initializing cryptonote protocol...

<a​zizlight:matrix.org> 2025-02-10 00:14:59.880 I Cryptonote protocol initialized OK

<a​zizlight:matrix.org> 2025-02-10 00:14:59.881 I Initializing core...

<a​zizlight:matrix.org> 2025-02-10 00:14:59.882 I Loading blockchain from folder /home/monero/.bitmonero/lmdb ...

<a​zizlight:matrix.org> 2025-02-10 00:15:17.560 E Underflow in txpool weight

<a​zizlight:matrix.org> 2025-02-10 00:15:17.561 E failed to find transaction input in key images. img=<ef993d365f3efa5e2af37081fe5b0ee04c8b20a6e6dc82c4562cf2360a00dd88>

<a​zizlight:matrix.org> 2025-02-10 00:15:17.561 E transaction id = <d8ffea526c6f1edc73965c0a44f72ca20ed60220f1063efcd11e771b3cef1601>

<a​zizlight:matrix.org> 2025-02-10 00:15:17.562 E Underflow in txpool weight

<a​zizlight:matrix.org> the 200 GiB .bitmonero dir isnt completely synced, just to be clear

<o​frnxmr:xmr.mx> That log isn't pretty

<o​frnxmr:xmr.mx> Btw, when you post logs, try to use a paste site like paste.debian.net or www.zerobin.net

<o​frnxmr:xmr.mx> (it spams the irc side)

<a​zizlight:matrix.org> oh im sorry

hrm, sigbus error

<o​frnxmr:xmr.mx> Ive dont recall pruning a full chain to print those errors. Are you sure the original blockchain isnt corrupt?

<o​frnxmr:xmr.mx> Ginger, what sort of wild setup are you running?

<o​frnxmr:xmr.mx> Ive buit Monero like 18 times over tge past few days and running test prs

<a​zizlight:matrix.org> 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

<a​zizlight:matrix.org> 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

<o​frnxmr:xmr.mx> Wdym? Why not?

<a​zizlight:matrix.org> 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

<o​frnxmr:xmr.mx> That should work

<a​zizlight:matrix.org> then was the .bitmonero 200 GiB dir i saved already corrupted? is that why it was stuck pruning

azizlight if you view `top`, is monerod still processing?

<a​zizlight:matrix.org> i didnt bother continuing with the pruning because of nonindication of status, and not responding to ./monerod status or ./monerod sync_info commands

<a​zizlight:matrix.org> so i killed it

<a​zizlight:matrix.org> 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

<a​zizlight:matrix.org> i had stopped this one because it had gotten stuck synchronizing and i got frustrated because the number didnt increase

<o​frnxmr:xmr.mx> Yeah probably just bad peerq

<a​zizlight:matrix.org> 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

<a​zizlight:matrix.org> 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

ofrnxmr ^

<o​frnxmr:xmr.mx> If youre stuck, the disabling peers and poppibg blocks before restarting with a good node, is a solution

<o​frnxmr:xmr.mx> Youre syncing fine now, so no need

<o​frnxmr:xmr.mx> The second section of sync_info should say `mooooooooooooooo` . The mooo implies that everything is working ok

<a​zizlight:matrix.org> i do see it

<t​ommy_13:matrix.org> 🔥💨 Telegram Menu: Exclusive Premium Selections

<t​ommy_13:matrix.org> t.me/+tb_L9H0WVVU1NWNk

<t​ommy_13:matrix.org> 🍃🌈 Flower & Mushrooms

<t​ommy_13:matrix.org>     •    ⚪ White

<t​ommy_13:matrix.org>     •    💎 Molly

<t​ommy_13:matrix.org>     •    🌿 Flower (🔥 Premium Strains)

<t​ommy_13:matrix.org>     •    🍄 Mushrooms (Raw & Bars):

<t​ommy_13:matrix.org>     •    🍫 Bobby Bars: 4-mushroom blend by Big Thraxington

<t​ommy_13:matrix.org>     •    👻 Spooky Bars: 🎨 Dabman collab (✨ limited edition)

<t​ommy_13:matrix.org>     •    🚪 Golden Doors: Forbes #8 (2023 Top 10)

<t​ommy_13:matrix.org> 🧪🌌 Psychedelics

<3​21bob321:monero.social> Thanka mbll

oh, maybe its just a corrupted mdb file...

<0​xchr1s:matrix.org> Anyone have any insight into why I receive this message?

<0​xchr1s:matrix.org> `2025-02-10 02:00:55.061 W Invalid DNSSEC TXT record signature for updates.moneropulse.no: validation failure <updates.moneropulse.no. TXT IN>: 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`

<p​lsxninja:matrix.org> funny how people comes in here to sell their products of marijuana..... seems scammy like

<k​illercat103:xmr.se> The ones with some random telegram link? Probably

<k​illercat103:xmr.se> Then idk where to buy such and i dont care to find out

<b​asses:matrix.org> discuss.privacyguides.net/t/recommend-kraken-pro-specifically/24826

<b​asses:matrix.org> 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)

<b​asses:matrix.org> 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)

<b​asses:matrix.org> directly*

<s​iren:kernal.eu> Good, low fees. No complaints. Afaik Pro comes with extra KYC and business accounts are also Pro. I use it for my business.

<b​asses:matrix.org> KYC questionnaire, which I'm sure u can fill it with anything, right?

<s​iren:kernal.eu> We needed to submit full-KYC for every single board member as well as company registration documents

<b​asses:matrix.org> interesting, so this is probably the same case for individuals

IIRC Kraken Pro is available for individuals with "Pro Personal" account (ID verification + proof of address verification)

<b​asses:matrix.org> it is the same as intermediate (normal) account, right?

<b​asses:matrix.org> KYC is necessary in both cases

<k​evino:tchncs.de> is Vthor here on the irc side ?

<k​evino:tchncs.de> i need to talk to ask him about the xmrsigner project

yes he's here

<k​evino:tchncs.de> i need to talk to him about the xmrsigner project

yes kevino

<k​evino:tchncs.de> Can you see my dm

kevino: Nope, doesn't work over the bridge, but you can also write @vthor:nope.chat if you want

<k​evino:tchncs.de> Is the issue with building xmrsigner fixed ?

<k​evino:tchncs.de> 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

<k​evino:tchncs.de> Or if binaries were available for testing , i could test it out

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.

Binaries should be there, but letme check - I don't rememeber where I dropped them, give me a moment.

<k​evino:tchncs.de> Ohh i see

<k​evino:tchncs.de> I am using pi zero 2w so don't know if you built it for them

will work also with pi zero 2w, tested it on both

curl -L -o Makefile github.com/DiosDelRayo/MoneroSigner/releases/download/v0.9/Makefile

make image

DEVICE=<device path to microSD> make flash

curl -L -o Makefile github.com/DiosDelRayo/MoneroSigner/releases/download/v0.9/Makefile && make image

<k​evino:tchncs.de> Ohh

<k​evino:tchncs.de> Okay thanks :)

it is the whole sd image based on PiOS (huge in comparation to <50MB buildroot(xmrsignerOS - but could get monero-wallet-rpc running there)

<k​evino:tchncs.de> Okay

I do not rememeber much at the moment, because it is a long time ago, 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.

<k​evino:tchncs.de> I will try

<k​evino:tchncs.de> So i need to build from the old repo

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...)

<k​evino:tchncs.de> Ohh yeah 👍

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.

<k​evino:tchncs.de> Ohh ok

you will need a 16GB sdcard for the image.

<k​evino:tchncs.de> I can only imagine the difficultly in developing the OS for monero signing , with its complex cryptography and address types 😅

<k​evino:tchncs.de> I have a 32gb sd card which are the standard ones available nowdays

you can use that one, will work.

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.

<k​evino:tchncs.de> Okay

<k​evino:tchncs.de> Would be waiting for the updates too 😅

<k​evino:tchncs.de> So everything works with the build you gave me ?

<k​evino:tchncs.de> Obviously not using it with a lot of funds

<k​evino:tchncs.de> Obviously not using it with a lot of funds right now

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.

Yes should work everything - but not a great experience with the waiting time. I made like 10 transactions on mainnet.

<k​evino:tchncs.de> ```cat xmrsigner-dev-buster-16gb.img.xz.* > xmrsigner-dev-buster-16gb.img.xz

<k​evino:tchncs.de> signify-openbsd -C -p xmrsigner.pub -x SHA256.sig xmrsigner-dev-buster-16gb.img.xz

<k​evino:tchncs.de> make: signify-openbsd: No such file or directory

<k​evino:tchncs.de> make: *** [Makefile:38: verify-xz] Error 127```

<k​evino:tchncs.de> `cat xmrsigner-dev-buster-16gb.img.xz.* > xmrsigner-dev-buster-16gb.img.xz

<k​evino:tchncs.de> signify-openbsd -C -p xmrsigner.pub -x SHA256.sig xmrsigner-dev-buster-16gb.img.xz

<k​evino:tchncs.de> make: signify-openbsd: No such file or directory

<k​evino:tchncs.de> make: *** [Makefile:38: verify-xz] Error 127`

<k​evino:tchncs.de> ``cat xmrsigner-dev-buster-16gb.img.xz.* > xmrsigner-dev-buster-16gb.img.xz

<k​evino:tchncs.de> signify-openbsd -C -p xmrsigner.pub -x SHA256.sig xmrsigner-dev-buster-16gb.img.xz

<k​evino:tchncs.de> make: signify-openbsd: No such file or directory

<k​evino:tchncs.de> make: *** [Makefile:38: verify-xz] Error 127``

<k​evino:tchncs.de> @ vthor