- 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
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.
- improves conciseness of tips displayed in Qt
- makes the function of the reset button on the importkeydialog
describe reality
- describe alertnotify to match the new reality after 565280f4
- make sure that "koinu" is not expressed as "koinus"
- fix type in advanced send screen
This adds more defensiveness around dumping or backing up wallets, so
that the directory and filepaths are always available (even if they were
on transient storage that was removed), and that they never overwrite
other files.
This allows users to set the directory in which to store backups and
datadumps. If not provided, defaults to a subdirectory of `datadir`
called `backups/`, and if that cannot be created, defaults to `datadir`.
While looking at the network code, we realized this code is unused and
largely unmaintained. Given issue #2231, and its removal in 1.21, it's
time to remove it now.
This has the nice benefit of removing a single point of failure/control
(because it depends on a keypair to send alerts).
This code restores the pre-alert behavior before the merge of PR #1470.
See #2523, a request not to drop data when changing the time scale of
the graph.
This change includes several components performed by @michilumin:
* allows resampling and data retention
* separates data from visual sample stores on the graph
* uses averages instead of maximums for samples
* improves timing accuracy
Co-authored-by: Michi Lumin <michi@luskwood.org>
Throughout the code, we use mockable time in places where we want
to test things that are subject to timing constraints, but don't
want to wait for great amounts of time when we use the regtest
network to ensure nothing gets broken. Mockable time is a system
time override that is only enabled on chains that have the
fMineBlocksOnDemand parameter set (currently: regtest).
Currently, only time expressed in seconds is able to be mocked, but
we have a couple of places where time is evaluated in microseconds,
one of them being the time between sending out addr messages.
This introduces a mockable time in microseconds and refactors the
time evaluation for addr messages to be mocked, so that we can
more reliably (and faster) test that.
Other protocol features may want to use this too, but currently the
sending of addr messages is the only place we test. Bitcoin Core
nowadays has a much better time system that we inherit in future
versions, but for the current scope I found this not worth the
effort of backporting, as these would impact a much larger part of
the code base.
Inspired by: 1a8f0d5a from Amiti Uttarwar
The algorithm here is important and took some time to get right. Instead
of comparing whether the current number of connected nodes minus the
number of unevictable nodes is greater than the number of max
connections, check that:
* there are any evictable nodes (connected nodes minus unevictable
nodes)
* there are more nodes connected than requested (connected nodes minus
max connections)
While we could wait for nodes to disconnect organically, it's more
important to run the eviction logic frequently enough that we can tell
when it will have an effect.
Whitelisted connections and protected inbound connections are
unevictable, and max connections should account for inbound connections.
Because the evictor will never evict protected inbound connections, the
maximum connection count should always be at least as large as the
protected connection count.
Note that the tests for this use a delay and test that the delay has not
expired. This helps improve determinism in the testing. Otherwise, a
strict test for a fixed number of disconnections is susceptible to
things like CPU jitter, especially when running through CI.
Patrick ran this test for 1000 runs on busy CPUs and saw no failures.
This uses the constant in src/net.h for the minimum allowed number of
connections.
The limit of new max connections is silently capped to the number of
available file descriptors. This value is not exposed in the UI or
RPC messages so as not to leak interesting or important system details.
The floor of maximum connections is set to the number of connections
required for this node to operate.
This makes the best attempt to reduce the number of connections by
reusing the eviction logic. This reuses the core of that algorithm at
the expense of deterministic behavior. In other words, starting with a
max connections value of 125 and then changing the max connections to 3
does not mean that this will immediately evict 122 connections.
Eventually the number of connections will reduce to the limit.
While the body of the condition will add latency to network processing,
the integer comparison between max connections and size of the
connections vector should be quick in most cases.
Note the extraction of connection disconnect/delete helpers so as to
reuse the same logic in multiple places. While this may not be strictly
necessary for the algorithm, it reduces the possibility that this entire
loop will get stuck doing busy work when trying to evict connections to
get under the maximum threshold.
