| Age | Commit message (Collapse) | Author |
|---|
|
This removes another callback from block connection logic, making it
easier to reason about the wallet-RPCs-returns-stale-info issue.
UpdatedTransaction was previously used by the GUI to display
coinbase transactions only after they have a block built on top of
them. This worked fine for in most cases, but only worked due to a
corner case if the user received a coinbase payout in a block
immediately prior to restart. In that case, the normal process of
caching the most recent coinbase transaction's hash would not work,
and instead it would only work because of the on-load -checkblocks
calling DisconnectBlock and ConnectBlock on the current tip.
In order to make this more robust, a full mapWallet loop after the
first block which is connected after restart was added.
|
|
|
|
|
|
This simplifies fixing the wallet-returns-stale-info issue as we
can now hold cs_wallet across an entire block instead of only
per-tx (though we only actually do so in the next commit).
This change also removes the NOT_IN_BLOCK constant in favor of only
passing the CBlockIndex* parameter to SyncTransactions when a new
block is being connected, instead of also when a block is being
disconnected.
This change adds a parameter to BlockConnectedDisconnected which
lists the transactions which were removed from mempool due to
confliction as a result of this operation. While its somewhat of a
shame to make block-validation-logic generate a list of mempool
changes to be included in its generated callbacks, fixing this isnt
too hard.
Further in this change-set, CValidationInterface starts listening
to mempool directly, placing it in the middle and giving it a bit
of logic to know how to route notifications from block-validation,
mempool, etc (though not listening for conflicted-removals yet).
|
|
c4a6929 Clarify assumptions made about when BlockCheck is called (Matt Corallo)
Tree-SHA512: 2eceb0c4f06c7fd6b290b93843bda11a4b63131559c5e8226bfec84596ed4e54ee6d8f5bc9cf789a80675be8b8079cf9234c96032df306258cb2260b9d8c7825
|
|
|
|
|
|
|
|
|
|
Edited via:
$ contrib/devtools/copyright_header.py update .
|
|
|
|
In anticipation of making all the callbacks out of block processing
flow through it. Note that vHashes will always have something in it
since pindexFork != pindexNewTip.
|
|
|
|
|
|
add signal UpdateTip()
7d0bf0b include the chaintip *blockIndex in the SyncTransaction signal (Jonas Schnelli)
|
|
|
|
- allows reducing of calls to main.cpp for getting the chaintip during transaction syncing
- potentially allows reducing of cs_main locks
|
|
- removes mapBlockIndex find operation
- theoretically allows removing the cs_main lock during zqm notification while introducing a new file position lock
|
|
|
|
|
|
- use one CReserveScript per mining thread
|
|
|
|
Fixes #6109
|
|
|
|
0f5954c Regression test for ResendWalletTransactions (Gavin Andresen)
|
|
|
|
Adds a regression test for the wallet's ResendWalletTransactions function, which uses a new, hidden RPC command "resendwallettransactions."
I refactored main's Broadcast signal so it is passed the best-block time, which let me remove a global variable shared between main.cpp and the wallet (nTimeBestReceived).
I also manually tested the "rebroadcast unconfirmed every half hour or so" functionality by:
1. Running bitcoind -connect=0.0.0.0:8333
2. Creating a couple of send-to-self transactions
3. Connect to a peer using -addnode
4. Waited a while, monitoring debug.log, until I see:
```2015-03-23 18:48:10 ResendWalletTransactions: rebroadcast 2 unconfirmed transactions```
One last change: don't bother putting ResendWalletTransactions messages in debug.log unless unconfirmed transactions were actually rebroadcast.
|
|
|
