This crash seemed to have never happened in 0.8.x, and we are missing the later commit
in a8db31c83d6a43e07f741f7f61b1bf0df87621c7 so it seems better to just revert this.
This reverts commit 036a69c13c06670b46d3c02cb47e3fc7b2487854.
Rebased-from: e7853a91cf646a6a4701158d148f036924575a97
Rebased-by: Warren Togami <wtogami@gmail.com>
Original code from https://github.com/bitcoin/bitcoin/pull/3656
Warning
=======
This patch was rejected from Bitcoin Core and must be considered experimental.
Theoretically it is compatible with the de facto standard as utilized by
blockchain.info and a few vendors.
We were losing information about sent/received by overriding the
category in case of a conflicted transaction.
Hence, remove the "conflicted" category.
Conflicted status of a transaction can still be determined by looking
for confirmations<0.
Rebased-from: b77ecd66b6b19921c98422bf70a39c4338c2f8b9 0.8.x
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.
Conflicts:
src/qt/walletmodel.cpp
src/wallet.cpp
Conflicts:
src/wallet.cpp
Rebased-from: 07986591be1610f3a209f15755dabad14322f16c 0.8.x
- fix crash with walletpassphrase by checking if RPC server is running and
give a friendly error message how to fix this (fixes#3100)
- add 3 new RPCErrorCodes RPC_SERVER_NOT_STARTED
- use the new code where needed / missing
Upstream: 4315ec1a722a290ba2bb2b86080a787f6174e2a2
Conflicts:
src/rpcnet.cpp
src/rpcwallet.cpp
Rebased-from: a80b01cdf6323dae55020933ad1f5ea52f64b0bc 0.8.x
Two reasons for this change:
1. Need to always use boost::thread's sleep, even on Windows, so the
sleeps can be interrupted (prior code used Windows' built-in Sleep).
2. I always forgot what units the old Sleep took.
Two changes:
Use IsConfirmed() instead of IsFinal(), so 'getbalance "*" 0' uses the same
'is this output spendable' criteria as 'getbalance'. Fixes issue #172.
And a tiny refactor to CWallet::GetBalance() (redundant call to IsFinal -- IsConfirmed
calls IsFinal).
getbalance with no arguments and 'getbalance "*" 0' could return different different results,
This is to support the signrawtransaction API call; given the public
keys involved in a multisig transaction, this gives back the redeemScript
needed to sign it.
- fix#1560 by properly locking proxy related data-structures
- update GetProxy() and introduce GetNameProxy() to be able to use a
thread-safe local copy from proxyInfo and nameproxyInfo
- update usage of GetProxy() all over the source to match the new
behaviour, as it now fills a full proxyType object
- rename GetNameProxy() into HaveNameProxy() to be more clear
OrderedTxItems returns a multimap of pointers, but needs a place to store the actual CAccountingEntries it points to.
It had been using a stack item, which was clobbered as soon as it returned, resulting in undefined behaviour.
This fixes at least bug #1768.
- Show address receiving the generation, and include it in the correct "account"
- Multiple entries in listtransactions output if the coinbase has multiple outputs to us
Logic:
- If sending a transaction, assign its timestamp to the current time.
- If receiving a transaction outside a block, assign its timestamp to the current time.
- If receiving a block with a future timestamp, assign all its (not already known) transactions' timestamps to the current time.
- If receiving a block with a past timestamp, before the most recent known transaction (that we care about), assign all its (not already known) transactions' timestamps to the same timestamp as that most-recent-known transaction.
- If receiving a block with a past timestamp, but after the most recent known transaction, assign all its (not already known) transactions' timestamps to the block time.
For backward compatibility, new accounting data is stored after a \0 in the comment string.
This way, old versions and third-party software should load and store them, but all actual use (listtransactions, for example) ignores it.
