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.
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
Use 'osascript' to run AppleScript, instead of using (broken-in-10.8)
python appscript package.
And added support for code-signing the .app bundle, to make OSX's
GateKeeper happy.
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.
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.
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.
signrawtransaction was unable to sign pay-to-script-hash inputs
when given the list of private keys to use. With this commit
you can provide the p2sh redemption script in the list of
inputs.
Corrupt wallets used to cause a DB_RUNRECOVERY uncaught exception and a
crash. This commit does three things:
1) Runs a BDB verify early in the startup process, and if there is a
low-level problem with the database:
+ Moves the bad wallet.dat to wallet.timestamp.bak
+ Runs a 'salvage' operation to get key/value pairs, and
writes them to a new wallet.dat
+ Continues with startup.
2) Much more tolerant of serialization errors. All errors in deserialization
are reported by tolerated EXCEPT for errors related to reading keypairs
or master key records-- those are reported and then shut down, so the user
can get help (or recover from a backup).
3) Adds a new -salvagewallet option, which:
+ Moves the wallet.dat to wallet.timestamp.bak
+ extracts ONLY keypairs and master keys into a new wallet.dat
+ soft-sets -rescan, to recreate transaction history
This was tested by randomly corrupting testnet wallets using a little
python script I wrote (https://gist.github.com/3812689)
Before, opening a -datadir that was created with a new
version of Berkeley DB would result in an un-caught DB_RUNRECOVERY
exception.
After these changes, the error is caught and the user is told
that there is a problem and is told how to try to recover from
it.
Before, opening a -datadir that was created with a new
version of Berkeley DB would result in an un-caught DB_RUNRECOVERY
exception.
After these changes, the error is caught and the user is told
that there is a problem and is told how to try to recover from
it.
Gavin Andresen