Homebrew attempts to check for outdated dependents or those with broken
linkage. Such behavior might lead to failures when Homebrew updates them
on old macOS images.
This change prevents such behavior.
Github-Pull: #29080
Rebased-From: 43c3246af7
Verifying the wallet updates the birth time accordingly when it
detects a transaction with a time older than the oldest descriptor
timestamp.
This could happen when the user blindly imports a descriptor with
'timestamp=now'.
Github-Pull: #28920
Rebased-From: 83c66444d0
To avoid scanning blocks, as assumed by a wallet with no
generated keys or imported scripts, the default value for
the birth time needs to be set to the maximum int64_t value.
Once the first key is generated or the first script is imported,
the legacy SPKM will update the birth time automatically.
Github-Pull: #28920
Rebased-From: 6f497377aa
As the user could have imported a descriptor with
a newer timestamp (by blindly setting 'timestamp=now'),
the wallet needs to update the birth time when it detects
a transaction older than the oldest descriptor timestamp.
Github-Pull: #28920
Rebased-From: 75fbf444c1
In the following-up commit, the wallet birth time will also
be modified by the transactions scanning process. When a tx
older than all descriptor's timestamp is detected.
Github-Pull: #28920
Rebased-From: b4306e3c8d
Verify the transaction creation process does not produce
a BnB solution when SFFO is enabled.
This is currently problematic because it could require a
change output. And BnB is specialized on changeless solutions.
Co-authored-by: Andrew Chow <achow101@gmail.com>
Co-authored-by: Murch <murch@murch.one>
Github-Pull: #28994
Rebased-From: 05e5ff194c
Useful for understanding what is going on internally
when the software is running. Debug issues, and provide
more accurate feedback to users.
Github-Pull: #28994
Rebased-From: 0c5755761c
b1d350c78b doc: update release notes for 26.0 (fanquake)
b0546bc907 doc: update manual pages for 26.0 (fanquake)
9ce1766d20 build: bump version to v26.0 final (fanquake)
Pull request description:
Final changes for 26.0. Assuming no further backports. rc3 was done in #28872.
ACKs for top commit:
achow101:
ACK b1d350c78b
hebasto:
ACK b1d350c78b, I have reviewed the code and it looks OK.
Tree-SHA512: 8b1bfa9e9d6c5ccf8305335eba503c02a76043b2752e2302da84cb574078889ddb761b9efd14ef97f68bbae154b00ac54f531e2e33eba6baf8d703aa98ef5175
The `vmull_p64` is a part of the Crypto extensions from the ACLE. They
are optional extensions, so they get enabled with a `+crypto` for
architecture flags.
Github-Pull: #28919
Rebased-From: 228d6a2969
to allocate our limited outbound slots correctly, and to ensure addnode
connections benefit from their intended protections.
Our addnode logic usually connects the addnode peers before the automatic
outbound logic does, but not always, as a connection race can occur. If an
addnode peer disconnects us and if it was the only one from its network, there
can be a race between reconnecting to it with the addnode thread, and it being
picked as automatic network-specific outbound peer. Or our internet connection
or router, or the addnode peer, could be temporarily offline, and then return
online during the automatic outbound thread. Or we could add a new manual peer
using the addnode RPC at that time.
The race can be more apparent when our node doesn't know many peers, or with
networks like cjdns that currently have few bitcoin peers.
When an addnode peer is connected as an automatic outbound peer and is the only
connection we have to a network, it can be protected by our new outbound
eviction logic and persist in the "wrong role".
Examples on mainnet using logging added in the same pull request:
2023-08-12T14:51:05.681743Z [opencon] [net.cpp:1949] [ThreadOpenConnections]
[net:debug] Not making automatic network-specific outbound-full-relay connection
to i2p peer selected for manual (addnode) connection: [geh...odq.b32.i2p]:0
2023-08-13T03:59:28.050853Z [opencon] [net.cpp:1949] [ThreadOpenConnections]
[net:debug] Not making automatic block-relay-only connection to onion peer
selected for manual (addnode) connection: kpg...aid.onion:8333
2023-08-13T16:21:26.979052Z [opencon] [net.cpp:1949] [ThreadOpenConnections]
[net:debug] Not making automatic network-specific outbound-full-relay connection
to cjdns peer selected for manual (addnode) connection: [fcc...8ce]:8333
2023-08-14T20:43:53.401271Z [opencon] [net.cpp:1949] [ThreadOpenConnections]
[net:debug] Not making automatic network-specific outbound-full-relay connection
to cjdns peer selected for manual (addnode) connection: [fc7...59e]:8333
2023-08-15T00:10:01.894147Z [opencon] [net.cpp:1949] [ThreadOpenConnections]
[net:debug] Not making automatic feeler connection to i2p peer selected for
manual (addnode) connection: geh...odq.b32.i2p:8333
Finally, there does not seem to be a reason to make block-relay or short-lived
feeler connections to addnode peers, as the addnode logic will ensure we connect
to them if they are up, within the addnode connection limit.
Fix these issues by checking if the address is an addnode peer in our automatic
outbound connection logic.
Github-Pull: #28895
Rebased-From: cc62716920
If alignment of the PoolAllocator would be insufficient, then the test would fail. This also catches the issue with ARM 32bit,
where int64_t is aligned to 8 bytes but void* is aligned to 4 bytes. The test adds a check to ensure the pool has allocated
a minimum number of chunks
Github-Pull: #28913
Rebased-From: d5b4c0b69e
This changes the PoolAllocator to default the alignment to the given type. This makes the code simpler, and most importantly
fixes a bug on ARM 32bit that caused OOM: The class CTxOut has a member CAmount which is an int64_t and on ARM 32bit int64_t
are 8 byte aligned which is larger than the pointer alignment of 4 bytes. So for CCoinsMap to be able to use the pool, we
need to use the alignment of the member instead of just alignof(void*).
Github-Pull: #28913
Rebased-From: ce881bf9fc
The negative bound for script threads comes from the machine which
generates the man pages, so may only be correct for that machine. Any
other placeholder value will also be wrong for some machines. Fix this
be removing the value. This also fixes help2man incorrectly bolding the
value, as if it were a paramater.
Closes#28850.
Github-Pull: #28858
Rebased-From: d799ea26ed
This commits fixes a crash bug that can be caused with the following steps:
- change to the "Transactions" view
- right-click on an arbitrary transaction -> "Show transaction details"
- close the transaction detail window again
- select "Settings" -> "Mask values"
The problem is that the list of opened dialogs, tracked in the member
variable `m_opened_dialogs`, is only ever appended with newly opened
transaction detail dialog pointers, but never removed. This leads to
dangling pointers in the list, and if the "Mask values" menu item is
selected, a crash is caused in the course of trying to close the opened
transaction detail dialogs (see `closeOpenedDialogs()` method). Fix this
by removing the pointer from the list if the corresponding widget is
destroyed.
Github-Pull: https://github.com/bitcoin-core/gui/pull/774
Rebased-From: e26e665f9f
The zip for codesigned MacOS distribution needs to have all files have
the same timestamp. These files also need to be included in the zip as
zip is not automatically recursive. We use the same pattern for zip as
is done for the other zip files produced by guix.
Github-Pull: #28757
Rebased-From: f6f18eeaa8
958ee5db63 doc: generate example bitcoin.conf for v26.0rc1 (fanquake)
d1fe90c423 doc: generate manual pages for v26.0rc1 (fanquake)
c4fa45c2c3 build: bump version to v26.0rc1 (fanquake)
Pull request description:
Bump the version number.
Generate the man pages.
Generate example bitcoin.conf.
Release-notes.md already points to the wiki: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/26.0%E2%80%90Release%E2%80%90Notes%E2%80%90Draft
ACKs for top commit:
josibake:
ACK 958ee5db63🚀
hebasto:
ACK 958ee5db63
Tree-SHA512: eb13253dd5dbae2723a1a89a42d832c9c817cd00ecb51414313f15c8a988504dd1940babb42bf65cc97a4e37eb861a1ea6df19e6c763eebe4c8734c1cdf99e07
