An attempt to fix bug tx confirmation window is getting out of the screen and can't click on "send" by setting a maximum of 45 characters to not wrap lines in the label and be able to add ... if the size exceeds that.
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.
- 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>
While working with other networking code, Patrick and I noticed that we
use signed types and wrongly-sized types for several networking related
values, including data lengths, timeout durations, and port numbers.
This commit corrects several of these types and improves error handling
slightly to account for potentially invalid values.
- Removes hard coded GZIP_ENV because this is now handled properly
by gitian.
- Removes target '.mm.o' because that was needed for XCode <= 4.2
Cherry-picked from: f8c6697
Omitted all unmaintained dialects unless there only is a dialect.
Excluded files:
- bg_BG -> bg
- ca@valencia and ca_ES -> ca
- el_GR -> el
- es_AR, es_CL, es_CO, es_DO, es_ES, es_MX, es_UY and es_VE -> es
- et_EE -> et
- fa_IR -> fa
- fr_CA and fr_FR -> fr
- ro_RO -> ro
- ru_RU -> ru
- tr_TR -> tr
- vi_VN -> vi
- zh and zh_HK -> zh_CN
While limitations on the influence of attackers on addrman already
exist (affected buckets are restricted to a subset based on incoming
IP / network group), there is no reason to permit them to let them
feed us addresses at more than a multiple of the normal network
rate.
This commit introduces a "token bucket" rate limiter for the
processing of addresses in incoming ADDR messages. Every connection
gets an associated token bucket. Processing an address in an ADDR
message from non-whitelisted peers consumes a token from the bucket.
If the bucket is empty, the address is ignored (it is not processed,
stored or forwarded). The token counter increases at a rate of 0.1
tokens per second, and will accrue up to a maximum of 1000 tokens
(the maximum we accept in a single ADDR message).
When a GETADDR is sent to a peer, it immediately gets 1000 additional
tokens, as we actively desire many addresses from such peers (this
may temporarily cause the token count to exceed 1000). This is
similar to allowing bursts.
The rate limit of 0.1 addr/s was copied from Bitcoin Core.
Backported from: 0d64b8f7, 5648138f, f424d601 and d930c7f5
Original authors: Pieter Wuille <pieter@wuille.net>, and
Jon Atack <jon@atack.com>
Qt wallets display information to users about the broadcast state
of transactions, without truly knowing the actual state. The fact
that a peer has requested details for a transaction does not mean
it was accepted to their mempool or relayed to any other peers and
miners, because the only way to test if the transaction can be
accepted is by requesting and processing it.
We remove the "offline" and "maturity warning" statuses, which
saves large wallets memory and processing time.
Backported from: beef7ec4
Original author: Matt Corallo <git@bluematt.me>
Each node keeps a registry of manually added nodes (through the
addnode parameter, rpc call or UI) but there are currently no
limits imposed on that usage, which is a bit sloppy and can lead
to situations where memory is being used for storing addresses
that are never connected to, because the maximum number of
connections used for addnode entries is hardcoded as 8. This
could prevent smaller systems that host nodes (like those
running on an ARM SoC) to optimally use the available memory.
This enhancement limits the addnode functionality as follows:
1. Whenever over 799 nodes are added to the registry, require
the user to remove an entry before a new one can be added
2. Disallow very large addresses (more than 256 characters).
This limit provides for at least 4 levels of subdomains as
specified under RFC1035.
See https://datatracker.ietf.org/doc/html/rfc1035#section-2.3.1
Verification levels must be between 0 and 4 inclusive, and block heights should
always be positive. While code in the scan process handles the latter case with
a default value, it's better to verify and reject invalid input where it first
enters the system.
