Well, the taker is the coordinator. I would not call that a centralized coordinator.

It's not always the same entity, and no one other than the taker knows the input and output mappings or can easily perform a Sybil attack.

Not sure if it can get much better than this from the taker's perspective.

<3

I managed to fix it by running a newer version than what was avaialble at the Debian repos.

It's now at 83% sync. It's running on my home server on an nvme with gigabit internet, so the conditions are pretty good.

Here is the command in case it helps anyone:

```
docker run -d --restart always --name monerod -v /flash/monero/:/home/monero/.bitmonero --user 1000:1000 --network "container:gluetun" ghcr.io/sethforprivacy/simple-monerod:v0.18.4.5 --rpc-restricted-bind-ip=0.0.0.0 --rpc-restricted-bind-port=18089 --no-igd --no-zmq --enable-dns-blocklist --ban-list=/home/monero/ban_list.txt
```

It's more or less the recommended parameters from the Docker image repo, with the addition of running it as unprivileged and behind a VPN (gluetun).

After all night running, on nvme, a powerful CPU and with plenty of RAM, it took several hours to reach 65% and is stuck there. Now all peers are blocked for some reason and is not syncing anymore.

Command used:

```
monerod --data-dir /flash/monero/ --prune-blockchain --sync-pruned-blocks --db-sync-mode=fast:async:250000000 --fast-block-sync 1 --prep-blocks-threads 8 --block-sync-size 100 --max-concurrency 8 --no-igd --no-zmq --enable-dns-blocklist --out-peers 16 --in-peers 8
```

logs:

```
...
2026-02-17 07:54:36.217 I Host 95.217.7.137 blocked.
2026-02-17 07:54:36.217 I Host 95.217.7.248 blocked.
2026-02-17 07:54:40.113 E Too many object fields
2026-02-17 07:54:40.116 E Exception at [portable_storage::load_from_binary], what=Too many object fields
2026-02-17 07:54:41.609 E Too many object fields
2026-02-17 07:54:41.611 E Exception at [portable_storage::load_from_binary], what=Too many object fields
status
Height: 2365820/3611892 (65.5%) on mainnet, not mining, net hash 2.70 GH/s, v14, 16(out)+0(in) connections, uptime 0d 0h 0m 16s
```

All I want is to finish sync and measure the CPU time of validating transactions after the initial sync, to compare with bitcoind and see how it would scale.

Not so nice... Created at could be kind of sensitive. Donated at not sure what it means. And device? Is it decodable somehow? What is it?

Well that's with a remote node. I tried to sync from scratch as I would have for a Bitcoin node. What was very demanding is the IO.

I'm testing it again, and will compare the CPU time of transaction verification after the initial sync.

What was this about? Asking honestly, just read a few articles when it happened. https://en.cryptonomist.ch/2025/09/15/monero-record-reorganization-18-blocks-rewritten-and-118-transactions-made-unconfirmed/

care to elaborate?

IMO no external/centralized coordinator is the way. JoinMarket can still be improved, and that's the plan for JoinMarket NG.

what, why?