We were not previously triggering lookahead before calculating a Bloom filter, which means we might have missed transactions in some edge cases. Add a test to catch this and then fix up various unit tests to have fewer magic numbers and be more robust to changes.
For partial scriptSig OP_0 is used as a signature placeholder:
Pay-to-address: OP_0 [pubkey]
Pay-to-pubkey: OP_0
P2SH with 2-of-3 CHECKMULTISIG: OP_0 OP_0 OP_0 [redeem script]
Previously the codepath that was supposed to mark keys as used didn't work, and the lookahead calculation wasn't quite right. Now the current key advances correctly when an inbound tx is found that spends to it, including pending transactions. Additionally the lookahead zone now has the threshold zone after it, not inside it, meaning that if you request a lookahead size of 100 keys you'll actually always have at least 100 keys, never less.
addFollowingAccounts method now has the check that active keychain has no keys in use. This would prevent divergence of derivation paths for followed and following keys. In future this behaviour should be replaced with some sort of key rotation.
`parseCoin()` now accepts negative values; the check for an excessive
value is moved to the constructor from `parseCoin()` and uses
`checkArgument()`; some `Coin`-type constants broken out into one
`long` one `Coin` in order to be usable in the constructor.
Corresponding tests included. The `BitcoinURI` class constructor
throws exception on parsing a negative amount, which is needed now
that `Coin` class accepts negative amounts.
The 4294967295 number (0xffffffff) was incorrectly serialized because the UnsignedInteger.MAX_VALUE.longValue() helper returned 4294967295 instead of expected 4294967296.
The VarInt.sizeOf() incorrectly returned 9 instead of 5 for the 4294967295 (0xffffffff) number.
See https://en.bitcoin.it/wiki/Protocol_specification#Variable_length_integer
At the moment currentKeys map of KeyChainGroup is not restored after
deserialization and subsequent call to currentKey produces different
key then expected.
Proposed solution reconstructs currentKey map on deserialization using
stored numbers of issues keys. It is
not future-proof as it assumes only RECEIVE and CHANGE keys are being
used.
Bitcoinj can be crashed with OutOfMemory by sending a message with
a large claimed var_str length or bytes array length.
The actual message size does not matter, it's the claimed length that matters.
This affects all bitcoinj-based apps that receive messages including Multibit, Android Bitcoin Wallet, Mycelium and Hive.
The fix limits accepted length to max message size (32 MB).
Signed-off-by: Mike Hearn <mike@plan99.net>
