- Mishaboar was listed twice because of capitalization
- Added all reviewers
- Fix description of traffic graph improvement
- Added portuguese translation and contributors
- Added bulgarian translation and contributors
Minor updates to portuguese from portugal translation, and finished translated 100% of the rest of the file.
this new was made to be able to run sucessful all tests do to my error on (https://github.com/dogecoin/dogecoin/pull/3028)
Applied some suggestions and corrections from @justAndrea1111
ed7d266dcbd8bb8af80f9ccb8deb3e18f9cc3f6972912680feeb37b090f8cee0 is
the new mainnet checkpoint at height 4303965, with a total tx count
of 86433645.
Calculated the tx volume between block 3793538 and 4288126 which is
exactly 1 year of volume.
Cumulative chainwork is 0x07dc8ab65fc32f953c4a
---
af23c3e750bb4f2ce091235f006e7e4e2af453d4c866282e7870471dcfeb4382 is
the new testnet checkpoint at height 3976284, with a total tx count
of 5353803.
The tx volume did not significantly change (0.024 to 0.026) so that
remains unchanged.
Cumulative chainwork is 0x3e3c33bc605e5d
- removes defunct mainnet seeds
- adds newly discovered seeds, top 80% of observed uptime
- filters out all nodes with version 1.14.0-1.14.2 because these
cause sync issues for connecting peers
Add a unique suffix to the IPC server name before hashing, to avoid
things like network collisions or attempts to reuse old sockets on
restart.
Remove now-superfluous code that removed the old socket after a crash.
Tests 5 scenarios for transaction download scheduling:
1. Whether eventually, after a series of timeouts, all our peers
that announced a transaction are sent a getdata request
2. Whether outbound peers are prioritized over inbound peers when
a getdata request takes longer than optimal
3. That we honor the maximum in-flight capacity, that this is on
a per-peer basis and that it resets itself after timeout
4. That when we have an inflight getdata request when a peer
disconnects, we recover after the initial 30 second timeout
and fetch the transaction from another peer
5. That we recover after a peer sends us a notfound message for
a tx we had an inflight getdata request for.
- Lower the timeout until we will request a transaction from an
additional peer on top of the one we received an inv from, from
1 minute to 30 seconds. Waiting a full minute will often mean
that the transaction will skip 2 blocks (one that is currently
templated, and the one that we'd make a minute after that.
This allows the transaction to at least have a chance to be
included in the next block template.
- (Inferred) lower the timeout between requesting and receiving a
transaction from 10 minutes to 5 minutes. We keep the multiplier
from Bitcoin Core of 10x the re-request timeout, to allow faster
cleanup of stale requests when 2 peers have a slow connection.
- Change the frequency of checking timeouts from once every 10
minutes, to once every 90 seconds, on average. We randomize this
check to be performed every 60-120 seconds. This allows the node
to be triggered into cleanup more frequently and with that also
helps towards the goal of faster cleanup of stale requests.
Changes all timing around when we send inv messages to our peers to
be mockable with setmocktime (on regtest.)
This is needed for testing transaction scheduling in time that is
faster-than-real.
- Add an explicit memory bound to m_tx_process_time
Previously there was an implicit bound based on the handling
of m_tx_announced, but that approach is error-prone
(particularly if we start automatically removing things from
that set).
- Remove NOTFOUND transactions from in-flight data structures
This prevents a bug where the in-flight queue for our peers
will not be drained, resulting in not downloading any new
transactions from our peers.
- Expire old entries from the in-flight tx map
If a peer hasn't responded to a getdata request, eventually
time out the request and remove it from the in-flight data
structures. This is to prevent any bugs in our handling of
those in-flight data structures from filling up the
in-flight map and preventing us from requesting more
transactions (such as the NOTFOUND bug mentioned above).
- Fix bug around transaction requests
If a transaction is already in-flight when a peer announces
a new tx to us, we schedule a time in the future to
reconsider whether to download. At that future time, there
was a bug that would prevent transactions from being
rescheduled for potential download again (ie if the
transaction was still in-flight at the time of
reconsideration, such as from some other peer). This fixes
that bug.
- Improve NOTFOUND comment
Cherry-picked from: 218697b6, 23163b75, e32e0840, f635a3ba
and 308b7673
Co-authored-by: Anthony Towns <aj@erisian.com.au>
