Fixes for 0.8.1 release #2373

I intend these three commits, applied on top of the v0.8.0 tag, to be the 0.8.1 release.

The plan is:

• A new checkblock rule, in effect until 15 May, that ensure only blocks compatible with old releases are accepted into the main chain (only blocks that touch 4,500 or fewer distinct txids are allowed).
• A limit of 500k to blocks created, also in effect until 15 May.

Alerts will be sent to pre-0.8 releases over the next two months, telling people to either upgrade or create a DB_CONFIG file so they can handle large blocks. After May 15'th, blocks up to 1MB large will be allowed again.

Tested by syncing the entire main chain and the testnet chains. A unit test is included, but it only runs if you download the 900K forking block (see the comment in src/test/checkblock_tests.cpp ).

Automatic sanity-testing: FAILED BUILD/TEST, see http://jenkins.bluematt.me/pull-tester/298db97f231661a5cafab37dc9a591f1980b7f5a 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
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.

Pull-tester is upset because it creates a block (b39) that violates the new rule (it fills the block up to 1MB with abnormally tiny transactions that have scriptSig OP_1 and scriptPubKey OP_1). @TheBlueMatt : easiest fix, I think, would be to have pull-tester create blocks with timestamps from the past.

4,500 txids can easily break pre-0.8 clients if there's even a 1 block deep reorg, right? Since it isn't for very long, might it make sense to use a lower limit? (If this has already been discussed and resolved in my semi-absense, just let me know and I'll drop it)

No, not easily, because most transactions are duplicated between the two legs of most forks.

Longer forks are a risk, but are (happily) rare.

AIUI... even if both competing blocks were EXACT duplicates in terms of included transactions, they would still get a pre-0.8 node stuck in a reorg if the conflict-resolving block contained even as few as 165 transactions...?

I don't believe so: sipa's re-org code tries to resolve the conflict using as few blocks as possible.

Pre-0.6? 0.5? (I forget when the re-org code got smarter about making smaller transactions) nodes may get stuck; that is a good reason for them to patch or upgrade or workaround sooner rather than later.

I intend these three commits, applied on top of the v0.8.0 tag, to be the 0.8.1 release.

What's the third commit?

A 1-block-deep reorg requires 3 blocks in a single commit (not 100% sure on the last one): 1) undo stale block, 2) apply winner block, and 3) apply conflict-resolving block

@petertodd : third commit just bumps version numbers to '0.8.1', I removed it from this pull only because it doesn't merge cleanly with git HEAD. @luke-jr : deep re-orgs are definitely a theoretical problem, but we have to weigh two months of chronic unconfirmed transactions if we set the block size too small versus coddling people/services who won't upgrade or set their DB_CONFIG. Based on IRC conversation, I think the right thing to do is recommend setting DB_CONFIG for 120,000 locks instead of 50,000, although even that will cause problems for people running on low-memory VPS'es. But they should upgrade to 0.8 anyway to get much better performance...

I doubt 2,000 txids would cause much unconfirmed transactions, but whatever. ACK @ 120k locks DB_CONFIG, but think perhaps we should give a simple formula so admins can make their own informed decision. Obviously upgrading to 0.8 is the way forward, but a lot of people still have custom patching that may take a while to adapt.

Re the plan, I understand the 1st bullet point, but not the 2nd.. What is the reason for the 2nd please?

@gavinandresen Yea, the pulltester test was designed to trigger this case, I suppose it should be switched to do two such blocks, a must accept with a past timestamp and a must reject with a timestamp that triggers this rule.

@gavinandresen When is 0.8.1 scheduled? I'm asking, because we should update translations, if there is time left.

@gavinandresen If these are IN 0.8.1 why not merge it to current head?

Closing; I cherry-picked the final 0.8.1 versions of these.