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>
* Fixed toString() bug.
* Updated comments to match present Bitcoin Core behavior with respect to User-Agent.
* Removed constructor accepting a boolean. This changes public API but neither multibit
nor bitcoin-wallet nor mycelium nor hive-android uses this version of constructor.
The rationale is to avoid passing a boolean to a method as this makes code hard to read.
Client classes updated to preserve original semantic. All tests pass.
Script.<clinit> depended both on Script.<init> and NetworkParameters.<init> to prepare ScriptChunk cache.
At the same time NetworkParameters.<init> depended on Script.<clinit> by using Script.writeBytes().
The fix frees Script.<clinit> from both the NetworkParameters and Script objects.
This should remove the root cause behind NetworkParameters construction not being thread safe.
* This is intended to clarify distinction between full message and its payload to match terminology advertised on https://en.bitcoin.it/wiki/Protocol_specification.
* Does not change public API.
* These refactorings were mostly automated and should not introduce bugs. All tests pass.
If a Transaction contains a DeterministicKey of our
DeterministicKeyChains, then we should mark this key as issued. This can
happen, when we replay/resync the blockchain or when another device uses
one of our keys.
Signed-off-by: Harald Hoyer <harald@harald-hoyer.de>
DeterministicKeyChain.maybeLookAhead() would pre-generate a new key, for
every issued key, even if it is only one. If we replay the blockchain
and update the issuedKeys counter, maybeLookAhead() would trigger the
regeneration and resending of the bloom filter for every used key.
This patch adds a threshold, where keys are only pre-generated after
more keys are needed than the value of the threshold.
Signed-off-by: Harald Hoyer <harald@harald-hoyer.de>
