This happens if the store is relatively fresh and has not yet fully wrapped
around at least once. Thus, entire entries of the ring buffer are still
zeroed, and in particular the hash field of store entries will be zero. In
consequence, get() is locating and returning an invalid block when asked to
look for the zero hash.
Valid blocks that hash to zero will require an astronomical amount of
mining. So we fix this bug by hardcoding the zero hash to never be found in
our store.
Includes a test for this edge case.
It's always
```
Download peer died. Picking a new one.
Unsetting download peer: <peer>
Setting download peer: <peer>
```
So the first message can go away.
Because tweaking is necessary for transaction signing, these usages
have been changed to produce new inputs instead and replace them in
transactions as needed.
Because tweaking is necessary for transaction signing, these usages
have been changed to produce new inputs instead and replace them in
transactions as needed.
Because tweaking is necessary in cases like unit tests, these usages
have been changed to produce new inputs instead and replace them in
transactions as needed.
Because tweaking is necessary for fee calculation logic, these usages
have been changed to produce new TransactionOutputs instead and
replace them in transactions as needed.
Pushing an empty data is *not* a no-op: an item is added to the
stack. So that empty array should be represented in the data
part of the script chunk.
This makes behaviour consistent with script parsing, and input
signing expects the empty array as a placeholder for a missing
signature.
This reverts 07682145e3 from 2015!
Also adds a test.
Deprecate write(OutputStream) and replace with existing
toByteArray() method. Internally implement a write(ByteBuffer) method.
Update Script to use chunk.toByteArray().
Release 0.17 was the transition release to allow users
to migrate from ListenableFuture to CompletableFuture.
In Release 0.18 we are removing ListenableCompletableFuture and
ListenableCompletionStage and changing method signatures to
return CompletableFuture.
This is technically a breaking change and, of necessity, we weren't
able to mark everything that is going away as "deprecated", but
we did put a special notice in the 0.17 release notes and the migration
should not be too difficult.
If we deprecate these two classes, there will be no way for callers to
get rid of the deprecation warnings.
Instead, I've added **bolded** warnings in the JavaDoc for each class
**and** deprecated all their methods.
I also removed the "When the migration is finished" paragraphs in the
JavaDoc.
