rbrunner: I (naively) tried building monerod using a similar approach as we do for FreeBSD. And while I was able to get it to build eventually, I couldn't get it to not segfault on startup. I'm not sure if that's because it wasn't going to work in the first place (which seems likely given what I've read on cross-compiling for OpenBSD) or because of

the hacks I added to get it to build - more investigation needed, but perhaps another time.

<m​onerooo:monero.social> Does the latest gui wallet (v0.18.3.3) support ipv6 settings? It seems that these are completely ignored.

<j​effro256:monero.social> Which ipv6 settings?

<m​onerooo:monero.social> --p2p-use-ipv6=1 --p2p-ignore-ipv4=1 --rpc-use-ipv6=1 --rpc-ignore-ipv4=1

<j​effro256:monero.social> How are you passing those options to the GUI wallet? Those aren't valid options for the GUI AFAIK

<j​effro256:monero.social> If you're passing those options to the Linux AppImage, they're just going to the void

tobtoht_: Thanks for looking into it. Don't waste too much time with it however. I have also found the pretty clear statements from OpenBSD people regarding cross compiling in the meantime.

I think carefully written and clear instructions how to self-compile on OpenBSD for people with only little dev knowledge would also already go a long way

I am really impressed with the security focus of OpenBSD. People on Reddit sometimes ridicule people using Monero on Windows and recommend Linux.

I could retort: "Linux? Pah. Real men use OpenBSD."

<m​onerooo:monero.social> So the official gui does not support ipv6?

Did you specify options in the right place for that in the GUI? In the command-line options that the GUI wallet will pass on to the Monero daemon that it starts automatically?

You could of course also start the daemon yourself, with the proper command line arguments

I am pretty sure that the GUI wallet does not have some dead-simple way to switch to IPV6, e.g. by just using a checkbox somewhere. The true program to talk to will be the Monero daemon.

<m​onerooo:monero.social> Yeah, autostart. /monero-gui-v0.18.3.3/monerod --detach --data-dir=/media/home/SSD/Monero --db-sync-mode=safe (...)

Hmm, if I use "./monerod --p2p-use-ipv6 --p2p-ignore-ipv4 --rpc-use-ipv6 --rpc-ignore-ipv4" with my own daemon, it still happily uses IPV4, and no IPV6 connections ...

I don't think we have any seed nodes that are on IPV6 so if you manage to strictly making any IPV4 connections impossible for your daemon that may not work anyway

<m​onerooo:monero.social> monero-project/monero #8818

<m​onerooo:monero.social> monero-project/monero #9285

<m​onerooo:monero.social> Or only ipv4 default settings ^^

Interesting. Still quite a mess then it seems.

Looks almost hopeless right now, with almost nobody really being reachable on IPV6

<m​onerooo:monero.social> Because nobody has an ipv6 connection except me?😅

<n​obfg9000:matrix.org> hi, I was reading about bitcoin's difficulty adjustment system and how it updates every ~2 weeks. it looks like they have some justification for this, although I'm not sure I agree with the justifications (old.reddit.com/r/Bitcoin/comments/m…all_your_bitcoin/gv86j6b/?context=5). how does difficulty adjustment work in monero and how ofte<clipped message>

<n​obfg9000:matrix.org> n does it update (every block?). Couldn't you just do something like update the difficulty every block, considering the median hashrate (or something) of the last N blocks?

<n​obfg9000:matrix.org> they also seem to comment on bitcoin cash's difficulty adjustment system (EDA) using a shorter adjustment period, but I can't find a source for this. Also it seems like they replaced it with another system called DAA?

<s​omeoneelse495495:matrix.org> hey, be aware that there are several delay between matrix.org and monero.social matrix instance. So you'll probably see messages from yesterday appearing today.

<s​omeoneelse495495:matrix.org> This is a question suited for ArticMine I believe.

<s​omeoneelse495495:matrix.org> There are explanations of the difficulty in the Monero technicals pdf, I forgot the name

<n​obfg9000:matrix.org> oh zero to monero

<s​omeoneelse495495:matrix.org> yeah thats right

<r​ucknium:monero.social> nobfg9000: BCH uses ASERT now. See bitcoincashresearch.org/t/empirical…lysis-of-the-aserts-performance/708 and bitcoincashresearch.org/t/asert-before-and-after/312

my ISP still doesn't support ipv6

nobfg9000: monero.stackexchange.com/questions/…fficulty-adjustment-for-monero-work

@hyc Is this good or bad news?

Is it guaranteed that monero-wallet-rpc --tx-notify "cmd %s" is executed exactly twice?

At the moment, my command(cmd) expects exactly two calls. Once in txpool and once again when the first block has been confirmed. During a stress test, however, some payments run into a timeout. I need to expand the log output to investigate and understand this further. But it seems that at least --tx-notify is called at least once, which is good.

pcre it can be configured / behaviour changed

But the defaults are notif @ 0 then again at 1

<x​fedex:matrix.org> every block

If the rpc wallet is turned off. Then on / while syncing it will trigger when it finds the tx

<x​fedex:matrix.org> monero uses cryptonote's difficulty adjustment

<x​fedex:matrix.org> computation is based on the 720 blocks with a 15-blocks lag, and it cuts the 60 biggest and smallest block times before computing the average block time

@plowsof Ah, that's interesting. So I can actually only expect a single notify on tx confirmed at n.

Perhaps it could also be a problem that I mine a big junk of blocks myself here on the testnet and therefore the notify @ 0 may fail. Just a wild guess.

But I'm probably wrong about that.

@plowsof. Thank you. Your information helps me a lot. cu later - guys.

<p​reland:matrix.org> Question: let’s say you are running a local testnet with two daemons. You accidentally set the difficulty on one daemon differently than another, so the daemons both block each other’s IP (in this case would be localhost).

<p​reland:matrix.org> You then change the difficulties back to matching, and manually block localhost on both daemons. However, they instantly block each other again. What is wrong? (Fyi only one daemon was actually mining, and it was the one with the correct difficulty setting)

did you roll back the mined blocks on the wrong one?