Age | Commit message (Collapse) | Author |
|
This allows fun stuff such as `bitcoin --help | less`, and more
easy piping to files.
Looking at other tools such as bash, gcc, they all send their help
text to stdout.
|
|
|
|
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.
|
|
|
|
Fixed upstream in 8f10a2889089af1b2ac64802360494b54c8c7ff1.
|
|
Equivalent code. (false == 0 == DB_LOAD_OK). Fixes #1706.
|
|
|
|
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.
|
|
Upstream partials from 9e470585b35a84fcb7f6aa41ac0216c117e2a5e1, e679ec969c8b22c676ebb10bea1038f6c8f13b33, and 922e8e2929a2e78270868385aa46f96002fbcff3.
|
|
|
|
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.
|
|
Partial of upstream dae3e10a5abe93833c57183b7c00f1db9200f46e
|
|
|
|
|
|
|
|
(PARTIAL: Left out anything changing debug.log)
|
|
|
|
(PARTIAL cherry pick)
|
|
|
|
interval between subsidy reductions
|
|
Since the minimum signed integer cannot be represented as positive so long as its type is signed, and it's not well-defined what happens if you make it unsigned before negating it, we instead increment the negative integer by 1, convert it, then increment the (now positive) unsigned integer by 1 to compensate
|
|
As noticed by sipa (Pieter Wuille), this can happen when CBigNum::setint64() is
called with an integer value of INT64_MIN (-2^63).
When compiled with -ftrapv, the program would crash. Otherwise, it would
execute an undefined operation (although in practice, usually the correct one).
|
|
Bitcoin will not make an outbound connection to a network group
(/16 for IPv4) that it is already connected to. This means that
if an attacker wants good odds of capturing all a nodes outbound
connections he must have hosts on a a large number of distinct
groups.
Previously both inbound and outbound connections were used to
feed this exclusion. The use of inbound connections, which can be
controlled by the attacker, actually has the potential of making
sibyl attacks _easier_: An attacker can start up hosts in groups
which house many honest nodes and make outbound connections to
the victim to exclude big swaths of honest nodes. Because the
attacker chooses to make the outbound connection he can always
beat out honest nodes for the consumption of inbound slots.
At _best_ the old behavior increases attacker costs by a single
group (e.g. one distinct group to use to fill up all your inbound
slots), but at worst it allows the attacker to select whole
networks you won't connect to.
This commit makes the nodes use only outbound links to exclude
network groups for outbound connections. Fancier things could
be done, like weaker exclusion for inbound groups... but
simplicity is good and I don't believe more complexity is
currently needed.
|
|
|
|
|
|
|
|
|
|
|
|
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 was causing test_bitcoin to abort on a 32-bit system likely due to -ftrapv.
|
|
CBigNum::setint64() does 'n <<= 8', where n is of type "long long".
This leads to shifting onto and past the sign bit, which is undefined
behavior in C++11 and can cause problems in the future.
|
|
|
|
|
|
(this fixes a Mac OS X gitian build error for 0.5.x)
|
|
|
|
0.4.7rc1
|
|
verification uses the latter too
This caused clients to reject block #177618 since it has a P2SH transaction with over 200 bytes in scriptSig.
(Upstream commit: e679ec969c8b22c676ebb10bea1038f6c8f13b33)
|
|
|
|
Acquire an exclusive, advisory lock before sending output to debug.log
and release it when we're done. This should avoid output from multiple
threads being interspersed in the log file.
We can't use CRITICAL_SECTION machinery for this because the debug log
is written during startup and shutdown when that machinery is not
available.
(Thanks to Gavin for pointing out the CRITICAL_SECTION problems based
on his earlier work in this area)
|
|
|
|
|
|
Any problems seen during deserialization will throw an uncaught
exception, crashing the entire bitcoin process. Properly return an
error instead, so that we may at least log the error and gracefully
shutdown other portions of the app.
|
|
|
|
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.
|