This is just to make the API easier to follow. Also cleaned up
AsyncOnObject to not default to caarse timer unless the interval is
>2000 msec.
Also we use QMetaObject::invokeMethod() directly by default if the
AsyncOnObjectCall() has when_ms <= 0 (default).
This should have no real observable change on app behavior other than
being a code cleanup & nit.
This commit allows aarch64 and/or arm64 hosts to cross-build
for amd64 docker targets (the reverse was always supported).
This commit is needed because now I run an Apple Silicon Mac and I'd
like to be able to cross-build to x64_64.
Minor nit in preparation for the May 2026 upgrade.
The only change really is that when working with token serializations,
we pre-allocate more space for token commitments in EstimatedSerialSize()
which now expects up to 128 byte commitments.
Otherwise everything is the same, pretty much.
It was kinda specialized code that tried to react to the exact rocksdb
version we are running and/or compiling against and figure out the version
and commit hash of rocksdb.
It really just belongs in Storage/Compat.cpp and not in Storage.cpp itself.
The rocksdb team removed the long-standing "raw pointer"
rocksdb::DB::Open() API in favor of the unique_ptr version.
The reason we were using the raw pointer version is because it was more
compatible with older versions, including the one that ships with
Fulcrum.
As a result we were forced to create a "Compat" later in Storage/ for
rocksdb::DB::Open that smoothes over the differences. This commit just
makes all calls to rocksdb::DB::Open() in the codebase go through
Compat::DBOpen.
Undoing the blocks anyway is mainly pointless due to rocksdb guarantees
and was added as a paranoia measure. We should probably eventually
remove this mechanism but for now we will undo just the latest block,
not the lest 6 blocks as that may be excessive and is sometimes slow for
BTC.
This fixes issue #324. We throttle the creation of new connections to max 10 per second, and
we also impose some additional logic on windows to pause the creation of new connections if
the windows object count exceeds 5000, or the active client connections in PeerMgr exceed 50.
For non-windows we just limit active client connections in PeerMgr to 200 before we pause.
This should avoid future unforeseen issues on all platforms, but definitely also fixes the
actual issue we have seen with Windows (issue #324).
This can save on allocations in some cases, so we were able to simplify
BTC::Address class to us this new facility in CScript operator<<
Taken from BCHN MR !2023.
To preserve previous behavior. Every 10 mins was a bit too frequent.
Every 30 was what we did before, so we should just maintain the same
behavior.
Also in this commit: don't normal-level log the "Verified peer" message
if refreshing a known-good peer, instead put it in debug-level log.
Only do the SSL retry if it's clear we failed to connect to the port
either via "Connection refused" or via "timed out" (either of which can
happen if the port is closed, depending on router config on the remote
end).
Also: Tweaked the log message and also clear the preferSsl flag on full-on
failure to retry from scratch with TCP again in future.
This helps us tolerate server misconfigurations where the TCP port is
invalid/not-working but the SSL port would work. e.keff.org on BTC
mainnet is one such server.
We prefer to be tolerant here to pick up as many "good" servers as
possible, in the interests of wallets obtaining as many options as
possible for servers.
This is ok to do and preferable since wallets almost exclusively use the
SSL port anyway.
These calls are no longer needed for when clients are created and
destroyed (as they once were). They were redundant and have been removed
to reduce potential extra update() calls running when nothing changed.
* Peer Manager: Don't keep "good" peer connections alive
Closes#307.
All previous versions of Fulcrum would maintain active connections to
all "goor" peers forever, periodically refreshing them every ~30 mins.
However, on BTC with so many Electrum-style servers around, this could
end up eating ~200 or more connections just for peer discovery. Since
this is wasteful, we instead opt to simply disconnect after determining
that a peer is "good" and instead keep around a separate "good" list
(previously the "good list" was just the active PeerClient connections).
We re-connect to known-good peers every 10 mins to determine whether
they are still up and to pick up any changed ports, etc.
* PeerMgr: Log to debug number of active clients we delete on cleanup
Also make Client::Info::protocolVersion default to the ServerMisc
minimum protocol version, rather than the magic number we used before,
so that things rely on minimum version in only 1 place in the code..
Also in this commit:
- Updated README.md to talk about v1.6 protocol compatibility and need
for v28.0.0 or above of Core/Knots
- Updated RPC error message saying Bitcoin Core or Bitcoin Knots (not
just Bitcoin Core) >= v28.0.0 is ok for submitpackage.
We validate args in an asynch thread since that is potentially costly
(we must hash the first txn, etc).
When that's done, we forward request to bitcoind.
This required us allowing generic_do_async to accept an optional
"completion" function. In order to make things cleaner and faster we
templatized ServerBase::generic_do_async, and redid its internals
slightly. Hopefully this is cleaner and also hopefully redundant copies
of e.g. std::function are avoided with this template implementation.
Also in this commit: Various nits and fixups in Util.h, added
ThrowInternalErrorIf() macro, and other misc. cleanup.
