Since a core feature of NotificationListener is to combine many
notification objects into one, we now changed the app-private
wallet-transaction-id to be a list instead of a singular item.
This allows the combined set of notifications to not have lost
the actual reference to the underlying individual transactions.
Setting the "LowPower" mode on the main DownloadManager class will
cause it to halt all network activity and jobs will die.
You can revive it by changing it to NormalPower and optionally calling
the start() method to restart all jobs.
We always need two random peers to download a certain merkle block, to
avoid the withholding attack.
It occurred to me that there is no need to do them one after the other,
they can both run in parallel without issues. Saving time.
Also use the more appropriate lock_guard for mutex usage.
And I noticed that in the NotificationCenter we assumed a callback would
be able to unregister itself, which requires a recursive mutex. As such
the mutex has now been elevated to be such.
Negative ban scores are a bit annoying since when a user bans the node
it gives a 1000 point punishment, assuming that this will make the ban
score be above the 1000 point limit which implies banned.
This is an abstract class that the application using this library needs
to subclass. Ownership and lifetime don't change, it still lies with the
app using the library and they still need to add and remove it from the
connectionManager, but this makes it much more stable for multi-
threading environments and avoids issues on misuse.
The checkpoints were formerly copied from the full node, so based
on possible fork-events.
That seems less useful nowadays and since we want to be able to
allow starting a blockchain instance from any checkpoint it makes
sense to spread them out more evenly.
Based on the concept that the BCH chain generates around 50K blocks
a year, we simply use that interval.
This removes various very old ones meaning that the total count is
roughly equal.
This improves the docs, adds a getter and last it makes the
blockHeightAtTime() more secure by not returning a value below the
checkpoint. As this would throw if used directly in the block() method.
This public method allows an application to replace the static-
header files in a life-situation. Without needing to restart the app.
The idea is that a static chain starts at a checkpoint, and we extend
it into the past to start at an earlier checkpoint. This suddenly
makes available a larger amount of history without changing anything
of the data that was already there.
The blockchain object holds all block-headers, the backing store for
this class is now being exposed more to allow understanding what we have
or not have available. And also what the source of that info is.
The download from a peer is now limited to just 4000 blocks, at which
point the download proceeds from another peer.
Naturally it can go back to the first afterwards too.
The idea is that we download a month worth of blocks at a time and then
fetch the same blocks from a backup peer in order to be certain we
actually see the real state.
The problem we've seen is that after the first downloads we end up
starting the second and if the initial sync or a similar large download
happens, many people won't leave it running until the backup actually
completes since the UI looks like its finished.
This is also a good starting point for rating peers at download speed by
having predictable chunks and that means we could time and aim to use
the faster peers.
This is becoming relevant as we can see a huge difference where peers
give you 10x performance compared to some of the slower ones.
If between the first peer finishing downloading and the second
finishing downloading a block was mined, we need to pick a different
peer for the block the first one didn't download.
With the expansion of the database more agressive, checking a
larger set of peers for one that works becomes more important, as
such open more connections ever cycle if we can't find good ones
after half a minute.
With the expansion of the database more agressive, checking a
larger set of items for the best one becomes more important, as
such do a 10x for finding the best sccoring item.
The observed effect is finding previously useful peers within seconds
instead of a minute.
When our addresses database is filled with old or wrong addresses, we
end up trying to connect to a large number of IPs before we find actual
peers.
When we see that is the case, let's try to find more IP addresses from
our peers.
tomFlowee