I'm writing some wallet regression tests using -regtest mode, and
need to generate an initial multi-hundred-block chain. Repeatedly
calling setgenerate to generate one block is slow and doesn't
work properly, because block creation happens asynchronously.
This adds two features to setgenerate in -regtest mode:
1) Instead of being interpreted as number of threads to start, the
third argument is the number of blocks to generate.
2) setgenerate will not return until the block creation threads
have created the requested number of blocks.
Use misc methods of avoiding unnecesary header includes.
Replace int typedefs with int##_t from stdint.h.
Replace PRI64[xdu] with PRI[xdu]64 from inttypes.h.
Normalize QT_VERSION ifs where possible.
Resolve some indirect dependencies as direct ones.
Remove extern declarations from .cpp files.
This changes the priority calculation to not include the size of per-txin
data including up to 110 bytes of scriptsig so that transactions which
sweep up extra UTXO don't lose priority relative to ones that don't.
I'd toyed with some other variations, but it seems like any formulation
which results in an incentive stronger than making them not count will
sometimes create incentives to add extra outputs so that you have
extra inputs to consume later. The maximum credit is limited so that
users don't lose the disincentive to stuff random data in their
transactions, the limit of 110 is based on the size of a P2SH
redemption with a compressed public key.
This shouldn't need a staged deployment because the priority is not
used as a relay criteria, only a mining criteria.
Gavin Andresen