This is certainly not exhaustive, but it's better than nothing. Adds checks
for:
- Any message received before sending a version
- Any message received other than version/reject before sending a verack
It also tries to goad the remote into sending a pong, address, or block
announcement.
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
Make sure that RPC tests are actually checking failures correctly by:
- Catching JSON RPC exceptions and verifying the error codes and messages.
- Failing the test case if the JSON RPC exception isn't raised.
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.
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
Adds a qa testcase testing the new "-assumevalid" option. The testcase builds
a chain that includes and invalid signature for one of the transactions and
sends that chain to three nodes:
- node0 has no -assumevalid parameter and rejects the invalid chain.
- node1 has -assumevalid set and accepts the invalid chain.
- node2 has -assumevalid set but the invalid block is not buried deep
enough to assume invalid, and so rejects the invalid chain.
If node 0 is sufficiently fast to announce its block to node 1,
node 1 might already have the block by the time the
node_sync_via_rpc loop gets around to node 1, resulting in the
submitblock result "duplicate-inconclusive" as node 1 has the block,
but prefers an alternate chain.
Cory Fields