💬 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-2936762191)
> [@maflcko](https://github.com/maflcko) Remove the data corruption label.

Why? I think it is clear that the data is corrupt, but the cause of the corruption is unknown, likely a hardware failure.

💬 davidgumberg commented on pull request "test: apply microsecond precision to test framework logging":
(https://github.com/bitcoin/bitcoin/pull/32676#discussion_r2124692659)
non-blocking question/nit, why is this approach with a derived class of `logging.Formatter` preferable to modifying the `datefmt` string?

```diff
- formatter = logging.Formatter(fmt='%(asctime)s.%(msecs)03d000Z %(name)s (%(levelname)s): %(message)s', datefmt='%Y-%m-%dT%H:%M:%S')
+ formatter = logging.Formatter(fmt='%(asctime)sZ %(name)s (%(levelname)s): %(message)s', datefmt='%Y-%m-%dT%H:%M:%S.%f')

💬 maflcko commented on pull request "test: enabling wallet migration functional test on windows":
(https://github.com/bitcoin/bitcoin/pull/32219#discussion_r2124695723)
I never used it and it is broken anyway for newer release tags, that are using the cmake build system, so removing it seems fine for now. If someone is actually using it, it should be trivial to just check out the commit prior to this pull merged and use it. If someone wants to add it back, it should be trivial to recover the autotools portion from the git history and it should also be relatively easy to add the new cmake portion.

💬 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-2936795044)
> As this is the Bitcoin Core repo, you probably won't get any suggestions to use other software. Most of the contributors here use Bitcoin Core, and obviously our expertise is in this particular software. Personally, I suggest using Bitcoin Core as I will also be able to assist you if you run into further issues.

Sure. I'll get around to the rescan when I have space and when the version I mentioned is available. When do you think that will be?

💬 mzumsande commented on pull request "test: apply microsecond precision to test framework logging":
(https://github.com/bitcoin/bitcoin/pull/32676#discussion_r2124707366)
I tried that too - it doesn't work, it will print
`2025-06-03T19:12:56.%fZ TestFramework (INFO):`
See https://stackoverflow.com/questions/75035056/microsecond-do-not-work-in-python-logger-format for some background.

💬 maflcko commented on pull request "test: apply microsecond precision to test framework logging":
(https://github.com/bitcoin/bitcoin/pull/32676#discussion_r2124708211)
> non-blocking question/nit, why is this approach with a derived class of `logging.Formatter` preferable to modifying the `datefmt` string?
>
> ```diff
> - formatter = logging.Formatter(fmt='%(asctime)s.%(msecs)03d000Z %(name)s (%(levelname)s): %(message)s', datefmt='%Y-%m-%dT%H:%M:%S')
> + formatter = logging.Formatter(fmt='%(asctime)sZ %(name)s (%(levelname)s): %(message)s', datefmt='%Y-%m-%dT%H:%M:%S.%f')
> ```

Does it work locally? The docs say:

> The %f format directive only a
...

💬 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-2936811324)
> > [@maflcko](https://github.com/maflcko) Remove the data corruption label.
>
> Why? I think it is clear that the data is corrupt, but the cause of the corruption is unknown, likely a hardware failure.
>

The wallet isn't corrupt. I was able to recover keys and get the version of the wallet. 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.

💬 fanquake commented on pull request "depends: use "mkdir -p" when installing xproto":
(https://github.com/bitcoin/bitcoin/pull/32568#issuecomment-2936831629)
@willcl-ark Thanks for circling back around. We can follow up with the build env leakage.

✅ fanquake closed an issue: "build: (initial?) failure to build xproto on Alpine"
(https://github.com/bitcoin/bitcoin/issues/32494)

🚀 fanquake merged a pull request: "depends: use "mkdir -p" when installing xproto"
(https://github.com/bitcoin/bitcoin/pull/32568)

💬 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-2936836818)
> The wallet isn't corrupt.

It is. Otherwise you wouldn't have to open this bug report. See also https://github.com/bitcoin/bitcoin/issues/32548#issuecomment-2889145174



> The problem still stands as to when Bitcoin Core for MacOS will release the version my wallet has.

The wallet is understood to be corrupt. There will likely never be a release that can open it. You'll have to restore a non-corrupt backup or import the private keys into a newly created wallet.

💬 fanquake commented on pull request "depends: use "mkdir -p" when installing xproto":
(https://github.com/bitcoin/bitcoin/pull/32568#issuecomment-2936856287)
Backported to `29.x` in #32589.

👍 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.