by individual transactions to 2 places (but call only once in each):
- ConnectBlock ( before calculated fees per txs twice )
- AcceptToMemoryPoolWorker ( before called CheckTxInputs 4 times and calculated
fees per tx one extra time )
Also call tx.GetValueOut() only once per call of CheckTxInputs (instead of 2)
This resolves an issue where estimatesmartfee would return 999
sat/byte instead of 1000, due to floating point loss of precision
Thanks to sipa for suggesting is_integral.
CFeeRate and CTxMemPoolEntry have explicitly defined copy ctors which has the same functionality as the implicit default copy ctors which would have been generated otherwise.
Besides being redundant, it violates the rule of three (see https://en.wikipedia.org/wiki/Rule_of_three_(C%2B%2B_programming) ).
(Of course, the rule of three doesn't -really- cause a resource management issue here, but the reason for that is exactly that there is no need for an explicit copy ctor in the first place since no resources are being managed).
CFeeRate has an explicitly defined copy ctor which has the same functionality as the implicit default copy ctor which would h
ave been generated otherwise.
This removes the possibility for GetCoin/HaveCoin/HaveCoinInCache to return
true while the respective coin is spent. By doing it across all calls, some
extra checks can be eliminated.
coins_tests is modified to call HaveCoin sometimes before and sometimes
after AccessCoin. A further change is needed because the semantics for
GetCoin slightly changed, causing a pruned entry in the parent cache to not
be pulled into the child in FetchCoin.
A few "a->an" and "an->a".
"Shows, if the supplied default SOCKS5 proxy" -> "Shows if the supplied default SOCKS5 proxy". Change made on 3 occurrences.
"without fully understanding the ramification of a command" -> "without fully understanding the ramifications of a command".
Removed duplicate words such as "the the".
Prior to per-utxo CCoins, we checked that no other in-mempool tx
spent any of the given transaction's outputs, as we don't want to
uncache that entire tx in such a case. However, we now are checking
only that there exists no other mempool spends of the same output,
which should clearly be impossible after we removed the transaction
which was spending said output (barring massive mempool
inconsistency).
Thanks to @sdaftuar for the suggestion.
This patch makes several related changes:
* Changes the CCoinsView virtual methods (GetCoins, HaveCoins, ...)
to be COutPoint/Coin-based rather than txid/CCoins-based.
* Changes the chainstate db to a new incompatible format that is also
COutPoint/Coin based.
* Implements reconstruction code for hash_serialized_2.
* Adapts the coins_tests unit tests (thanks to Russell Yanofsky).
A side effect of the new CCoinsView model is that we can no longer
use the (unreliable) test for transaction outputs in the UTXO set
to determine whether we already have a particular transaction.
This changes the logging categories to boolean flags instead of strings.
This simplifies the acceptance testing by avoiding accessing a scoped
static thread local pointer to a thread local set of strings. It
eliminates the only use of boost::thread_specific_ptr outside of
lockorder debugging.
This change allows log entries to be directed to multiple categories
and makes it easy to change the logging flags at runtime (e.g. via
an RPC, though that isn't done by this commit.)
It also eliminates the fDebug global.
Configuration of unknown logging categories now produces a warning.
This a breaking API change to the prioritisetransaction RPC call which previously required exactly three arguments and now requires exactly two (hash and feeDelta). The function prioritiseTransaction is also updated.
Add notification signals to make it possible to subscribe to mempool
changes:
- NotifyEntryAdded(CTransactionRef)>
- NotifyEntryRemoved(CTransactionRef, MemPoolRemovalReason)>
Also add a mempool removal reason enumeration, which is passed to the
removed notification based on why the transaction was removed from
the mempool.
All decisions about whether the transactions are valid data points are made at the time the transaction arrives. Updating on blocks all the time will now cause stale fee estimates to decay quickly when we restart a node.
Fee estimation can just check its own mapMemPoolTxs to determine the same information. Note that now fee estimation for block processing must happen before those transactions are removed, but this shoudl be a speedup.
Suhas Daftuar