Later commits will introduce checks for "safe TXs" which might abort the
signing on first try, but succeed a few seconds later, so we periodically
retry to sign the tip.
* Let Commit() return void
The boolean return value will loose its meaning in the next commit
* Implement 2-stage commits for CDBTransaction and CScopedDBTransaction
CDBTransaction is changed to allow CDBBatch, CDBWrapper and other
CDBTransactions as parent instead of just CDBWrapper. This in turn allows
to implement multi-staged commits in CEvoDB.
We now have the "current transaction" which is started and ended (commit
or rollback) for each call to Connect-/DisconnectBlock. When the current
transaction is committed, it moves its contents into the "root transaction"
instead of directly writing to CDBWrapper.
CommitRootTransaction() then handles the final commitment to CDBWrapper. It
is called at the same time when the chainstate is flushed to disk, which
guarantees consistency between chainstate and CEvoDB.
* Allow to efficiently move values into parent transactions to avoid copies
When CDBTransaction<CDBTransaction<...>>::Commit() is called, we can avoid
copying values from this transaction to the parent transaction and instead
pass values by rvalue and let the contents be moved.
* Revert "Force FlushStateToDisk on ConnectTip/DisconnectTip while not in IBD (#2560)"
This reverts commit 6dfceaba5a.
* Add a button/context menu item to show qr codes for addresses in address book
* Add a context menu item to show qr code for addresses in transaction list
The local node might be the bad one actually as it might not have catched
up with the chain. In that case, LLMQs might be different for the sending
and receiving node.
When ProcessMessageBatchedSigShares returns false, it's interpreted as
if an invalid/malicious message was received, causing a ban. So, we should
return "!ban" instead of just "ban".
It was reported on iOS that CMerkleBlock sometimes included the dummy
quorum commitments introduced with v13, which led to banning of nodes as
these were not supported/expected there.
We should in general only include TXs here that are of interest for SPV
nodes, so we should maintain the list of allowed TX types.
* Ignore sig share inv messages when we don't have the quorum vvec
* Update src/llmq/quorums_signing_shares.cpp
Co-Authored-By: codablock <ablock84@gmail.com>
We may eventually want to break out harfbuzz and build it in depends, but
for now just ensure that runtime dependencies don't depend on whether or not
harfbuzz was present on the builder.
* On timeout, print members proTxHashes from members which did not send a share
* Move inactive quorums check above timeout checks
This allows to reuse things in the next commit
* Avoid locking cs_main through GetQuorum by using a pre-filled map
* Use find() instead of [] to access quorums map
* Return bool in ProcessMessageXXX methods to indicate misbehaviour
* Send/Receive multiple messages as part of one P2P message in CSigSharesManager
Many messages, especially QSIGSHARESINV and QGETSIGSHARES, are very small
by nature (5-14 bytes for a 50 members LLMQ). The message headers are
24 bytes, meaning that we produce a lot of overhead for these small messages.
This sums up quite a bit when thousands of signing sessions are happening
in parallel.
This commit changes all related P2P messages to send a vector of messages
instead of a single message.
* Remove bogus lines
Included these by accident
* Unify handling of BanNode in ProcessMessageXXX methods
* Remove bogus check for fMasternodeMode
* Properly use == instead of misleading >= in SendMessages
* Put "didSend = true" near PushMessage
Stop relying on the information previously found in the CSigSharesInv
and CBatchedSigShares messages and instead use the information found in
the session refereced by the session id.
This also updates a few LogPrintf calls. Previously, CSigSharesInv::ToString
also included the signHash in the returned string, which is not the case
anymore, so we have to add it manually.
We must watch out to not blindly use externally provided keys in unordered
sets/maps, as attackers might find ways to cause unbalanced hash buckets
causing performance degradation.
Allows convenient salted hashing with unordered maps and sets. Useful when
there is a risk of unbalanced hash buckets slowing things down, e.g. when
externally supplied hashes are used as keys into a map.
