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
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.
Change check_announcement_of_new_block() to wait specifically for the
announcement of the newly created block, instead of waiting for any
announcement at all. A difficult to reproduce failure in
check_announcement_of_new_block() that happened in a travis build
(https://travis-ci.org/bitcoin/bitcoin/jobs/175198367) might have happened
because an older announcement was mistaken for the expected one. The error
looked like:
Assertion failed: Failed
File ".../bitcoin/qa/rpc-tests/test_framework/test_framework.py", line 145, in main
self.run_test()
File ".../bitcoin/build/../qa/rpc-tests/p2p-compactblocks.py", line 787, in run_test
self.test_sendcmpct(self.nodes[1], self.segwit_node, 2, old_node=self.old_node)
File ".../bitcoin/build/../qa/rpc-tests/p2p-compactblocks.py", line 201, in test_sendcmpct
check_announcement_of_new_block(node, test_node, lambda p: p.last_cmpctblock is None and p.last_inv is not None)
File ".../bitcoin/build/../qa/rpc-tests/p2p-compactblocks.py", line 194, in check_announcement_of_new_block
assert(predicate(peer))
This commit also changes the assertion failed message above to include more
detailed information for debug.
Motivation for this change is mainly to make sync_blocks behavior easier to
understand. Behavior is unchanged in the normal case when there are only 2
nodes in the rpc_connections set. When there are more than 2 nodes, the
previous "timeout -= wait" statement wouldn't take into account time spent
waiting for all nodes and as a result could lead to blocking for longer than
the requested timeout.
Russell Yanofsky