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.
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.
c117d9e Support for error messages and a few more rejection reasons (Luke Dashjr)
14e7ffc Use standard BIP 22 rejection reasons where applicable (Luke Dashjr)
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).
