Add a new checkpoint at block 295,000

[trevinhofmann]

Block 295,000 seems to meet the criteria of a reasonable timestamp and
no strange transactions. 295,000 is the current block height in the
bootstrap.dat torrent provided by jgarzik.

[BitcoinPullTester]

Automatic sanity-testing: FAILED BUILD/TEST, see http://jenkins.bluematt.me/pull-tester/p4541_125fba1b482997f13b5eec6b24d634adda4f91e7/ for binaries and test log.

This could happen for one of several reasons:

1. It chanages paths in makefile.linux-mingw or otherwise changes build scripts in a way that made them incompatible with the automated testing scripts (please tweak those patches in qa/pull-tester)
2. It adds/modifies tests which test network rules (thanks for doing that), which conflicts with a patch applied at test time
3. It does not build on either Linux i386 or Win32 (via MinGW cross compile)
4. The test suite fails on either Linux i386 or Win32
5. The block test-cases failed (lookup the first bNN identifier which failed in https://github.com/TheBlueMatt/test-scripts/blob/master/FullBlockTestGenerator.java)

If you believe this to be in error, please ping BlueMatt on freenode or TheBlueMatt here.

This test script verifies pulls every time they are updated. It, however, dies sometimes and fails to test properly. If you are waiting on a test, please check timestamps to verify that the test.log is moving at http://jenkins.bluematt.me/pull-tester/current/
Contact BlueMatt on freenode if something looks broken.

[laanwj]

$ for i in {294990..295011} ; do echo -n $i; cli getblock $(cli getblockhash $i) | grep time; done
294990    "time" : 1397075456,
294991    "time" : 1397075731,
294992    "time" : 1397076248,
294993    "time" : 1397076552,
294994    "time" : 1397077330,
294995    "time" : 1397078005,
294996    "time" : 1397079260,
294997    "time" : 1397079338,
294998    "time" : 1397079914,
294999    "time" : 1397079977,
295000    "time" : 1397080064,
295001    "time" : 1397080132,
295002    "time" : 1397080804,
295003    "time" : 1397080796,  # (decreases from 295002!)
295004    "time" : 1397081482,
295005    "time" : 1397082215,
295006    "time" : 1397082919,
295007    "time" : 1397083812,
295008    "time" : 1397084101,
295009    "time" : 1397084269,
295010    "time" : 1397084806,
295011    "time" : 1397084952,

Block 295003 has an earlier timestamp than 295002, is this a problem?

I don't think so, as there is no block after 295000 with a timestamp before 1397080064, and no block after 295000 with a timestamp before 1397080064, but with a non-monotonically-increasing timestamp so closeby I'd thought I'd ask.

[gavinandresen]

Strictly speaking, as long as all blocks before the checkpoint have a timestamp before it, and all blocks after have timestamps after, all is OK.

[jgarzik]

heh I think people are getting impatient for a new torrent ;p I'll roll one.

[laanwj]

OK, ACK

[petertodd]

NACK

Checkpoints only exist to solve a DoS attack during initial sync. The previous checkpoint has a difficulty more than high enough to make that DoS attack extremely expensive to pull off, and it's a continual source of confusion as to the actual security model of Bitcoin.

It's about time we stop updating them every release.

[sipa]

I hope that after headers-first we can get rid of checkpoints entirely (or at least replace them by something that doesn't actually constrain the chain), by replacing the no-sigchecks-before-last-checkpoint with no-sigchecks-if-buried-by-enough work. Until then, they're unfortunately more than just a DoS attack protection, but also a synchronization optimization...

[laanwj]

@petertodd I agree with you in principle, however, as long as we still maintain these checkpoints it's better to keep them up to date.