`fread(3)` does not distinguish between end-of-file and error,
and callers must use `feof(3)` and `ferror(3)` to determine which
occurred.
Github-Pull: #29307
Rebased-From: 55439903212dcee6af09da7393a41e3754501b37
Explicit callers of `AutoFile::fclose()` should check whether
`fclose(3)` failed because this may be due to a failure to
flush written data to disk. Such failures after writing to
a file should be treated as failures to `fwrite(3)`.
Github-Pull: #29307
Rebased-From: e9abf95ab52f1f2d6f73ecca63133c29c253b7d9
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: 8decc5c726
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: 4fdd836db9
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: df30247705
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: c3d02be536
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: 9d728916b2
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: 453b4813eb
