Adds a "walletconflicts" array to transaction info; if
a wallet transaction is mutated, the alternate transaction id
or ids are reported there (usually the array will be empty).
Metadata from the original transaction is copied to the mutant,
so the transaction time and "from" account of the mutant are
reported correctly.
- Exclamation mark icon for conflicted transactions
- Show mouseover status for conflicted transactions as "conflicted"
- Don't show inactive transactions on overview page overview
Extend CMerkleTx::GetDepthInMainChain with the concept of
a "conflicted" transaction-- a transaction generated by the wallet
that is not in the main chain or in the mempool, and, therefore,
will likely never be confirmed.
GetDepthInMainChain() now returns -1 for conflicted transactions
(0 for unconfirmed-but-in-the-mempool, and >1 for confirmed).
This makes getbalance, getbalance '*', and listunspent all agree when there are
mutated transactions in the wallet.
Before:
listunspent: one 49BTC output
getbalance: 96 BTC (change counted twice)
getbalance '*': 46 BTC (spends counted twice)
After: all agree, 49 BTC available to spend.
This allows getting raw transaction data from the wallet even if the
transaction is no longer in the blockchain / mempool (for example if it
got orphaned due to malleability abuse).
This commit strengthens 1bbca249b2 by updating the CWalletTx::IsConfirmed() function.
If (bSpendZeroConfChange==false), then IsConfirmed() should actually treat unconfirmed change as being unconfirmed.
contrib/devtools/fix-copyright-headers.py script to be able to perform this maintenance task with ease during the rest of the year, every year. Modifications to contrib/devtools/README.md to document what fix-copyright-headers.py does.
- Log a warning when bootstrap files are specified using `-loadblock`
but cannot be opened.
- Log a warning when bootstrap.dat exists in the home directory
but cannot be opened.
Keep track of which block is being requested (and to be requested) from
each peer, and limit the number of blocks in-flight per peer. In addition,
detect stalled downloads, and disconnect if they persist for too long.
This means blocks are never requested twice, and should eliminate duplicate
downloads during synchronization.
In case the total number of orphan blocks in memory exceeds a limit
(currently set to 750), a random orphan block (which is not
depended on by another orphan block) is dropped. This means it will
need to be downloaded again, but it won't consume memory until then.
Just for completeness. Only a few messages changed or moved since last time.
Don't change any translatable messages until 0.9 final unless really necessary.
The getaddednodeinfo RPC call, when invoked with the dns flag set to
false, returns a malformed JSON object with duplicate keys.
Change this to return an array of objects with one key as
shown in the help message.
Fixes#3581.
- remove btc address length from address validator
- add an optional btc address check in validated line edit that defaults
to off and is used in GUIUtil::setupAddressWidget()
- an isAcceptable() check is added to validated line edit on focus out
which only kicks in, when a validator is used with that widget
- remove an isAcceptable() check from sendcoinsentry.cpp
- remove obsolete attributes from ui files, which are set by calling
GUIUtil::setupAddressWidget()
- move some more things to GUIUtil::setupAddressWidget() and remove them
from normal code e.g. placeholder text
This changes the block processing logic from "try to atomically switch
to a new block" to a continuous "(dis)connect a block, aiming for the
assumed best chain".
This means the smallest atomic operations on the chainstate become
individual block connections or disconnections, instead of entire
reorganizations. It may mean that we try to reorganize to one block,
fail, and rereorganize again to the old block. This is slower, but
doesn't require unbounded RAM.
It also means that a ConnectBlock which fails may be no longer called
from the ProcessBlock which knows which node sent it. To deal with that,
a mapBlockSource is kept, and invalid blocks cause asynchronous "reject"
messages and banning (if necessary).
Pieter Wuille