💬 maflcko commented on pull request "clang-tidy: Apply modernize-deprecated-headers":
(https://github.com/bitcoin/bitcoin/pull/32673#discussion_r2124518776)
It is needed, see:

[09:40:31.692] The full include-list for /ci_container_base/src/bech32.h:
[09:40:31.692] #include <cstdint> // for uint8_t

💬 maflcko commented on pull request "clang-tidy: Apply modernize-deprecated-headers":
(https://github.com/bitcoin/bitcoin/pull/32673#discussion_r2124554639)
thx, sorted

💬 maflcko commented on pull request "clang-tidy: Apply modernize-deprecated-headers":
(https://github.com/bitcoin/bitcoin/pull/32673#discussion_r2124553705)
there are several, so maybe a separate pull request or linter could be added for this? Although, I don't see a risk here.

```
src/base58.h:14:#ifndef BITCOIN_BASE58_H
src/bech32.h:14:#ifndef BITCOIN_BECH32_H
src/common/messages.h:11:#ifndef BITCOIN_COMMON_MESSAGES_H
src/common/types.h:13:#ifndef BITCOIN_COMMON_TYPES_H
src/net_permissions.h:12:#ifndef BITCOIN_NET_PERMISSIONS_H
src/node/types.h:13:#ifndef BITCOIN_NODE_TYPES_H
src/txgraph.h:14:#ifndef BITCOIN_TXGRAPH_H
src/wallet/types.h
...

🤔 polespinasa reviewed a pull request: "tests: Expand HTTP coverage to assert libevent behavior"
(https://github.com/bitcoin/bitcoin/pull/32408#pullrequestreview-2893647989)
LGTM friendly acknowledging this PR :)
ACK f16c8c67bf137e64fbeea1242431baaa915a5c53

Agree on the 5sec timeout change, we avoid weird errors if the CI is lazy.

I locally rebased this on top of master (e872a566f251c73908de8b6d243c94a6679c2eac) to make sure there aren't silent merging conflicts that make the test fail. It works correctly :)

📝 stringintech opened a pull request: "test: headers sync timeout"
(https://github.com/bitcoin/bitcoin/pull/32677)
When reviewing PR #32051 and considering which functional tests might need to be adapted/extended accordingly, I noticed there appears to be limited functional test coverage for header sync timeouts and thought it might be helpful to add one.

This test attempts to cover two scenarios:

1. **Normal peer timeout behavior:** When a peer fails to respond to initial getheaders requests within the timeout period, it should be disconnected and the node should attempt to sync headers from the next
...

🤔 maflcko reviewed a pull request: "test: apply microsecond precision to test framework logging"
(https://github.com/bitcoin/bitcoin/pull/32676#pullrequestreview-2893719748)
nice!

review ACK ed179e0a6528c39b3bca76365f256716f917e19b 🗳

<details><summary>Show signature</summary>

Signature:

```
untrusted comment: signature from minisign secret key on empty file; verify via: minisign -Vm "${path_to_any_empty_file}" -P RWTRmVTMeKV5noAMqVlsMugDDCyyTSbA3Re5AkUrhvLVln0tSaFWglOw -x "${path_to_this_whole_four_line_signature_blob}"
RUTRmVTMeKV5npGrKx1nqXCw5zeVHdtdYURB/KlyA/LMFgpNCs+SkW9a8N95d+U4AP1RJMi+krxU1A3Yux4bpwZNLvVBKy0wLgM=
trusted comment: review ACK ed1
...

💬 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-2936749799)
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.

💬 achow101 commented on pull request "test: enabling wallet migration functional test on windows":
(https://github.com/bitcoin/bitcoin/pull/32219#discussion_r2124675098)
I've always used my own guix builds, I don't use the script. However, I would prefer to not drop functionality.

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