💬 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

💬 glozow commented on pull request "p2p: improve TxOrphanage denial of service bounds":
(https://github.com/bitcoin/bitcoin/pull/31829#discussion_r2124894458)
ignoring because the constant gets deleted

💬 glozow commented on pull request "p2p: improve TxOrphanage denial of service bounds":
(https://github.com/bitcoin/bitcoin/pull/31829#discussion_r2124891663)
added a test that has 10 evictions in 1 go

💬 glozow commented on pull request "p2p: improve TxOrphanage denial of service bounds":
(https://github.com/bitcoin/bitcoin/pull/31829#discussion_r2124907696)
Restructured this way, with the help of 🪄 ✨AI ✨

💬 davidgumberg commented on pull request "test: apply microsecond precision to test framework logging":
(https://github.com/bitcoin/bitcoin/pull/32676#issuecomment-2937200960)
Tested ACK https://github.com/bitcoin/bitcoin/pull/32676/commits/ed179e0a6528c39b3bca76365f256716f917e19b

Added an `assert(0)` to `feature_abortnode.py` and on this branch, microsecond times are printed, on master (5471e29d057049d2b5a) they are not.

Didn't reproduce the described situation in the PR, but it makes sense that this would result in nonsensical ordering of logs any time you have sub-ms events, and I can recall having run into this before.


<details>

<summary>

### Test
...

💬 enirox001 commented on issue "Potential data race on fHavePruned flag":
(https://github.com/bitcoin/bitcoin/issues/21627#issuecomment-2937210740)
Sure, I can give it a go

💬 davidgumberg commented on pull request "deps: Bump lief to 0.16.6":
(https://github.com/bitcoin/bitcoin/pull/32431#issuecomment-2937216785)
```console
$ find guix-build-$(git rev-parse --short=12 HEAD)/output/ -type f -print0 | env LC_ALL=C sort -z | xargs -r0 sha256sum
```

```
9607cec72e511df72d1d07ef850015172d6c2707604f46694c019cd37903c65b guix-build-74dfa4155037/output/aarch64-linux-gnu/SHA256SUMS.part
30916e57efaa2bfd4265d840cde7049c863c4d35cec9d5e70681e7bc428e2d14 guix-build-74dfa4155037/output/aarch64-linux-gnu/bitcoin-74dfa4155037-aarch64-linux-gnu-debug.tar.gz
c462783e946c5e3e61a6a4ab4be1b8ddb6db9be07194d3241b43a8c
...

💬 achow101 commented on pull request "descriptors: MuSig2":
(https://github.com/bitcoin/bitcoin/pull/31244#discussion_r2124941224)
Done

💬 achow101 commented on pull request "descriptors: MuSig2":
(https://github.com/bitcoin/bitcoin/pull/31244#discussion_r2124941299)
Done