This change is a result if pulling the recent translations
from the Transifex website using the
bitcoin-maintainer-tools/update-translations.py tool.
A few manual adjustments were made:
- skipped removing of `bitcoin_af.ts`
- skipped removing of `bitcoin_ar.ts`
- skipped adding of `bitcoin_ru_RU.ts` (`bitcoin_ru.ts` is already
present)
LLVM Clang >=16.0 and Apple Clang >=15.0 do not recognize
`-Xclang -internal-isystem/usr/local/include` anymore.
For example, see: cbbe1d4454
Github-Pull: #29195
Rebased-From: 8decc5c726caca2381cffbd1b3585862421f5b8e
The Apple notary service requires submitted app bundles to be configured to use the hardened runtime libraries. This is configured at signing time, and supported by the signapple tool Bitcoin Core uses for reproduceable signed binaries. We simply need to pass "--hardened-runtime" when the signature is created. Once attached to the bundle, the resulting codesigned binary can be successfully submitted to the Apple binary notarization service by any Apple Developer.
Github-Pull: #29127
Rebased-From: 4fdd836db92e789c98b9e68398ca931a968cc9c3
Test that wallet rescans process transactions topologically, even if a
parent's entry into the mempool is later than that of its child.
This behavior is important because IsFromMe requires the ability to look
up a transaction's inputs.
Co-authored-by: furszy <matiasfurszyfer@protonmail.com>
Github-Pull: #29179
Rebased-From: df30247705940c50c5eaafd74e2abbeb8b0cec07
Test that wallet rescans process transactions topologically, even if a
parent's entry into the mempool is later than that of its child.
This behavior is important because IsFromMe requires the ability to look
up a transaction's inputs.
Github-Pull: #29179
Rebased-From: c3d02be536ac3f35c10efa03653186a17ebbfc12
Log at the top before incrementing so that this log isn't printed when
there's only 1 tx.
Github-Pull: #29227
Rebased-From: eb78ea4eebfe150bc1746282bfdad6eb0f764e3c
A Bitcoin Core node may only connect to a peer destination via I2P if both sides
have sessions with the same encryption type. The encryption type is a property
of the session, not the destination. Sessions may support multiple encryption
types.
As Bitcoin Core is not currently setting the I2P encryption type when creating
sessions, it is using the older default, ElGamal (type 0).
This pull updates Bitcoin Core to use both ECIES-X25519 and ElGamal (types 4 and
0, respectively). This allows to connect to I2P peers with either type, and the
newer, faster ECIES-X25519 will be preferred.
See also the recently updated section "Signature and Encryption Types" in
https://geti2p.net/en/docs/api/samv3
Thanks and credit to zzzi2p (https://github.com/zzzi2p) for reporting.
Closes https://github.com/bitcoin/bitcoin/issues/29197.
Github-Pull: #29200
Rebased-From: 9d728916b27e18efc6f8839770ed5ec14789fc08
Instead of reaching into the mapTx data structure, use a helper method
that provides the required vector of CTxMemPoolEntry pointers.
Github-Pull: #28391
Rebased-From: 453b4813ebc74859864803e9972b58e4be76a4d6
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: 43c3246af774bda284111056268a814477f9b256
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: 83c66444d0604f0a9ec3bc3f89d4f1a810b7cda0
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: 6f497377aa17cb8a590fd7717fa8ededf4249999
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: 75fbf444c1e13c6ba0e79a34871534c845a13849
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: b4306e3c8db6cbaedc8845c6d21c750b39f682bf
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: 05e5ff194c7722b4ebc2b9309fc0bf47b3cf1df7
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: 0c5755761c3e544547899ad096121585dffa73df
The crash would happen when querying a mempool transaction with verbosity=2, while pruning.
Github-Pull: #29003
Rebased-From: 494a926d05df44b60b3bc1145ad2a64acf96f61b
b1d350c78b0a26e3c514a79b928578727df70538 doc: update release notes for 26.0 (fanquake)
b0546bc907edc4e6b7ab1baaf1f9400bd8315bf3 doc: update manual pages for 26.0 (fanquake)
9ce1766d206d3ef607d659d6d0759b8c02a02f60 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 b1d350c78b0a26e3c514a79b928578727df70538
hebasto:
ACK b1d350c78b0a26e3c514a79b928578727df70538, 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: 228d6a2969e4fcee573c9df7aad31550eab9c8d4
This change is required to work with the new windows-2022 image version
20231115 properly.
Github-Pull: #28905
Rebased-From: 91d5bd8ac9a28725c735f8e6900bc85673bb190a
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: cc627169206fe902157806d88fcaf2b05701c38d
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: d5b4c0b69e543de51bb37d602d488ee0949ba185
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: ce881bf9fcb7c30bb1fafd6ce38844f4f829452a
