<m​akeitwork:matrix.org> Hello everyone. As I'm trying to run a local for-developers in-docker monero network, I start two nodes in --regtest mode. When I make them exclusive p2p nodes for each other, one of them says "genesis block mismatch" in the logs:

<m​akeitwork:matrix.org> 2024-01-17 08:14:12.500 [RPC0] ERROR net.p2p src/cryptonote_core/blockchain.cpp:2436 Client sent wrong NOTIFY_REQUEST_CHAIN: genesis block mismatch:

<m​akeitwork:matrix.org> 2024-01-17 08:14:12.501 [RPC0] ERROR net.p2p src/cryptonote_core/blockchain.cpp:2436 id: <48ca7cd3c8de5b6a4d53d2861fbdaedca141553559f9be9520068053cda8430b>,

<m​akeitwork:matrix.org> 2024-01-17 08:14:12.503 [RPC0] ERROR net.p2p src/cryptonote_core/blockchain.cpp:2436 expected: <418015bb9ae982a1975da7d79277c2705727a56894ba0fb246adaabb1f4632e3>,

<m​akeitwork:matrix.org> I can see that one of the block hash it mentions is for the testnet, but the other one is for the mainnet. I'm not sure why mainnet genesis block pops up here at all.

regtest is based off mainnet.

That is, it does not have its own genesis block, etc.

<m​akeitwork:matrix.org> That's interesting. In the Monero codebase, I can see:

<m​akeitwork:matrix.org> mainnet_genesis_hex = "418015bb9ae982a1975da7d79277c2705727a56894ba0fb246adaabb1f4632e3"

<m​akeitwork:matrix.org> and then get_info() returns "top_block_hash":"418015bb9ae982a1975da7d79277c2705727a56894ba0fb246adaabb1f4632e3"

<m​akeitwork:matrix.org> So now the question is, where does "genesis block mismatch" error come from when running two regtest nodes?

<m​akeitwork:matrix.org> A related issue is why I went to run two nodes instead of one, is that when I run only one node and try to generateblocks, it returns status="BUSY" instead of "OK". Then I found someone with a similar problem who worked around it by running two nodes, details here: monero.stackexchange.com/a/13370/16802

<m​akeitwork:matrix.org> That's what I'm trying to do - I just need a working generateblocks().

Run with --offline, don't run with --testnet, don't connect to testnet nodes.

When not offline, a node will want to peer with the network before allowing mining. This is to prevent wastefully mining on presumably bullshit data.

Tangentially, I also usually run with --fixed-difficulty 1, to bypass waiting for blocks.

<m​akeitwork:matrix.org> m-relay: So, that is exactly what I am doing, the command for my supervisord service is:

<m​akeitwork:matrix.org> `monerod --non-interactive --regtest --log-file=/monero/logs/monerod0.log --config-file=/bitmonero.daemon.conf -p2p-bind-ip=127.0.0.1 --p2p-bind-port=28080 --add-exclusive-node=127.0.0.1:28081 --rpc-bind-port=18550 --data-dir=/monero/data0`

<m​akeitwork:matrix.org> And then the conf file is the following (it does have the offline configuration):

