| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
Matt pointed out some time ago that there existed a minor DOS
attack where a node in its initial block download could be wedged
by an overwrite attack in a fork created between checkpoints before
a time where BIP30 was enforced. Now that the BIP30 timestamp
is irreversibly past the check can be more aggressive and apply to
all blocks except the two historic violations.
|
|
Conflicts:
bitcoin-qt.pro
doc/README
doc/README_windows.txt
share/setup.nsi
src/serialize.h
|
|
Conflicts:
contrib/Bitcoin.app/Contents/Info.plist
doc/README
doc/README_windows.txt
share/setup.nsi
src/serialize.h
|
|
Hard-code a special nId=max int alert, to be broadcast if the
alert key is ever compromised. It applies to all versions, never
expires, cancels all previous alerts, and has a fixed message:
URGENT: Alert key compromised, upgrade required
Variations are not allowed (ignored), so an attacker with
the private key cannot broadcast empty-message nId=max alerts.
|
|
This fixes two alert system vulnerabilities found by
Sergio Lerner; you could send peers unlimited numbers
of invalid alert message to try to either fill up their
debug.log with messages and/or keep their CPU busy
checking signatures.
Fixed by disconnecting/banning peers if they send 10 or more
bad (invalid/expired/cancelled) alerts.
|
|
|
|
Conflicts:
src/main.cpp
|
|
|
|
Conflicts:
src/main.cpp
|
|
If 950 of the last 1,000 blocks are nVersion=2, reject nVersion=1
(or zero, but no bitcoin release has created block.nVersion=0) blocks
-- 75 of last 100 on testnet3.
This rule is being put in place now so that we don't have to go
through another "express support" process to get what we really
want, which is for every single new block to include the block height
in the coinbase.
|
|
"Version 2" blocks are blocks that have nVersion=2 and
have the block height as the first item in their coinbase.
Block-height-in-the-coinbase is strictly enforced when
version=2 blocks are a supermajority in the block chain
(750 of the last 1,000 blocks on main net, 51 of 100 for
testnet). This does not affect old clients/miners at all,
which will continue producing nVersion=1 blocks, and
which will continue to be valid.
|
|
|
|
Conflicts:
doc/unit-tests.txt
|
|
|
|
|
|
|
|
Conflicts:
src/key.h
src/keystore.h
src/net.h
src/protocol.cpp
src/qt/guiutil.h
src/test/DoS_tests.cpp
|
|
Conflicts:
src/net.cpp
|
|
(PARTIAL: Left out anything changing debug.log)
|
|
|
|
|
|
interval between subsidy reductions
|
|
Conflicts:
doc/unit-tests.txt
src/serialize.h
|
|
Conflicts:
src/main.cpp
src/serialize.h
|
|
|
|
Remove orphan transactions from memory once
all of their parent transactions are received
and they're still not valid.
Thanks to Sergio Demian Lerner for suggesting this fix.
|
|
Loop over all inputs doing inexpensive validity checks first,
and then loop over them a second time doing expensive signature
checks. This helps prevent possible CPU exhaustion attacks
where an attacker tries to make a victim waste time checking
signatures for invalid transactions.
|
|
Changes suggested by Sergio Demian Lerner to
help prevent potential DoS attacks.
|
|
(this fixes a Mac OS X gitian build error for 0.5.x)
|
|
(this fixes a Mac OS X gitian build error for 0.5.x)
|
|
Conflicts:
src/main.h
src/net.cpp
src/serialize.h
|
|
(Partial/merge of upstream 9247134eaba9a1d0fa74f22de238af1476663005, 1a3f0da9229a8e524d1010cdc8bd3b9da71fe529, and 3e343522226e6c249f5cb05436eec347b87c6361)
|
|
Conflicts:
src/main.cpp
|
|
Conflicts:
src/ui.cpp
src/ui.h
src/uibase.cpp
src/xpm/about.xpm
|
|
|
|
I originally created a pull to replace the "COPYING" in crypter.cpp and
crypter.h, but it turned out that COPYING was actually the correct
file.
|
|
I originally created a pull to replace the "COPYING" in crypter.cpp and
crypter.h, but it turned out that COPYING was actually the correct
file.
|
|
I originally created a pull to replace the "COPYING" in crypter.cpp and
crypter.h, but it turned out that COPYING was actually the correct
file.
|
|
(PARTIAL of 966ae00)
|
|
|
|
PARTIAL, since d68dcf7 isn't backported (yet)
|
|
Immediately issue a "getblocks", instead of a "getdata" (which will
trigger the relevant "inv" to be sent anyway), and only do so when
the previous set of invs led us into a known and attached part of
the block tree.
|
|
Pull request #948 introduced a fix for nodes stuck on a long side branch
of the main chain. The fix was non-functional however, as the additional
getdata request was created in a first step of processing, but dropped
in a second step as it was considered redundant. This commits fixes it
by sending the request directly.
|
|
|
|
Pull request #948 introduced a fix for nodes stuck on a long side branch
of the main chain. The fix was non-functional however, as the additional
getdata request was created in a first step of processing, but dropped
in a second step as it was considered redundant. This commits fixes it
by sending the request directly.
|
|
In cases of very large reorganisations (hundreds of blocks), a situation
may appear where an 'inv' is sent as response to a 'getblocks', but the
last block mentioned in the inv is already known to the receiver node.
However, the supplying node uses a request for this last block as a
trigger to send the rest of the inv blocks. If it never comes, the block
chain download is stuck.
This commit makes the receiver node always request the last inv'ed block,
even if it is already known, to prevent this problem.
|
|
|
|
|
