The system writes a new file every single run (provided new headers were
received) and we sometimes compact them into a big file again.
The code forgot to remove the newly introduced info files of the old
files it compacted. Leaving confusing things happening after.
This solves that by making the first run remove all info files and re-
build them, adding a version byte to allow us freedom to do that in the
future again.
The bchd seed owner says that since there are no bchd nodes on main-chain
due to the code being outdated, the seed is empty.
We hope this will change in the future, but for now it makes no sense to
query it since it will just generate a fail.
This improves several corner cases on detecting if a peer we
are requesting headers from is actually giving them to us.
Specifically, the height could be zero for a genesis-only view, which
caused the detection to always give the higest score (height zero is
seen as special).
After a node is disconnected we now also reset the history in order to
let the new node get measured from only its own performance.
We optimistically create a new info file but as we start we might
instantly realize the file is useless and give up before having written
a single byte.
We now remove that file to avoid stale state.
Also be more verbose on warnings.
The blockchain class can effectively now be shallow,
we can have a list of blockheaders of, for instance, the last year
alone. It builds on top of a known checkpoint (hardcoded block data)
and as long as we do not access block info that is unavailable, things
just work like normal.
We throw at the request of a blockheader that is too old.
Should the peer have been rejected on status or similar, we don't
register a successful connection and avoid the peer from being selected
again since then we don't remove the punishment done on connection
start.
This changes the SPV action to not actually exit when sync
is completed, but instead keep running in the background
so it will detect when a wallet loses a peer and reinstate one.
The methodname:
blockHeightAtTime()
makes the reader think about the actual height of the chain at that
time. Returning that value until the timestamp of the next block is
reached.
Now the method actally returns that number.
The code does not do any work to account for blocks going backwards in
time compared to the block before.
We removed the default value in order to avoid misusage of the method
and mistaking the amount with the connection-id.
From Peer we now se the faster overload of punish(), avoiding looping
through the peer list.
Also check return-code when needed.
The PeerAddressDB keeps a score for each IP/port we have about how
useful that peer is.
This change re-visits the way we use the DB where we now are more fluid
in our approach to scores. We no longer simply forever-ban a peer after
it made a mistake once.
This rewrites the select-a-peer algo to take timing into account,
preferring a peer that we connected to recently while putting a higher
score on a peer that failed a long time ago so if we start running out
of good peers we start on the not-so-great-but-maybe-improved first.
Good behavior is likewise rewarded so a peer can become higher prio
again, but generally a new IP still gets preferred. Again, the balance
is to keep not-so-great options in the running.
as the max number of headers is 2000, we should avoid asking any peers
for this data before we are close enough to the tip for it to be easy to
verify as correct.
Peers take a good amount of time to respond, so wait longer before
connecting to a different peer.
We now wait 60 seconds before creating more connections.
This removes a premature optimization where we avoid hashing the header
in the small case that the interface doesn't actually find any useful
transactions in the block.
It hurts others calling this API, though, as they suddenly need access
to the full header instead of just the blockId.
Every peer that we connect to should get the bloom filter set and it
should also get the 'mempool' call sent once which will make that peer
respond with all matches of the bloom filters which are in the mempool.
The tricky part is that we should have the latest bloom filter set on
each of those peers before the mempool is sent, since they work
together.
Also if we are behind, the mempool should not be sent. (It can cause
problems in the wallet if we receive unconfirmed transactions before
mined transactions)
So, when a peer starts downloading merkle blocks, the bloom filter of all
the other peers becomes invalid the moment a match is found by an actual
wallet.
This is Ok on one peer because the merkleblock automatically updates the
filter on match on the server side, but obviously not on the other peers
we have for that wallet.
The approach we follow is that as soon as a sync-run is done on a single
peer (we do a main and also a backup sync), we tell the wallet to re-
build its bloom filter for _all_ peers and if the sync that peer did
leads us to be at the chain-tip, we also send each peer the mempool
command.
When the SyncChainAction was written, various interactions we do
today in the ConnectionManager did not happen yet. Features in
Peer didn't exist yet.
This updates the SyncChainAction to take those items into account
and be more responsive and conclue we are 'up to date' faster,
while also leaving behind a better state.
To enable this means the buildsystem will build all the applications
as well as the libraries.
Applications are 'hub' / 'txVulcano' / 'indexer' etc.
Default this one is turned off.
When we receive a known message (currently just avahello) we now
intantly ban and disconnect the peer, no need to
test compliance when they openly greet us saying they are not following
the same chain.
tomFlowee