Cherry-picked from: bitcoin/bitcoin 3272e34f
and bitcoin/bitcoin cc25f892
and bitcoin/bitcoin a33381ac
Conflicts resolved:
- removed ci script and guix file changes that we don't have
- removed changes to libxcb
- squashed commits as cc25f892 was a fixup
- rewrote the change to depends/README
Co-authored-by: fanquake <fanquake@gmail.com>
Co-authored-by: W. J. van der Laan <laanwj@protonmail.com>
Changes client parametrization and mining frequency inside
importprunedfunds.py to make sure that when wallet configuration
changes, the test still can succeed, by not allowing it to respend
unconfirmed outputs that could otherwise be reused in this test.
The alternative would be to have to change this test every time the
wallet defaults change, which is not the subject of this test.
Updates MIN_CHANGE to always allow for a subsequent bump from the
change output using RBF or CPFP of at least 2x the recommended
minumum fee, on top of the dust limit, because the previous value
did not allow enough change for performing a CPFP bump, and only
allowed for a single bumfee call, which would spend the entire
change output rather than allowing for optimization.
Adds a test to bumpfee.py that tests the policy of MIN_CHANGE and
MIN_FINAL_CHANGE parameters when using RBF, making sure that with
the wallet default configuration, RBF can be performed. This test
fails on this commit.
Sets WALLET_INCREMENTAL_RELAY_FEE to 1/10th of the default
recommended minimum fee, to encourage using RBF over CPFP and
saving the additional blockspace required for child transactions
spending parent transactions.
The previous value was based off a 1 DOGE recommended fee and did
not make sense with the current minimum fee recommendation.
The value of DEFAULT_INCREMENTAL_RELAY_FEE has never been tuned for
Dogecoin since porting from Bitcoin Core 0.14. Even though the dual
meaning of this parameter is suboptimal, it can still be tuned.
This commit sets the value to 1/10th of DEFAULT_MIN_RELAY_TX_FEE
from validation.h, which causes:
1. Mempool limiting to be performed in steps of 0.0001 DOGE/kb
instead of 0.00001 DOGE/kb
2. RBF to be accepted by the mempool if the new fee is at least
0.0001 DOGE/kb higher than the previous fee known to the
mempool
3. RBF to be cheaper than CPFP by a factor 10 (as the latter would
require a fee of more than 0.001 DOGE/kb on a subsequent bumping
transaction), to encourage mempool replacement over prioritizing
through additional transactions that need to be mined.
4. Mempool limiting to be 10x faster to reset to zero than before,
because for bitcoin, fee increments equaled their minimum fee,
but for us this was 1/100th.
mempool_tests.cpp has been reworked a bit to reflect the reality
of having a lower increment than the minimum fee, as even though
this already was the case, this was not tested correctly due to the
static values in the unit test.
Refresh the most active translation files. As we're not set up with the same tooling as Bitcoin, we get slightly different results compared to the files they generate, so I've picked only specific files to update to reduce churn. If we have translation volunteers for other languages we can update those languages at the time.
* Chinese
* French
* German
* Indonesian
* Italian
* Japanese
* Korean
* Netherlands
* Spanish
* Russian
* Turkish
Introduces RECOMMENDED_MIN_TX_FEE as a constant that explicitly
sets a single value and then implements this value for each fee
related constant throughout the code, instead of using values
relative to COIN. This helps because it makes the relation of
other defaults to the fee recommendation clear and makes
choices made by developers in wallet configuration easier to
read and understand.
This commit only changes existing values to be expressed relative
to the recommended fee and does not change actual values.
Instead of doing the awkward /bin path prepending at config.site
creation time, set darwin_{CC,CXX} in a way that fully determines the
program's path (clang/clang++)
Also see the added comment block in depends/Makefile for more context on
determining $PATH for our config.site.
Cherry-picked from: 880660ac
Conflicts: cherry-picked from a Bitcoin Core build system that is
optimized for supporting system-provided clang builds
which Dogecoin Core does not have at this time. I have
removed all code regarding that functionality and only
kept the code relevant to Dogecoin Core for this
major version (1.14), i.e. those lines that use the
pinned clang from the depends system.
Patches openssl 1.0.2's usage of secure_getenv to always use the
fallback OPENSSL_issetugid() instead, to remove reliance on a
higher glibc than the minimum we currently support (2.11)
See depends/patches/openssl/secure_getenv.patch for a full
description of the patch.
* Change from a block target number to using speed labels which pick predefined fee values.
* Remove smart fee labels from send coins control dialog.
* Rename slider position configuration for Qt, as smart fee slider settings are not compatible with preset fee settings.
* Reduce DEFAULT_FALLBACK_FEE to 1,000,000 Koinu. Note this by itself has no effect as the required fee is higher.
* Reduce wallet minimum fees to 0.01 DOGE
* Update DEFAULT_DUST_LIMIT
* Revise derived values after updating recommended fees
* Remove fee rounding from RPC tests
* Revert tests back to Bitcoin originals where possible
- update bitcoin_fr.ts in french language
- with this commit new users (running first time Dogecoin Core) have a message that they are syncing with Dogecoin network (instead Bitcoin)
This cherry-picks a tinyformat commit:
8a2812d848
The effect should be to remove all compilation warnings about implicit
switch fallthroughs.
Updating the entire header file to the latest release at once brings in
other changes that may be more invasive for 1.14.5, and this commit
should not interfere with a further update.
CFeeRate and CTxMemPoolEntry have explicitly defined copy ctors which has
the same functionality as the implicit default copy ctors which would
have been generated otherwise.
Besides being redundant, it violates the rule of three
(see https://en.wikipedia.org/wiki/Rule_of_three_(C%2B%2B_programming) ).
(Of course, the rule of three doesn't -really- cause a resource
management issue here, but the reason for that is exactly that there is
no need for an explicit copy ctor in the first place since no resources
are being managed).
CFeeRate has an explicitly defined copy ctor which has the same
functionality as the implicit default copy ctor which would have been
generated otherwise.
-----------------------------
Cherry-picked from: b426e2467
Note:
Solved conflict where upstream moved CFeeRate into ./policy/
whereas we still have it in amount.h/cpp on 1.14.
