stephenhutchings commented 3 Jul 2015, 6:35 GMT:
> Hi Luke, happy for these to be distributed under the terms of the MIT licence.
> Let me know if you need anything further from me.

dae0a89 assets-attribution: Update typicons to MIT license (Luke Dashjr)

9a2469e release notes for fee estimation changes (Alex Morcos)

5460b24 Fix typo in release notes. (spin)

Encapsulate mapNodeState in a smart-pointer class with its own lock.

Why? So Misbehaving() can be called from the sanity-check-a-message code without holding cs_main.

And to get better exception safety (the smart-pointer approach gives RAII semantics).

And because protecting fewer things with cs_main is a good idea.

Tested by compiling with -DDEBUG_LOCKORDER, running all of the qa/rpc-tests, and running a node on the main network overnight.

I need this to write some unit tests for the
CNode::ReceiveMsgBytes() function.

New, undocumented-on-purpose -mocktime=timestamp command-line
argument to startup with mocktime set. Needed because
time-related blockchain sanity checks are done on startup, before a
test has a chance to make a setmocktime RPC call.

And changed the setmocktime RPC call so calling it will not result in
currently connected peers being disconnected due to inactivity timeouts.

Blocks generated in -regtest mode would pay to a key that was left
in the keypool, which can cause subtle bugs. In particular, I expected
every block generated to be unique, but got duplicate blocks between
calls to setgenerate.

Fixes Bitcoin Core issue 6268.

Unit test and code for a bigger-block hard fork.
Parameters are:
  8MB cap
  ... doubling every two years (so 16MB in 2018)
  ... for twenty years
  ... earliest possible chain fork: 11 Jan 2016
  ... after miner supermajority
  ... and grace period once miner supermajority achieved

qa/rpc-tests/bigblocks.py mines a 50% upgraded -regtest chain,
generates 4MB of transactions, and then tests the upgrade and
mining code to make sure larger blocks are only created when
the fork conditions are met.

The activation state of the fork is stored in the block tree database;
it is written when the threshold is met (and unwritten if the
threshold block is re-orged out of the best chain), and read at startup.

Code review and bug fixes by Mike Hearn.

…hed.

…fault.

This avoids the situation that has happened several times where the network starts running out of capacity and miners must be manually contacted in a rush to tell them about the command line flag.

…m this point on all changes will be triggered by a bit in nVersion rather than an incrementing integer.

Adds a BlockValidationResourceTracker class that is passed to
CheckInputs() / CScriptCheck() to keep track of the exact number
of signature operations required to validate a block, and the
exact number of bytes hashed to compute signature hashes.

Also extends CHashWriter to keep track of number of bytes hashed.

Intended to be the starting point for consensus rule changes
to replace the incorrect, messy sigop counting and size-limiting
rules currently in place.

Replace the inaccurate / somewhat ineffective consensus rule for
number of signature operations per block with new consensus rules
that accurately count the number of ECDSA signature operations needed
to validate a block, and the number of bytes of data needed to compute
signature hashes (to mitigate the attack described in CVE-2013-2292).

BIP number for this to be determined. Constants were chosen such that
any 'non-attack' transaction valid under the old rules is also valid
under the new rules, but maximum possible block validation times
are well-bounded, but tied to block size increases.

Summary of old rules / new rules:

Old rules: 20,000 inaccurately-counted-sigops for a 1MB block
New: 80,000 accurately-counted sigops for an 8MB block

A scan of the last 100,000 blocks for high-sigop blocks gets
a maximum of 7,350 sigops in block 364,773 (in a single, huge,
~1MB transaction).

For reference, Pieter Wuille's libsecp256k1 validation code
validates about 10,000 signatures per second on a single
2.7GHZ CPU core.

Old rules: no limit for number of bytes hashed to generate
signature hashes

New rule: 1.3gigabytes hashed per 8MB block to generate
signature hashes

Block 364,422 contains a single ~1MB transaction that requires
1.2GB of data hashed to generate signature hashes.