- allows to directly select an address from the addressbook, chose "send
coins" from the context menu, which sends you to sendcoins tab and fills
in the selected address
- try to enforce the same style to all Qt related files
- remove unneeded includes from the files
- add missing Q_OBJECT, QT_BEGIN_NAMESPACE / QT_END_NAMESPACE
- prepares for a pull-req to include Qt5 compatibility
- remove an unneeded MODAL flag, as MSG_ERROR sets MODAL
- re-order an if-clause in main to have bool checks before a function call
- fix some log messages that used wrong function names
- make a log message use a correct ellipsis
- remove some unneded spaces, brackets and line-breaks
- fix style for adding files in the Qt project
This fixes test_bitcoin failures on openbsd reported by dhill on IRC.
On some systems rand() is a simple LCG over 2^31 and so it produces
an even-odd sequence. ApproximateBestSubset was only using the least
significant bit and so every run of the iterative solver would be the
same for some inputs, resulting in some pretty dumb decisions.
Using something other than the least significant bit would paper over
the issue but who knows what other way a system's rand() might get us
here. Instead we use an internal RNG with a period of something like
2^60 which is well behaved. This also makes it possible to make the
selection deterministic for the tests, if we wanted to implement that.
Switch to using Qt's QLocalServer/QLocalSocket to handle bitcoin
payment links (bitcoin:... URIs)
Reason for switch: the boost::interprocess mechanism seemed flaky,
and doesn't mesh as well with "The Qt Way"
qtipcserver.cpp/h is replaced by paymentserver.cpp/h
Click-to-pay now also works on OSX, with a custom Info.plist
that registers Bitcoin-Qt as a handler for bitcoin: URLs and
an event listener on the main QApplication that handles
QFileOpenEvents (Qt translates 'url clicked' AppleEvents into
QFileOpenEvents automagically).
Extremely large transactions with lots of inputs can cost the network
almost as much to process as they cost the sender in fees.
We would never create transactions larger than 100K big; this change
makes transactions larger than 100K non-standard, so they are not
relayed/mined by default. This is most important for miners that might
create blocks larger than 250K big, who could be vulnerable to a
make-your-blocks-so-expensive-to-verify-they-get-orphaned attack.
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 change allows us to keep the translation without the need to
re-translate any string, when we update the copyright year
- copyright symbol is changed to HTML to ensure we get no encoding
issues and it's removed from the translation string so translators don't
break it by mistake
Version numbers changed from 0.7.99 to 0.8.0
Set CLIENT_VERSION_IS_RELEASE to remove pre-release warning
Updated copyright in COPYING and doc/READMEs to 2013
Updated doc/release-notes.txt
At least one service that accepted zero-confirmation transactions
was vulnerable because an attacker could send a transaction
with a lock time far in the future, and then have plenty of time in
which to get a double-spend mined (perhaps from a miner who wasn't
on the network when the first transaction was broadcast).
That is a variation on the "Finney attack". We still don't
recommend anybody accept 0-confirmation transactions as final
payment for anything. This change keeps non-final transactions
from appearing in the wallet, and, assuming most of the network
accepts this change, will prevent them from being relayed until
they are final.
* Pass txid's to CCoinsView functions by reference instead of by value
* Add a method to swap CCoins, and use it in some places to avoid a
allocating copy + destruct.
* Optimize CCoinsViewCache::FetchCoins to do only a single search
through the backing map.
- don't show QR Code context menu, when USE_QRCODE=1 was not specified
when compiling the client
- re-work on_showQRCode_clicked() for better readability and remove an
unneeded duplicate check
- re-work on_signMessage_clicked() and on_verifyMessage_clicked() to match
foreach in on_showQRCode_clicked(), which seems more robust / cleaner
- re-order context menu stuff to match real context menu layout
- add comments for all private slots in the class
Several changes to make the native windows leveldb code compile
with mingw32 and run on 32-bit Windows:
* Remove -std=c++0x dependency (modified code to use NULL instead of
nullptr)
* Link with -lshlwapi
* Only #define snprintf/etc if compiling with Visual Studio
* Do not link against DbgHelp.lib (wrote a CreateDir instead of using
DbgHelp's MakeSureDirectoryPathExists
* Define WINVER=0x0500 so MinGW32 can use the 64-bit-filesystem Windows
api calls
* Define __USE_MINGW_ANSI_STDIO=1 to use MinGW's printf (which supports
%ll)
I also cleaned up makefile.mingw, assuming that dependencies would be in
the standard /usr/local/{include,lib} by default but allowing overriding
with make DEPSDIR=... etc
This actually simplifies some SPV code, as they can keep track of
a filtered block and its txn before accepting both in one step.
The previous argument was that SPV nodes should handle the txn the
same as any other free txn and then mark them as connected to a
block when they get the filtered block itself. However, it now
appears that SPV nodes will need to put in more effort to verify
loose txn than they would to verify txn in blocks, thus making it
more approriate to send the txn after the filtered block.
By specifying -txindex when initializing the database, a txid-to-diskpos
index is maintained in the blktree database. This database is used to
help answering getrawtransaction() RPC queries, when enabled.
Changing the -txindex value requires a -reindex; the client will abort
at startup if the database and the specified -txindex mismatch.
- this flag allows bitcoin-qt.exe / bitcoind.exe (32-bit application) to
handle addresses larger than 2GB (up to 3GB on x86 Windows and up to
4GB on x64 Windows)
Note that the default value for fRelayTxes is false, meaning we
now no longer relay tx inv messages before receiving the remote
peer's version message.
Fixes issue #2178 : attacker could penny-flood with invalid-signature
transactions to deduce which addresses belonged to your node.
I'm committing this early for code review; I still need to write up
a test plan.
Executive summary of fix: check all transactions received from the network
for penny-flood rate-limiting before adding to the memory pool. But do NOT
ratelimit transactions added to the memory pool:
- because of blockchain reorgs
- stored in the wallet and added at startup
- sent from the GUI or one of the send* RPC commands (CWallet::CommitTransaction)
The limit-free-transactions code really should be a method on CNode, with
counters per-peer. But that is a bigger change for another day.
- it was bad, that quite some messages were just talking about a database,
I think a user should know, if we are talking about wallet db or
block/coin db
- also adds a new init message for "Verifying block database integrity..."
- this pull adds an InitMessage() function to noui.cpp, which outputs init
messages to debug.log (this allows to remove some printf() calls from
init.cpp)
- change InitMessage() in bitcoin.cpp to also write init messages to
debug.log to ensure nothting is missing in the log because of the
removal of printf() calls in init.cpp
Client (SPV) mode never got implemented entirely, and whatever part was already
working, is likely not been tested (or even executed at all) for the past two
years. This removes it entirely.
If we want an SPV implementation, I think we should first get the block chain
data structures to be encapsulated in a class implementing a standard interface,
and then writing an alternate implementation with SPV semantics.
- add qSort() for cachedAddressTable, as qLowerBound() and qUpperBound()
require the list to be in ascending order (see
http://harmattan-dev.nokia.com/docs/library/html/qt4/qtalgorithms.html#qLowerBound)
- add a new check in AddressTableModel::setData() to just return, when no
changes were made to a label or an address (prevents entry duplication
issue)
- remove "rec->label = value.toString();" from
AddressTableModel::setData() as the label gets updated by
AddressTablePriv::updateEntry() anyway (seems @sipa added this line via
1025440184 (L6R225))
- add another new check in AddressTableModel::setData() to just return, if
a duplicate address was found (prevents address overwrite)
- add a new check to EditAddressDialog::setModel() to prevent setting an
invalid model
- re-work the switch-case statement in AddressTableModel::accept() to
always break (as return get's called anyway) and order the list to match
the enum definition
- make accept() in editaddressdialog.h a public slot, which it should be
- misc small coding style changes
Previously when a transaction was set to lock at a specific block the
calculation was reversed, returning a negative number. This broke the UI
and caused it to display %n in place of the actual number.
In addition the previous calculation would display "Open for 0 blocks"
when the block height was such that the next block created would
finalize the transaction. Inserted the word "more" and changed the
calculation so that the last message would be "Open for 1 more block" to
better match user expectations.
Since block validation happens in parallel, multiple threads may be
accessing the signature cache simultaneously. To prevent contention:
* Turn the signature cache lock into a shared mutex
* Make reading from the cache only acquire a shared lock
* Let block validations not store their results in the cache
* During block verification (when parallelism is requested), script
check actions are stored instead of being executed immediately.
* After every processed transactions, its signature actions are
pushed to a CScriptCheckQueue, which maintains a queue and some
synchronization mechanism.
* Two or more threads (if enabled) start processing elements from
this queue,
* When the block connection code is finished processing transactions,
it joins the worker pool until the queue is empty.
As cs_main is held the entire time, and all verification must be
finished before the block continues processing, this does not reach
the best possible performance. It is a less drastic change than
some more advanced mechanisms (like doing verification out-of-band
entirely, and rolling back blocks when a failure is detected).
The -par=N flag controls the number of threads (1-16). 0 means auto,
and is the default.
- ensure we use strCaption for printf and fprintf, as before it could
happen to have an error message in the debug.log, which had no "Error"
(or whatever) in front
- this prevents an interference with the IPC message queue (which is used
for URI processing) when running a testnet and mainnet instance in
parallel
- to check for testnet, I had to raise the ParseParameters() call in
main() to the topmost position
- a click on "Reset Options" sets all options to the default values by
removing all stored settings (QSettings), loading the defaults and
saving them as the new settings
- before the reset is executed the user is presented a confirmation dialog
- special casing was needed for StartAtStartup
- some users reported it as weird, that the estimated block count could be
lower than our own nodes block number (which is indeed true and not good)
- this pull adds a new default behaviour, which displays our own block
number as estimated block number, if own >= est. block count
- the pull raises space for nodes block counts in cPeerBlockCounts to 8 to
be more accurate
- also removes a reduntant setNumBlocks() call in RPCConsole and moves
initialisation of numBlocksAtStartup in ClientModel, where it belongs
-checklevel gets a new meaning:
0: verify blocks can be read from disk (like before)
1: verify (contextless) block validity (like before)
2: verify undo files can be read and have good checksums
3: verify coin database is consistent with the last few blocks
(close to level 6 before)
4: verify all validity rules of the last few blocks
Level 3 is the new default, as it's reasonably fast. As level 3 and
4 are implemented using an in-memory rollback of the database, they
are limited to as many blocks as possible without exceeding the
limits set by -dbcache. The default of -dbcache=25 allows for some
150-200 blocks to be rolled back.
In case an error is found, the application quits with a message
instructing the user to restart with -reindex. Better instructions,
and automatic recovery (when possible) or automatic reindexing are
left as future work.
Initialize the OutputDebugStringF mutex and file pointer using
boost::call_once, to be thread-safe.
Make the return value of OutputDebugStringF really be the number of
characters written (*printf() semantics).
Declare the fReopenDebugLog flag volatile, since it is changed from
a signal handler.
And don't declare OutputDebugStringF() as inline.
If the user was really after the fastest possible confirmation times
they would be manually setting a fee. In cases where the wallet builds
a transaction with a priority that is too low to qualify as free until
the next block, go ahead without a fee. Confirmation frequently takes
multiple blocks even when a minimum fee is provided.
This avoids a potential crash when trying to read the scrippubkeys on
transactions where the first input IsMine but some of the rest are not
when running listaddressgroupings.
When the coin database is out of date with the block database, the
best block in it is automatically switched to. This reconnection
process can take time, so allow it to be interrupted.
This also stops block connection as soon as shutdown is requested,
leading to a faster shutdown.
This problem is like earth (mostly harmless). After/during a
-reindex, it means the statistics about the last block file
reported in debug.log are always of blk00000.dat instead of the
last file. Apart from that, it means a few more database entries
need to be read when finding a file to append to the first time.
