New versions of OpenSSL will reject non-canonical DER signatures. However,
it'll happily decode them. Decode then re-encode before verification in order
to ensure that it is properly consumed.
Github-Pull: #5634
Rebased-From: 488ed32f2a
CWalletTx::AddSupportingTransactions() was adding empty transaction
to vtxPrev in some cases. Skip over these.
Part one of the solution to #3190. This prevents invalid vtxPrev from
entering the wallet, but not current ones being transmitted.
Versions of bitcoin before 0.8.6 have a bug that inserted
empty transactions into the vtxPrev in the wallet, which will cause the node to be
banned when retransmitted, hence add a check for !tx.vin.empty()
before RelayTransaction.
Use deleteLater() instead of delete, as it is not allowed
to delete widgets directly in an event handler.
Should solve the MacOSX random crashes on send with coincontrol.
Rebased-From: 6c98cca9e4
WalletView:
- add new signal showNormalIfMinimized()
- emit the new signal in handleURI() to fix a bug, preventing the main
window to show up when using bitcoin: URIs
Upstream: dbc0a6aba2
- fixes src\net.cpp:1601: Error:invalid conversion from 'void*' to
'const char*' [-fpermissive] in a setsockopt() call on Win32 that was
found by using MinGW 4.8.1 compiler suite
Changes the maximum size of a free transaction that will be created
from 10,000 bytes to 1,000 bytes.
The idea behind this change is to make the free transaction area
available to a greater number of people; with the default 27K-per-block,
just three very-large very-high-priority transactions could fill the space.
Remove the (relay/mempool) rule that all outputs of free transactions
must be greater than 0.01 XBT. Dust spam is now taken care of by making
dusty outputs non-standard.
As we'd previously learned, OSX's fsync is a data eating lie.
Since 0.8.4 we're still getting some reports of disk corruption on
OSX but now all of it looks like the block files have gotten out of
sync with the database. It turns out that we were still using fsync()
on the block files, so this isn't surprising.
After discussing with BlueMatt, this appears to be harmless in its
current state since it's always set before it's used. Initialize it
anyway for readability and future safety.
Rebased-By: Wladimir J. van der Laan <laanwj@gmail.com>
Rebased-From: 106f133de6
