🤔 ismaelsadeeq reviewed a pull request: "Cluster size 2 package rbf"
(https://github.com/bitcoin/bitcoin/pull/28984#pullrequestreview-2033245669)
reACK 69deec6fd074e8524dd11103834739b02f50e814

💬 willcl-ark commented on issue ""Migrate Wallet" is unclear to translators":
(https://github.com/bitcoin/bitcoin/issues/29979#issuecomment-2088171543)
Can we close this now then? We're not going to find a more appropriate word than "migrate" for this context, and it seems like there's therefore no action to be taken here.

👍 willcl-ark approved a pull request: "test: Add test case for spending bare multisig"
(https://github.com/bitcoin/bitcoin/pull/29120#pullrequestreview-2033256084)
reACK e504b1fa1fa4d014b329dea81bfdf1aa55db238f

Appears to only a rebase on master since my previous ack
```
git range-diff 9c7b2d0d37b31f01403f7a0f2ea25b60b126c841...e504b1fa1fa4d014b329dea81bfdf1aa55db238f
```

💬 maflcko commented on issue ""Migrate Wallet" is unclear to translators":
(https://github.com/bitcoin/bitcoin/issues/29979#issuecomment-2088192746)
I think context can be added to translations, if it isn't already there. See for example 3868ba3a27d594dd2968548fff3db457cbeb0080.

💬 willcl-ark commented on issue ""Migrate Wallet" is unclear to translators":
(https://github.com/bitcoin/bitcoin/issues/29979#issuecomment-2088193794)
Oh ok, great! I wasn't aware that we could add context like that.

💬 maflcko commented on issue ""Migrate Wallet" is unclear to translators":
(https://github.com/bitcoin/bitcoin/issues/29979#issuecomment-2088194592)
An alternative may be to call it "Migrate Wallet Database", not sure which one is better, if any at all. I think if someone cares, they can open a pull request?

👍 willcl-ark approved a pull request: "blockstorage: XOR blocksdir *.dat files"
(https://github.com/bitcoin/bitcoin/pull/28052#pullrequestreview-2033326580)
ACK faaf3cf535999c2c9a84337414c8b35435384862

Nice change with the same rationale as the previous mempool XOR changes (preventing anti-virus falsely flagging/modifying block files).

One non-blocking comment left as a result of manual testing.

💬 willcl-ark commented on pull request "blockstorage: XOR blocksdir *.dat files":
(https://github.com/bitcoin/bitcoin/pull/28052#discussion_r1586058508)
Jjust noting here that if the user specifies `-blocksxor=01234567` and a file-based key already exists in the datadir, the key from the file is silently used.

This is the correct behaviour IMO, but wonder if we should log that the user-set option has been overridden?

As @maflcko pointed out to me previously, even if a user mistakenly thought they were using a custom xor key set as a CL option and removed the key file, they could still restore it. So I don't see any dangers with this curren
...

💬 maflcko commented on pull request "test: Add test case for spending bare multisig":
(https://github.com/bitcoin/bitcoin/pull/29120#issuecomment-2088216432)
utACK e504b1fa1fa4d014b329dea81bfdf1aa55db238f

💬 willcl-ark commented on issue "Testnet fixed seeds don't work":
(https://github.com/bitcoin/bitcoin/issues/29574#issuecomment-2088217034)
See #30008

💬 maflcko commented on pull request "blockstorage: XOR blocksdir *.dat files":
(https://github.com/bitcoin/bitcoin/pull/28052#discussion_r1586099563)
> -blocksxor=01234567

The option is boolean, so I guess it could throw here. In any case, the setting won't have an effect on an existing blocksdir, even on `-reindex`. Maybe the manpage can be adjusted to clarify this?

💬 laanwj commented on pull request "chainparams: Add achow101 DNS seeder":
(https://github.com/bitcoin/bitcoin/pull/30007#issuecomment-2088238337)
Concept ACK
```
Flags: x9
Status DNS name Totals IPv4 IPv6
nconn/n nconn/n TTL nconn/n TTL
* mainnet
OK seed.bitcoin.sipa.be. 25/25 25/25 2640 0/0
OK dnsseed.bluematt.me. 29/31 20/21 60 9/10 60
OK dnsseed.bitcoin.dashjr-list-of-p2p-nodes 22/22 22/22 264
...

💬 willcl-ark commented on pull request "chainparams: Add achow101 DNS seeder":
(https://github.com/bitcoin/bitcoin/pull/30007#issuecomment-2088252118)
Concept ACK

Some of our DNS seeds are currently not performing [well](https://github.com/bitcoin/bitcoin/issues/29911), so adding a new/more reliable one seems logical to me.

I have also been running this seeder myself for some time (at seed.bitcoin.fish.foo) and the program seems to work well from the operator side too, not requiring any intervention in the few weeks i've been running it.

I ran a different test to @laanwj on mainnet IPV4 only, and did find seeds generally returning res
...

💬 TheCharlatan commented on pull request "depends: sqlite 3.45.3":
(https://github.com/bitcoin/bitcoin/pull/29991#issuecomment-2088396078)
Guix builds (aarch64)
```
95204b6b16c56371e935059face7a9775a20248823740257a96f302b30a1f766 guix-build-63678f7635b4/output/aarch64-linux-gnu/SHA256SUMS.part
a7e81be279d93a7a20b354f98183ac7247694a3a665d56ee05d24cf249d7f74e guix-build-63678f7635b4/output/aarch64-linux-gnu/bitcoin-63678f7635b4-aarch64-linux-gnu-debug.tar.gz
613d11f0e216160f050e3e752234d33ba63d7e8c7d27bebabbc4cb292d686624 guix-build-63678f7635b4/output/aarch64-linux-gnu/bitcoin-63678f7635b4-aarch64-linux-gnu.tar.gz
5d1286410d
...

💬 instagibbs commented on pull request "p2p: opportunistically accept 1-parent-1-child packages":
(https://github.com/bitcoin/bitcoin/pull/28970#discussion_r1586254555)
> PCKG_POLICY doesn't populate m_tx_results so we wouldn't have results for those transactions

From my reading of the code, `package-mempool-limits` populates `m_tx_results`? We also allow those cases in our fuzz target(which I'm guessing is there because I hit it!).

We could probably be more aggressive about filling out results when possible and passing those results along, sounds like future work for now?

📝 glozow opened a pull request: "opportunistic 1p1c followups"
(https://github.com/bitcoin/bitcoin/pull/30012)
Followups from #28970:
- https://github.com/bitcoin/bitcoin/pull/28970#discussion_r1568781077
- https://github.com/bitcoin/bitcoin/pull/28970#discussion_r1585554972
- https://github.com/bitcoin/bitcoin/pull/28970#discussion_r1581019326
- https://github.com/bitcoin/bitcoin/pull/28970#discussion_r1581036209

💬 instagibbs commented on pull request "Cluster size 2 package rbf":
(https://github.com/bitcoin/bitcoin/pull/28984#discussion_r1586256603)
Should all these failures be `PCKG_POLICY`? We have individual errors which are reported as well, and now with 1P1C relay, we probably want to act on failures at p2p layer?

💬 glozow commented on pull request "p2p: opportunistically accept 1-parent-1-child packages":
(https://github.com/bitcoin/bitcoin/pull/28970#discussion_r1586256784)
Done in #30012

💬 glozow commented on pull request "p2p: opportunistically accept 1-parent-1-child packages":
(https://github.com/bitcoin/bitcoin/pull/28970#discussion_r1586256968)
Done in #30012

💬 glozow commented on pull request "p2p: opportunistically accept 1-parent-1-child packages":
(https://github.com/bitcoin/bitcoin/pull/28970#discussion_r1586257053)
Done in #30012