Previously various user-facing strings have used inconsistent currency units "BTC",
"btc" and "bitcoins". This adds a single constant and uses it for each reference to
the currency unit.
Also adds a description of the unit for --maxtxfee, and adds the missing "amount"
field description to the (deprecated) move RPC command.
This indicates that, eg, we have a public key for a key which may
be used as a pay-to-pubkey-hash. It generally means that we can
create a valid scriptSig except for missing private key(s) with
which to create signatures.
CTransAction::IsEquivalentTo was introduced in #5881.
This functionality is only useful to the wallet, and should never have
been added to the primitive transaction type.
Now that the off-by-one error w/nLockTime txs issue has been fixed by
87550eef (75a4d512 in the 0.11 branch) we can make the anti-fee-sniping
protection create transactions with nLockTime set such that they're only
valid in the next block, rather than an earlier block.
There was also a concern about poor propagation, however testing with
transactions with nLockTime = GetAdjustedTime()+1 as a proxy for
nLockTime propagation, as well as a few transactions sent the moment
blocks were received, has turned up no detectable issues with
propagation. If you have a block at a given height you certainly have at
least one peer with that block who will accept the transaction. That
peer will certainly have other peers who will accept it, and soon
essentially the whole network has the transaction. In particular, if a
node recives a transaction that it rejects due to the tx being
non-final, it will be accepted again later as it winds its way around
the network.
- fixes#3136
- the problem is related to Boost path and a static initialized internal
pointer
- using a std::string in CDBEnv::EnvShutdown() prevents the problem
- this removes the boost::filesystem::path path field from CDBEnv
- rpcwallet: No need to lock twice here
- openssl: Clang doesn't understand selective lock/unlock here. Ignore it.
- CNode: Fix a legitimate (though very unlikely) locking bug.
Chance "getbalance *" not to use IsTrusted. The method and result
now match the "getbalance <specific-account>" behavior. In
particular, "getbalance * 0" now works.
Also fixed a comment -- GetGalance has required 1 confirmation
for many years, and the default "getbalance *" behavior matches
that.
- Add an accept test for zero amounts, and a reject test for negative
amounts
- Remove ugly hack in `settxfee` that is no longer necessary
- Do explicit zero checks in wallet RPC functions
- Don't add a check for zero amounts in `createrawtransaction` - this
could be seen as a feature
- implement find_value() function for UniValue
- replace all Array/Value/Object types with UniValues, remove JSON Spirit to UniValue wrapper
- remove JSON Spirit sources
Previously due to an off-by-one error the wallet ignored
nLockTime-by-height transactions that would be valid in the next block
even though they are accepted into the mempool. The transactions
wouldn't show up until confirmed, nor would they be included in the
unconfirmed balance. Similar to the mempool behavior fix in 665bdd3b,
the wallet code was calling IsFinalTx() directly without taking into
account the fact that doing so tells you if the transaction could have
been mined in the *current* block, rather than the next block.
To fix this we strip IsFinalTx() of non-consensus-critical
functionality, removing the default arguments, and add CheckFinalTx() to
check if a transaction will be final in the next block.
Compute the change directly as difference between the "requested" and
the actual value returned by SelectCoins. This removes a duplication of
the fee logic code.
It's reasonable that automatic coin selection will not pick a zero
value txout, but they're actually spendable; and you should know
if you have them. Listing also makes them available to tools like
dust-b-gone.
Matt Corallo