👍 fanquake approved a pull request: "policy: uncap datacarrier by default"
(https://github.com/bitcoin/bitcoin/pull/32406#pullrequestreview-2893820725)
ACK a189d636184b1c28fa4a325b56c1fab8f44527b1

💬 mzumsande commented on pull request "test: apply microsecond precision to test framework logging":
(https://github.com/bitcoin/bitcoin/pull/32676#discussion_r2124747656)
by the way, I switched to `_=None` because `datefmt=None` runs into a linter error, and omitting the arg is not allowed (TypeErrors). Not sure if the linter is correct to complain about this.

💬 fanquake commented on issue "guix: nsis (Windows installer creator) is broken upstream":
(https://github.com/bitcoin/bitcoin/issues/32674#issuecomment-2936886240)
It fails building on `x86_64`, `aarch64` and with `--system=riscv64-linux`.

💬 maflcko commented on pull request "test: wallet: cover wallet passphrase with a null char":
(https://github.com/bitcoin/bitcoin/pull/32675#discussion_r2124757170)
might as well add coverage for `walletpassphrasechange` as well?

💬 l3x3l commented on issue "Unusual "Wallet requires newer version" Error with wallet.dat on macOS, Even with Older Client":
(https://github.com/bitcoin/bitcoin/issues/32548#issuecomment-2936896976)
It’s not corrupt. The wallet is just ahead of its time.

l3x3l
>--o--<


On Tue, Jun 3, 2025 at 1:21 PM maflcko ***@***.***> wrote:

> *maflcko* left a comment (bitcoin/bitcoin#32548)
> <https://github.com/bitcoin/bitcoin/issues/32548#issuecomment-2936836818>
>
> The wallet isn't corrupt.
>
> It is. Otherwise you wouldn't have to open this bug report. See also #32548
> (comment)
> <https://github.com/bitcoin/bitcoin/issues/32548#issuecomment-2889145174>
>
> The problem still st
...

💬 maflcko commented on pull request "test: apply microsecond precision to test framework logging":
(https://github.com/bitcoin/bitcoin/pull/32676#discussion_r2124781147)
I can see it fail if python internally passes `datefmt` as a keyword arg. I can see disabling the linter, because it may be wrong due to this. I can also see just saying `assert not datefmt` to ensure it is `None` and ensure the keyword is used. But no strong opinion. I think anything is fine here.

✅ maflcko closed an issue: "Unusual "Wallet requires newer version" Error with wallet.dat on macOS, Even with Older Client"
(https://github.com/bitcoin/bitcoin/issues/32548)

💬 maflcko commented on issue "Unusual "Wallet requires newer version" Error with wallet.dat on macOS, Even with Older Client":
(https://github.com/bitcoin/bitcoin/issues/32548#issuecomment-2936942299)
> It’s not corrupt. The wallet is just ahead of its time.

If the wallet is taken from the future, you can simply take the Bitcoin Core version from the same future. However, this is getting a bit abstract.

I'll close this issue for now, but of course the discussion can continue, if there is need to.

💬 Crypt-iQ commented on pull request "log: Mitigate disk filling attacks by rate limiting LogPrintf, LogInfo, LogWarning, LogError":
(https://github.com/bitcoin/bitcoin/pull/32604#discussion_r2124802864)
I came to the conclusion that because macros don't have default arguments, skipping the rate limiting for `UpdateTipLog` means that we need to: 1) introduce a new macro for IBD specifically for `UpdateTipLog`, or 2) modify all call-sites of whichever macro `UpdateTipLog` uses to accept a `rate_limit` argument.

I don't want to introduce a new macro only for tip logging since there are quite a few already, but I think it could be a better choice than adding more noise to the categories. I also
...

💬 mzumsande commented on pull request "test: apply microsecond precision to test framework logging":
(https://github.com/bitcoin/bitcoin/pull/32676#discussion_r2124805762)
I don't have a strong opinion either, I just wanted to mention this because `_=None` may look weird to some - if the current approach is fine I'll just leave it at this.

💬 mzumsande commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#issuecomment-2937010984)
re-ACK a189d636184b1c28fa4a325b56c1fab8f44527b1

💬 ryanofsky commented on pull request "multiprocess: Add capnp wrapper for Chain interface":
(https://github.com/bitcoin/bitcoin/pull/29409#issuecomment-2937025683)
Rebased 4fa7f72cb9d8f0290f56293989ec6ea950162c5b -> f92422e308ec33e2b211b866e218efacc77a4f7f ([`pr/ipc-chain.13`](https://github.com/ryanofsky/bitcoin/commits/pr/ipc-chain.13) -> [`pr/ipc-chain.14`](https://github.com/ryanofsky/bitcoin/commits/pr/ipc-chain.14), [compare](https://github.com/ryanofsky/bitcoin/compare/pr/ipc-chain.13-rebase..pr/ipc-chain.14)) due to silent conflicts with #32438 and #32641

💬 l3x3l commented on issue "Unusual "Wallet requires newer version" Error with wallet.dat on macOS, Even with Older Client":
(https://github.com/bitcoin/bitcoin/issues/32548#issuecomment-2937030996)
I’ll open it in the future.

l3x3l
>--o--<


On Tue, Jun 3, 2025 at 1:50 PM maflcko ***@***.***> wrote:

> *maflcko* left a comment (bitcoin/bitcoin#32548)
> <https://github.com/bitcoin/bitcoin/issues/32548#issuecomment-2936942299>
>
> It’s not corrupt. The wallet is just ahead of its time.
>
> If the wallet is taken from the future, you can simply take the Bitcoin
> Core version from the same future. However, this is getting a bit abstract.
>
> I'll close this issue for now, but
...

💬 achow101 commented on issue "Unusual "Wallet requires newer version" Error with wallet.dat on macOS, Even with Older Client":
(https://github.com/bitcoin/bitcoin/issues/32548#issuecomment-2937098382)
> The problem still stands as to when Bitcoin Core for MacOS will release the version my wallet has. It looks like it will be quite sometime for that release to be available.

It is unlikely that that will ever happen.

For starters, it appears that your wallet is a BDB wallet, support for these has been dropped, although it is still possible to migrate them

The issue stemming from the version number is unlikely to change in the future too as there are no plans to continue to use the version nu
...

👍 theuni approved a pull request: "build: add -Wthread-safety-pointer"
(https://github.com/bitcoin/bitcoin/pull/32647#pullrequestreview-2894050205)
utACK 83bfe1485c37d407de7eed11b8ad769a05f78b66

💬 achow101 commented on pull request "descriptors: MuSig2":
(https://github.com/bitcoin/bitcoin/pull/31244#discussion_r2124891874)
Checking for duplicates is actually a bit more complicated, and I'm thinking now that it would probably be easier to allow duplicates.

There are some scenarios where I think it's ambiguous whether they should be allowed. For example, would `musig(xpub/1,xpub/*)` be allowed? The same pubkey would appear twice for exactly one index.

💬 l3x3l commented on issue "Unusual "Wallet requires newer version" Error with wallet.dat on macOS, Even with Older Client":
(https://github.com/bitcoin/bitcoin/issues/32548#issuecomment-2937152358)
@achow101

💬 l3x3l commented on issue "Unusual "Wallet requires newer version" Error with wallet.dat on macOS, Even with Older Client":
(https://github.com/bitcoin/bitcoin/issues/32548#issuecomment-2937152553)
Wow Ava! Over 40,000!? That’s the end of time! What else do you need
from the dump to investigate?


l3x3l
>--o--<


On Tue, Jun 3, 2025 at 2:31 PM Ava Chow ***@***.***> wrote:

> *achow101* left a comment (bitcoin/bitcoin#32548)
> <https://github.com/bitcoin/bitcoin/issues/32548#issuecomment-2937098382>
>
> The problem still stands as to when Bitcoin Core for MacOS will release
> the version my wallet has. It looks like it will be quite sometime for that
> release to be availa
...

💬 davidgumberg commented on pull request "test: apply microsecond precision to test framework logging":
(https://github.com/bitcoin/bitcoin/pull/32676#discussion_r2124904485)
Ah, thanks for the context, I hadn't checked since I assumed the format specifiers would not differ between `datetime.datetime.strftime()` and `strftime()`, but I can confirm that applying the diff I suggest, the logs look exactly as @mzumsande indicated, and the microseconds are not printed.

💬 glozow commented on pull request "p2p: improve TxOrphanage denial of service bounds":
(https://github.com/bitcoin/bitcoin/pull/31829#discussion_r2124892503)
added