Transaction inputs are now prepopulated with empty scriptSig. Each signer
is expected to update this scriptSig with a signature at a proper place.
There is a new method in RedeemData to locate index of the key/signature
within scriptSig/program.
To generalize an above approach for all supported types of inputs,
RedeemData can now represent data for any type of input. For
pay-to-address and pay-to-pubkey inputs it is expected to contain single
key and CHECKSIG program.
Signers now accept ProposedTransaction object that could carry additional
metadata shared between signers. For now it shares derivation path of the
signing key.
To preserve the dummy sig feature, a new flag was introduced in a SendRequest.
It specifies whether to fill empty sigs with dummies during tx completion
or not. Default value is true (for backward compatibility).
There is a CustomTransactionSigner class that may be used as a base for
simple third-party signers (or may be not). It is used in unit test which
may be treated as a usage example.
In the end the API evolved in such a way that changing this param isn't that useful. To do contracts you tend to work with transactions directly, and a Wallet subclass that needs to do special signing by default can override the signing engine used.
Introduced pluggable signers notion. Instances of
TransactionSigner could be added into the wallet, so that they subsequently
applied to transaction to complete it.
Existing signing code (Transaction.signInputs) was refactored into
LocalTransactionSigner, which is always implicitly added to any wallet.
Related pull request: #157
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.
