💬 hebasto commented on pull request "ci: Update apt cache":
(https://github.com/bitcoin/bitcoin/pull/28925#issuecomment-1822586677)
> Would have been good to link-to/explain the failures here. Nothing in the PR description or commit messages about what broke, or why this is the fix.

A self-explaining excerpt from a build log has been added to the PR description.

🚀 fanquake merged a pull request: "Drop CAutoFile"
(https://github.com/bitcoin/bitcoin/pull/28904)

💬 hebasto commented on pull request "ci: Avoid toolset ambiguity that MSVC can't handle":
(https://github.com/bitcoin/bitcoin/pull/28905#issuecomment-1822593954)
> Do we know why this broke again?

The underlying [issue](https://developercommunity.visualstudio.com/t/MicrosoftVCToolsVersionv143defaulttx/10041951) is labeled "Under Investigation".

> I guess this is something we'll just have to maintain forever?

Or until Microsoft fixes the issue.

> That's a shame, because it also adds ~30% runtime to this CI job.

I agree with you.

💬 fanquake commented on pull request "test: fix `AddNode` unit test failure on OpenBSD":
(https://github.com/bitcoin/bitcoin/pull/28891#issuecomment-1822597668)
This code isn't in 26.x. So removed the backport label and milestone for now.

💬 fanquake commented on pull request "coins: make sure PoolAllocator uses the correct alignment":
(https://github.com/bitcoin/bitcoin/pull/28913#issuecomment-1822601800)
Will be backported in #28872.

💬 fanquake commented on pull request "ci: Update apt cache":
(https://github.com/bitcoin/bitcoin/pull/28925#issuecomment-1822604793)
Will be backported in #28872.

💬 fanquake commented on pull request "[26.x] Final Changes":
(https://github.com/bitcoin/bitcoin/pull/28872#discussion_r1401916649)
Sure. Added to the next push.

💬 hebasto commented on pull request "[26.x] Changes for rc3":
(https://github.com/bitcoin/bitcoin/pull/28872#issuecomment-1822617995)
Suggesting to backport https://github.com/bitcoin/bitcoin/pull/28905 as well to ensure CI pass.

🚀 fanquake merged a pull request: "p2p: do not make automatic outbound connections to addnode peers"
(https://github.com/bitcoin/bitcoin/pull/28895)

🚀 fanquake merged a pull request: "depends: bump libmultiprocess to fix capnproto deprecation warnings"
(https://github.com/bitcoin/bitcoin/pull/28907)

💬 ajtowns commented on pull request "Use serialization parameters for CTransaction":
(https://github.com/bitcoin/bitcoin/pull/28438#discussion_r1401931286)
If the issue is the separation between the `CNetAddr::SerParams` declaration and the `MultiSerParams(..,CNetAddr::V2,..)` use, could instead make it:

```c++
class MultiSerParam
{
public:
template<typename T>
operator T&() const { return T::GetIPCSerParams(); }
};
constexpr MultiSerParam INTERNAL_SER_PARAMS;

class CNetAddr {
struct SerParams {
const Encoding enc;
static SerParams GetIPCSerParams() { return {Encoding::V2}; }
SER_PARAMS_OPFUNC

...

💬 fanquake commented on pull request "ci: Avoid toolset ambiguity that MSVC can't handle":
(https://github.com/bitcoin/bitcoin/pull/28905#issuecomment-1822634582)
Added to #28872 for backporting.

💬 fanquake commented on pull request "p2p: do not make automatic outbound connections to addnode peers":
(https://github.com/bitcoin/bitcoin/pull/28895#issuecomment-1822635615)
Added the fix to #28872 for backporting.

👍 hebasto approved a pull request: "[26.x] Changes for rc3"
(https://github.com/bitcoin/bitcoin/pull/28872#pullrequestreview-1744270748)
ACK 740a85ce5f25f2282e32f148d61f92301bef7179, I've verified backports locally, also reviewed changes related to the `-par` option and `rc2` --> `rc3` as well.

💬 hebasto commented on pull request "[26.x] Changes for rc3":
(https://github.com/bitcoin/bitcoin/pull/28872#discussion_r1401975084)
nit:
```suggestion
- The transaction list in the GUI no longer provides a special category for "payment to yourself". Now transactions that have both inputs and outputs that affect the wallet are displayed on separate lines for spending and receiving. (gui#119)
```

I apologize for the wrong Grammar in my initial suggestion.

📝 willcl-ark opened a pull request: "rpc: add 'getnetmsgstats' RPC"
(https://github.com/bitcoin/bitcoin/pull/28926)
This picks up #27534 with a rebase and a few fixups, unsquashed for consideration. See #27534 for more background information.

Considerations from the previous draft:

> Should we allow dimensions to be rearraged?
>
> When it comes time to gather up the RPC results, @vasild has provided an [alternate implementation](https://github.com/vasild/bitcoin/commits/getnetmsgstats) that uses an array instead of the MultiMap structure. This results in two changes:
>
>> using the stack over the
...

👍 TheCharlatan approved a pull request: "Fee Estimator updates from Validation Interface/CScheduler thread"
(https://github.com/bitcoin/bitcoin/pull/28368#pullrequestreview-1744286806)
Re-ACK 91504cbe0de2b74ef1aa2709761aaf0597ec66a2

💬 Sjors commented on pull request "wallet: batch all individual spkms setup db writes in a single db txn":
(https://github.com/bitcoin/bitcoin/pull/28894#issuecomment-1822850560)
re-utACK f05302427386fe63f4929a7198652cb1e4ab3bcc

CI failure seems spurious

💬 maflcko commented on pull request "blockstorage: XOR blocksdir *.dat files":
(https://github.com/bitcoin/bitcoin/pull/28052#issuecomment-1822887374)
rebased

💬 dergoegge commented on pull request "multiprocess: Add basic type conversion hooks":
(https://github.com/bitcoin/bitcoin/pull/28921#discussion_r1401997881)
I'm gonna try to summarize my understanding of this to make sure I actually got it right.

We want this specialization of `CustomBuildField` for (most) of our serializable types. So we can either define it manually for each type or we can make use of sfinae (like you do here) to automatically only create the specialization for each of the required serializable types.

We also want to be able to further overload `CustomBuildField` for serializable types that can't use this generic specializat
...

⚠️ quakemmo opened an issue: "importing a wallet containing an hdseed overwrites target wallet hdseed"
(https://github.com/bitcoin/bitcoin/issues/28927)
### Is there an existing issue for this?

- [X] I have searched the existing issues

### Current behaviour


My basic idea was to have two nodes running with the same keys, if one fails, I can just rescan the blockchain on the other one and failover to it seamlessly.

I made a wallet on Node1, generated a few thousands addresses, saved the dumpwallet. Now I want to import the same keys to Node2, but I want it to be an HD wallet from the same seed, to avoid the headache of sendtoaddress, when
...