Prior to this commit pindexRescan was initialized to a chainActive.Tip().
However, the value of pindexRescan set at time of initialization was never
read before pindexRescan was being set to either chainActive.Genesis()
(case 1), FindForkInGlobalIndex(chainActive, locator) (case 2) or
chainActive.Genesis() (case 3). Thus, the initialization was redundant.
This commit a.) removes the redundant initialization and b.) simplifies
this logic so that pindexRescan is initialized to chainActive.Genesis()
(case 1 and 3), and set to FindForkInGlobalIndex(chainActive, locator)
(case 2) as needed.
This removes the option from the wallet to not pay a fee on "small"
transactions which spend "old" inputs.
This code is no longer worth keeping around, as almost all miners
prefer not to include transactions which pay no fee at all.
Warnings introduced by commit e2e2f4c "Return errors from importmulti if
complete rescans are not successful" and reported by Pavel Janík
<Pavel@Janik.cz> in https://github.com/bitcoin/bitcoin/pull/9773 and
https://github.com/bitcoin/bitcoin/pull/9827
wallet/test/wallet_tests.cpp: In member function ‘void wallet_tests::rescan::test_method()’:
wallet/test/wallet_tests.cpp:377:17: warning: declaration of ‘wallet’ shadows a global declaration [-Wshadow]
CWallet wallet;
Remove "nLowestTimestamp <= chainActive.Tip()->GetBlockTimeMax()" check from
importmulti, which is always true because nLowestTimestamp is set to the
minimum of the most recent block time and all the imported key timestamps,
which is necessarily lower than the maximum block time.
A new AssertLockHeld(cs_wallet) call was added in commit a58370e
"Dedup nTimeFirstKey update logic" (part of PR #9108).
The lock held assertion will fail when loading prexisting wallets files from
before the #9108 merge that have watch-only keys.
Because it is used inconsistently at least version 5.4.0 of g++ to
complains about methods that don't use override. There is two ways to go
about this: remove override from the methods having it, or add it to the
methods missing it. I chose the second.
When importing a watch-only address over importmulti with a specific timestamp,
the wallet's nTimeFirstKey is currently set to 1. After this change, the
provided timestamp will be used and stored as metadata associated with
watch-only key. This can improve wallet performance because it can avoid the
need to scan the entire blockchain for watch only addresses when timestamps are
provided.
Also adds timestamp to validateaddress return value (needed for tests).
Fixes#9034.
Additionally, accept a "now" timestamp, to allow avoiding rescans for keys
which are known never to have been used.
Note that the behavior when "now" is specified is slightly different than the
previous behavior when no timestamp was specified at all. Previously, when no
timestamp was specified, it would avoid rescanning during the importmulti call,
but set the key's nCreateTime value to 1, which would not prevent future block
reads in later ScanForWalletTransactions calls. With this change, passing a
"now" timestamp will set the key's nCreateTime to the current block time
instead of 1.
Fixes#9491
Minimum boost version was bumped to 1.47.0 in #8920, which
means the configure step won't even pass with older boost.
This version has boost filesystem v3, which means the
(crappy) fallbacks for older versions can go.
Preserve comment, order form, and account strings from the original wallet
transaction. Also set fTimeReceivedIsTxTime and fFromMe fields for consistency
with CWallet::CreateTransaction. The latter two fields don't influence current
wallet behavior, but do record that the transaction originated in the wallet
instead of coming from the network or sendrawtransaction.
More accurate than simply adding one byte per input, and properly handles the
case where the original transaction happened to have very small signatures
The result value indicates the actual fee on the transaction that was replaced. But there is an error message which uses the description 'oldfee' to refer to the original fee rate applied to the new transaction's estimated max size. It was confusing that two different uses of 'oldfee' had two different numeric values.
Have wallet's default bump value be higher than the default incrementalRelayFee to future proof against changes to incremental relay fee. Only applies when not setting the fee rate directly.
Use the wallet's fee calculation logic to properly clamp fee against minimums and maximums when calculating the fee for a bumpfee transaction. Unless totalFee is explictly given, in which case, manually check against min, but do nothing to adjust given fee.
In all cases do a final check against maxTxFee (after adding any incremental amount).
This command allows a user to increase the fee on a wallet transaction T, creating a "bumper" transaction B.
T must signal that it is BIP-125 replaceable.
T's change output is decremented to pay the additional fee. (B will not add inputs to T.)
T cannot have any descendant transactions.
Once B bumps T, neither T nor B's outputs can be spent until either T or (more likely) B is mined.
Includes code by @jonasschnelli and @ryanofsky
practicalswift