<m​akeitwork:matrix.org> ```

<m​akeitwork:matrix.org> # Documentation and examples:

<m​akeitwork:matrix.org> # monerodocs.org/interacting/monero-config-file

<m​akeitwork:matrix.org> regtest=1

<m​akeitwork:matrix.org> keep-fakechain=1 # keep the regtest blockchain, do not remove it after restarting the daemon

<m​akeitwork:matrix.org> no-sync=1

<m​akeitwork:matrix.org> offline=1 # ensures that the node does not connect to the main network and learn of its latest chaintip

<m​akeitwork:matrix.org> fixed-difficulty=1 # keeps the difficulty constant, allowing a large number of blocks to be generated quickly

<m​akeitwork:matrix.org> # Default is 0 = minimal logging; max is 4 - detailed tracing.

<m​akeitwork:matrix.org> log-level=4

<m​akeitwork:matrix.org> max-connections-per-ip=5

<m​akeitwork:matrix.org> #data-dir=/monero/data

<m​akeitwork:matrix.org> # RPC open node

<m​akeitwork:matrix.org> rpc-bind-ip=0.0.0.0

<m​akeitwork:matrix.org> # rpc-bind-port=18551

please use paste.debian.net

<m​akeitwork:matrix.org> So, that is exactly what I am doing, the command for my supervisord service is: `monerod --non-interactive --regtest --log-file=/monero/logs/monerod0.log --config-file=/bitmonero.daemon.conf -p2p-bind-ip=127.0.0.1 --p2p-bind-port=28080 --add-exclusive-node=127.0.0.1:28081 --rpc-bind-port=18550 --data-dir=/monero/data0`

<m​akeitwork:matrix.org> And then the conf file is the following (it does have the offline configuration): paste.debian.net/1304398

I'd remove the --add-exclusive-node, not needed for you (since offline) and there's always a chance you're hitting a testnet node there. Log level 4 is pretty violent too. It's part of the reason why I added log categories.

With those logs, you should also see where it's pulling that testnet genesis block from. Though you'll be swimming in log spam.

<m​akeitwork:matrix.org> Only set log lever 4 in an attempt to understand what is going on. At the end of the day, can I successfully generate blocks while running only a single regtest node, or do I need a network of two?

Either works. I routinely use generateblocks on offline nodes.

And the functional tests do so on networked ones.

<m​akeitwork:matrix.org> okay, to exclude possible conflicts between the command line arguments and the config file, I removed the config file and put all options in command line. Does this look right / similar to what you have for your node for which you routinely generate blocks?

<m​akeitwork:matrix.org> `command=monerod --non-interactive --regtest --keep-fakechain --no-sync --offline --log-level=4 --log-file=/monero/logs/monerod.log --rpc-bind-port=18551 --data-dir=/monero/data --rpc-bind-ip=0.0.0.0 --confirm-external-bind=1 --restricted-rpc=0 --no-igd --hide-my-port --rpc-login=monero:monero --disable-rpc-ban --db-sync-mode=safe --no-zmq=1`

I do not use --non-interactive (unlikely to make a difference though), nor no-sync, not restricted-rpc, nor hide-my-port, nor rpc login, nor disable-rpc-ban, nor db-sync-node.

I do not use config files either. But, if you want to try this, it should work:

monerod --regtest --offline --fixed-difficulty 1 --data-dir /tmp/monerod-tmp

Yes, works.

>>> daemon.generateblocks('TF1MMEY5v2dN49XKNCKCdBqmTMM6GdZZA5UBbDgTewaUd3c2jDazN5yKrG1BBHX3UyPqKD9hrh3DpPTDmWiCmsuRpePT1MTaPxm', 1)

{u'status': u'OK', u'untrusted': False, u'blocks': [u'59700fd0ee8c41127dff75e468cff4701a84881cf584cec458c601fe92617f60'], u'height': 1}

(that's the python RPC console)

(very useful for easily calling RPC on monerod, recommended)

(run with: utils/python-rpc/console RPCPORTGOESHERE)

<m​akeitwork:matrix.org> thanks will give it a try now; I have to call it from the code since it's part of a big project that I'm integrating with Monero.

<m​akeitwork:matrix.org> I remember adding no-sync because my node was actively downloading mainnet blockchain after starting, and I wanted to stop it.

(or run with: utils/python-rpc/console RPCPORTGOESHERE WALLETPORTGOESHERE if you want to run wallet and node RPC at once)

--offline will moot this.

<m​akeitwork:matrix.org> Following your hints, I ran a few test and found out the issue! The `--no-sync` causes generateblocks to return status: BUSY

duno if anyone here is interested. my monerodirect domains expire in 5 days and I will not be renewing them.

Thanks. Might be worth filing a bug, I don't see a use for that behaviour, maybe it wasn't intended.

<m​akeitwork:matrix.org> Now that I can generate blocks, could you clarify one more thing please. Do I use mainnet addresses or testnet addresses with this regtest blockchain?

Mainnet.

<m​akeitwork:matrix.org> Thanks for your help. Filed an issue in Monero repo too.

<j​effro256:monero.social> Do the core_proxy tests actually test anything useful since we have the core_tests ?

<j​effro256:monero.social> It looks like it just spins up a p2p instance with a fake core, does nothing, then turns it off

I never worked out what this was for.