[22.x] Backports for 22.x

fanquake commented at 2:53 am on October 14, 2021: member

Collecting backports for the 22.1 release. Currently:

#23045
#23061
#23148
#22390
#22820
#22781
#22895
#23335
#23333
#22949
#23580
#23504
https://github.com/bitcoin/bitcoin/pull/24239

fanquake added the label Backport on Oct 14, 2021

katesalazar commented at 12:26 pm on October 14, 2021: contributor

I suggested porting pull 439 of the gui repo of the bitcoin-core account back to 22, nobody explicitly denied, I’m not really sure if they ignore me or are just busy with something else, so I’ll leave this here and make sure it doesn’t spam undesired links. Cheers!

laanwj commented at 3:56 pm on October 14, 2021: member

@katesalazar The policy is that we backport bugfixes to previous releases. The referenced issue seems a small cosmetic change that doesn’t affect use of the software. So I’d say it’s unnecessary. On the other hand it’s also low-risk so if other people think it’s nice to have I’m also not strongly against it.

fanquake force-pushed on Oct 15, 2021

promag commented at 7:37 pm on October 15, 2021: member

ACK a75131e849d68d5dd65350001221f1aa86a6efc5. Performed same backports and got same result.

luke-jr commented at 1:04 am on October 16, 2021: member

Suggest #21882 #22390 #22781 #22820 #22895

Maybe #23182 (+followup fix) #22359 #22722 #22879

fanquake commented at 5:12 am on October 20, 2021: member

I’ve added #22390, #22781, #22820 and #22895 for now.

fanquake force-pushed on Oct 21, 2021

MarcoFalke added this to the milestone 22.1 on Oct 25, 2021

lukaszsamson commented at 6:36 pm on November 19, 2021: none

What about #22949?? #23353 is assigned to 22.1 milestone

fanquake commented at 1:32 am on November 22, 2021: member

What about #22949?? #23353 is assigned to 22.1 milestone

I’ve added #22949, and updated the PR description to include all the changes.

gruve-p commented at 8:43 am on November 22, 2021: contributor

ACK https://github.com/bitcoin/bitcoin/pull/23276/commits/e02e8dcf583fff679560c914f3089ec368d78ea2

fanquake force-pushed on Nov 22, 2021

laanwj commented at 5:46 pm on December 13, 2021: member

List-of-commits ACK 406e3134e2e322a4791f720ff665d0692e97be9a

ghost commented at 4:51 pm on January 17, 2022: none

I am not sure. Maybe this can be added: https://github.com/bitcoin/bitcoin/pull/23268

fanquake referenced this in commit a06915dece on Feb 9, 2022

fanquake force-pushed on Feb 14, 2022

build: Restrict check for CRC32C intrinsic to aarch64

`crc32c`'s hardware accelerated code doesn't handle ARM 32-bit at all.
Make the check in `configure.ac` check for this architecture explicitly.

For the release binaries, the current `configure.ac` check happens
to work: it enables it on aarch64 but disables it for armhf. However
some combination of compiler version and settings might ostensibly cause
this check to succeed on armhf (as reported on IRC). So make the 64-bit
platform requirement explicit.

Github-Pull: #23045
Rebased-From: f2747d1602ec4e1128356b861b2167daf66a845b

85c78e08ec

Fix (inverse) meaning of -persistmempool

Github-Pull: #23061
Rebased-From: faff17bbde6dcb1482a6210bc48b3192603a446f

db76db7329

doc: Add 23061 release notes

Github-Pull: #23061
Rebased-From: faa9c19a4b27e7fabf7c5deae1b4c4ca612ed01a

92d44ff36c

guix: Fix powerpc64(le) dynamic linker name

I used Guix's values for the powerpc64(le) dynamic linkers, and the
/lib-prefix seems to be a Guix-ism rather than standard. The standard
path for the linker-loaders start with /lib64.

I've taken the new loader values from SYSDEP_KNOWN_INTERPRETER_NAMES in
glibc's sysdeps/unix/sysv/linux/powerpc/ldconfig.h file.

For future reference, loader path values can also be found on glibc's
website: https://sourceware.org/glibc/wiki/ABIList?action=recall&rev=16

Github-Pull: #23148
Rebased-From: b96adcbfae90b3e041754f11624cac04c1999e8c

c1cdeddd90

system: skip trying to set the locale on NetBSD

Just treat it the same as the other BSDs.

Fixes #17379.

Github-Pull: #22390
Rebased-From: fdd71448e78f442ffd93a3a3398a5062eaba9f1b

c95b188fc0

build, qt: Fix typo in QtInputSupport check

Github-Pull: #22820
Rebased-From: e251726affe97da745362c82567c2377ceb07d21

a5a1538826

the result of CWallet::IsHDEnabled() was initialized with true.

But in case of no keys or a blank hd wallet the iterator would be skipped
and not set to false but true, since the loop would be not entered.

That had resulted in a wrong return and subsequent false HD and watch-only
icon display in gui when reloading a wallet after closing.

Update src/wallet/wallet.cpp

Co-authored-by: Hennadii Stepanov <32963518+hebasto@users.noreply.github.com>

Github-Pull: #22781
Rebased-From: 8733a8e84c4b2e484f6ed6159fcf5f29a360d42e

c671c6f470

consensus: don't call GetBlockPos in ReadBlockFromDisk without lock

