Github-Pull: bitcoin#26761
Rebased-From: 730e14a

If a wallet has key birthdates that are more recent than the currrent
chain tip, or a bestblock height higher than the current tip, we should
not attempt to rescan as there is nothing to scan for.

Github-Pull: bitcoin#26679
Rebased-From: 3784009

To be eligible for fee-bumping, a transaction must not have any
of its outputs (eg - change) spent in other unconfirmed transactions
in the wallet. However, this check should not apply to abandoned
transactions.

A new test case is added to cover this case.

Github-Pull: bitcoin#26675
Rebased-From: f9ce0ea

This class is the counterpart to CHashVerifier, in that it
writes data to an underlying source stream,
while keeping a hash of the written data.

Github-Pull: bitcoin#26909
Rebased-From: da6c7ae

The previous logic would call it once for serializing into the filestream,
and then again for serializing into the hasher. If AddrMan was changed
in between these calls by another thread, the resulting peers.dat would
be corrupt with non-matching checksum and data.
Fix this by using HashedSourceWriter, which writes the data
to the underlying stream and keeps track of the hash in one go.

Github-Pull: bitcoin#26909
Rebased-From: 5eabb61

Github-Pull: bitcoin#26924
Rebased-From: fadeb6b

Github-Pull: bitcoin#26944
Rebased-From: d81ca66

The way that the main overview page limits the number
of transactions displayed (currently 5) is not
an appropriate use of Qt. If it's run with a DEBUG
build of Qt, it'll result in a segfault in certain
relatively common situations. Instead of artificially
limiting the rowCount() in the subclassed proxy
filter, we hide/unhide the rows in the displaying
QListView upon any changes in the sorted proxy filter.

Github-Pull: bitcoin-core/gui/pull/704
Rebased-From: 08209c0

When an encrypted wallet is locked (for instance via the
RPC `walletlock`), the docs indicate that the key is
removed from memory. However, the vector (with a secure
allocator) is merely cleared. This allows the key to persist
indefinitely in memory. Instead, manually fill the bytes with
zeroes before clearing.

Github-Pull: bitcoin#27080
Rebased-From: 3a11adc

This will lower the load on the I2P network. Since we use one transient
session for connecting to just one peer, a higher number of tunnels is
unnecessary.

This was suggested in:
bitcoin#26754 (comment)
bitcoin#26754 (comment)

The options are documented in:
https://geti2p.net/en/docs/protocol/i2cp#options

A tunnel is unidirectional, so even if we make a single outbound
connection we still need an inbound tunnel to receive the messages sent
to us over that connection.

Alleviates: bitcoin#26754

Github-Pull: bitcoin#26837
Rebased-From: 801b405

The default number of tunnels in the Java implementation is 2 and in the
C++ i2pd it is 5. Pick a mid-number (3) and explicitly set it in order
to get a consistent behavior with both routers. Do this for persistent
sessions which are created once at startup and can be used to open up
to ~10 outbound connections and can accept up to ~125 incoming
connections. Transient sessions already set number of tunnels to 1.

Suggested in:
bitcoin#26754 (comment)
https://geti2p.net/en/docs/api/samv3

Alleviates: bitcoin#26754

Github-Pull: bitcoin#26837
Rebased-From: 3c1de03

An overload of MigrateLegacyToDescriptor is added which takes the wallet
name. The original that took a wallet pointer is still available, it
just gets the name, closes the wallet, and calls the new overload.

Github-Pull: bitcoin#26595
Reabsed-From: dbfa345

Github-Pull: bitcoin#26595
Rebased-From: 6bdbc5f

Since migration reloads the wallet, the wallet will always be locked
unless the passphrase is given. migratewallet can now take the
passphrase in order to unlock the wallet for migration.

Github-Pull: bitcoin#26595
Rebased-From: 7fd125b

Github-Pull: bitcoin#26595
Rebased-From: aaf02b5

Github-Pull: bitcoin#26595
Rebased-From: 9486509