Github-Pull: #22895
Rebased-From: 350e034e64d175f3db4c85ddca42e76e279912f6

7febe4f3c7

refactor: include a missing <limits> header in fs.cpp

... needed for std::numeric_limits<T>::max on WIN32

Github-Pull: #23335
Rebased-From: 077a875d94b51e3c87381133657be98989c8643e

282863a7e9

wallet: fix segfault by avoiding invalid default-ctored `external_spk_managers` entry

In the method `CWallet::LoadActiveScriptPubKeyMan`, the map
`external_spk_managers` (or `internal_spk_managers`, if parameter
`internal` is false) is accessed via std::map::operator[], which means
that a default-ctored entry is created with a null-pointer as value, if
the key doesn't exist.  As soon as this value is dereferenced, a
segmentation fault occurs, e.g. in `CWallet::KeypoolCountExternalKeys`.

The bevaviour can be reproduced by the following steps (starting with empty regtest datadir):

$ ./src/bitcoind -regtest -daemon
$ ./src/bitcoin-cli -regtest -named createwallet_name=wallet descriptors=true blank=true
$ cat regtest-descriptors.txt
[
  {
    "desc": "tr([e4445899/49'/1'/0']tprv8ZgxMBicQKsPd8jCeBWsYLEoWxbVgzJDatJ7XkwQ6G3uF4FsHuaziHQ5JZAW4K515nj6kVVwPaNWZSMEcR7aFCwL4tQqTcaoprMKTTtm6Zg/1/*)#mr3llm7f",
    "timestamp": 1634652324,
    "active": true,
    "internal": true,
    "range": [
      0,
      999
    ],
    "next": 0
  }
]
$ ./src/bitcoin-cli -regtest importdescriptors "$(cat regtest-descriptors.txt)"
[
  {
    "success": true
  }
]
$ ./src/bitcoin-cli -regtest getwalletinfo
error: timeout on transient error: Could not connect to the server 127.0.0.1:18443 (error code 1 - "EOF reached")

Bug reported by Josef Vondrlik (josef-v).

Github-Pull: #23333
Rebased-From: 6911ab95f19d2b1f60f2d0b2f3961fa6639d4f31

227ae65254

fees: Always round up fee calculated from a feerate

When calculating the fee for a given tx size from a fee rate, we should
always round up to the next satoshi. Otherwise, if we round down (via
truncation), the calculated fee may result in a fee with a feerate
slightly less than targeted.

This is particularly important for coin selection as a slightly lower
feerate than expected can result in a variety of issues.

Github-Pull: #22949
Rebased-From: 0fbaef9676a1dcb84bcf95afd8d994831ab327b6

bd7e08e36b

tests: Test for assertion when feerate is rounded down

When calculating a txs absolute fee, if the fee is rounded down to the
nearest satoshi, it is possible for the coin selection algorithms to
undercalculate the fee needed. This can lead to an assertion error in
some situations. One such scenario is added to
rpc_fundrawtransaction.py.

Github-Pull: #22949
Rebased-From: ce2cc44afd51f3df4ee7f14ea05b8da229183923

f66bc42957

tests: Calculate fees more similarly to CFeeRate::GetFee

Because of floating point precision issues, not all of the rounding done
is always correct. To fix this, the fee calculation for
assert_fee_amount is changed to better reflect how CFeeRate::GetFee does
it.

First the feerate is converted to an int representing sat/kvb. Then this
is multiplied by the transaction size, divivided by 1000, and rounded up
to the nearest sat. The result is then converted back to BTC (divided by
1e8) and then rounded down to the nearest sat to avoid precision errors.

Github-Pull: #22949
Rebased-From: 80dc829be7f8c3914074b85bb4c125baba18cb2c

c768bfa08a

build: patch qt to explicitly define previously implicit header include

macOS Monterey has refactored some includes such that implicitly defined headers were no longer exposed and that in turns breaks building Qt on macOS 12.

Additional Resources:
 - https://bugreports.qt.io/browse/QTBUG-97855
 - https://codereview.qt-project.org/c/qt/qtbase/+/378706
 - https://code.qt.io/cgit/qt/qtbase.git/commit/src/plugins/platforms/cocoa?id=dece6f5840463ae2ddf927d65eb1b3680e34a547

Github-Pull: #23580
Rebased-From: 8196b0a2bc63c35769eca213cba4a5844a737b90

801b0f05aa

ci: Replace soon EOL hirsute with jammy

Github-Pull: #23504
Rebased-From: fafa66e424cd0c4a4ac3175e0d3b15a54626aa4b

2f60fc6d8c

test: Call ceildiv helper with integer

It returns an incorrect result when called with a Decimal,
for which the "//" operator works differently.
Also drop unnecessary call to satoshi_round.

Github-Pull: #24239
Rebased-From: d1fab9d5d27a2db2546db0f610e0f6929ec4864e

269553fe73

fanquake force-pushed on Feb 15, 2022

achow101 commented at 2:17 pm on February 28, 2022: member

ACK 269553fe73b17f8acda3071a48836c66092d31d0

fanquake merged this on Mar 1, 2022

fanquake closed this on Mar 1, 2022

fanquake deleted the branch on Mar 1, 2022

DrahtBot locked this on Mar 1, 2023

[22.x] Backports for 22.x #23276