💬 fanquake commented on pull request "[28.x] build: suppress `-Wunterminated-string-initialization` in secp256k1":
(https://github.com/bitcoin/bitcoin/pull/32484#issuecomment-2886842840)
Changed this, as the prior approach would warn under Clang.

👍 pinheadmz approved a pull request: "rpc: Round verificationprogress to 1 for a recent tip"
(https://github.com/bitcoin/bitcoin/pull/32528#pullrequestreview-2846776698)
ACK 11116aa19f5173792f757276c8a58b279f18a199

Built and tested on macos/arm64. Reviewed the code. Grudgingly I accept that this is a user complaint that will never go away and since the PR only updates the UI I'm ok with it after all.

`guessVerificationProgress()` will now return `1` if the timestamp in the chain tip is within the last two hours. (Probably should have a release note?)

That gives the following result in the log when I finished syncing my mainnet full node (at about 13:40:
...

💬 pinheadmz commented on pull request "rpc: add "ischange: true" to decoded tx outputs in wallet gettransaction response":
(https://github.com/bitcoin/bitcoin/pull/32517#discussion_r2093141438)
done

💬 l0rinc commented on pull request "policy: make pathological transactions packed with legacy sigops non-standard":
(https://github.com/bitcoin/bitcoin/pull/32521#issuecomment-2886851641)
While sigops aren't necessarily difficult to compute, there's a lot of them - and now even more.
Please consider the related sigop optimization PR I just pushed: https://github.com/bitcoin/bitcoin/pull/32532

🤔 l0rinc requested changes to a pull request: "node: cap `-maxmempool` and `-dbcache` values for 32-bit"
(https://github.com/bitcoin/bitcoin/pull/32530#pullrequestreview-2846799717)
Can you please explain this in more detail? Why would a 64 bit system care about the 32 bit limits?

I'm already often setting the dbcache to values like 45GiB (which is already way over the 32 bit limit), I'm not sure I understand the motivation for capping the mempool size to below 4.5 GiB - see:
https://github.com/bitcoin/bitcoin/pull/31645/files#diff-3d0856e8b7f136c588b229e0cbd3b2e2c309cd097ade0879521daba4e1bb2a33R1092-R1097

Same for the surprisingly low default values, could you pleas
...

💬 l0rinc commented on pull request "rpc: Round verificationprogress to 1 for a recent tip":
(https://github.com/bitcoin/bitcoin/pull/32528#issuecomment-2886877605)
Will this show `progress=1.000000` before the last block as well?
I find that more confusing than `0.999999` for the last one.

💬 pinheadmz commented on pull request "rpc: Round verificationprogress to 1 for a recent tip":
(https://github.com/bitcoin/bitcoin/pull/32528#issuecomment-2886905244)
> Will this show `progress=1.000000` before the last block as well?

How do you define "last block"? Or, more to the point, how does your full node "know" there are no more blocks out there? That's always been the UX issue, it's not accurate to ever claim we are 100% certain we are 100% synced.

💬 l0rinc commented on pull request "rpc: Round verificationprogress to 1 for a recent tip":
(https://github.com/bitcoin/bitcoin/pull/32528#issuecomment-2886912645)
So what does the percentage mean if there's no fixed target value in the first place?

💬 pinheadmz commented on pull request "rpc: Round verificationprogress to 1 for a recent tip":
(https://github.com/bitcoin/bitcoin/pull/32528#issuecomment-2886930544)
After this PR, it will mean your chain tip's timestamp is within 2 hours of now.

💬 vasild commented on pull request "Replace libevent with our own HTTP and socket-handling implementation":
(https://github.com/bitcoin/bitcoin/pull/32061#discussion_r2092931817)
Passing `-1717429609` would make this code try to access `weekdays[-1]` :fire:

For modern style, better use `std::array` instead of C arrays and, more importantly, use the array's `at()` method which has boundary checks, just in case. Here is a change that adds some more tests and fixes the out-of-bounds access:

<details>
<summary>[patch] FormatRFC7231DateTime()</summary>

```diff
diff --git i/src/test/util_tests.cpp w/src/test/util_tests.cpp
index 387493152d..ebb40dd713 100644
---
...

💬 vasild commented on pull request "Replace libevent with our own HTTP and socket-handling implementation":
(https://github.com/bitcoin/bitcoin/pull/32061#discussion_r2093076600)
e95c6f5b6511ae35141b1e440e1f22e1004d3de6

Copying strings is expensive:

```suggestion
std::optional<std::string_view> HTTPHeaders::Find(const std::string& key) const
```

💬 vasild commented on pull request "Replace libevent with our own HTTP and socket-handling implementation":
(https://github.com/bitcoin/bitcoin/pull/32061#discussion_r2093078641)
```suggestion
void HTTPHeaders::Write(const std::string& key, const std::string& value)
```

💬 vasild commented on pull request "Replace libevent with our own HTTP and socket-handling implementation":
(https://github.com/bitcoin/bitcoin/pull/32061#discussion_r2093181637)
Would be good to document when `Read()` throws, returns true and false.

🤔 vasild reviewed a pull request: "Replace libevent with our own HTTP and socket-handling implementation"
(https://github.com/bitcoin/bitcoin/pull/32061#pullrequestreview-2846448811)
Posting review midway. Reviewed up to and including e95c6f5b6511ae35141b1e440e1f22e1004d3de6 `http: Implement HTTPHeaders class`

💬 vasild commented on pull request "Replace libevent with our own HTTP and socket-handling implementation":
(https://github.com/bitcoin/bitcoin/pull/32061#discussion_r2093081846)
```suggestion
void HTTPHeaders::Remove(const std::string& key)
```

💬 jonatack commented on pull request "rpc: Round verificationprogress to 1 for a recent tip":
(https://github.com/bitcoin/bitcoin/pull/32528#issuecomment-2886931577)
Concept ACK

💬 mzumsande commented on issue "Change functional tests to trigger reorg by reconsiderblock":
(https://github.com/bitcoin/bitcoin/issues/32531#issuecomment-2886940689)
> We should make sure that in our reorg/mempool tests spread across the codebase that we don't do it this way and instead:
>
> 1. Prep fork chain of sufficient length
> 2. invalidate the fork chain
> 3. do normal test setup
> 4. reconsiderblock the previously invalidated chain
>
> This appears to match the intended test coverage.

Why not simply submit the fork chain at the right point in time, provided it has more work - no invalidateblock / reconsiderblock involved at all. I always thought t
...

📝 theStack opened a pull request: "test: properly check for per-tx sigops limit"
(https://github.com/bitcoin/bitcoin/pull/32533)
Currently the per-tx sigops limit standardness check (bounded by `MAX_STANDARD_TX_SIGOPS_COST`, throwing "bad-txns-too-many-sigops" if exceeded):
https://github.com/bitcoin/bitcoin/blob/3f83c744ac28b700090e15b5dda2260724a56f49/src/validation.cpp#L925-L927

is only indirectly tested with the much higher per-block consensus limit (`MAX_BLOCK_SIGOPS_COST`):
https://github.com/bitcoin/bitcoin/blob/3f83c744ac28b700090e15b5dda2260724a56f49/test/functional/data/invalid_txs.py#L236-L242

I.e. an i
...

💬 instagibbs commented on issue "Change functional tests to trigger reorg by reconsiderblock":
(https://github.com/bitcoin/bitcoin/issues/32531#issuecomment-2886947178)
> Why not simply submit the fork chain at the right point in time

Sure, that works too, it just seemed easiest since you can use ~all the tooling to generate blockchains. e.g., if you want stuff in the fork blocks it's trivial to do via rpc.

💬 sipa commented on pull request "rpc: Round verificationprogress to 1 for a recent tip":
(https://github.com/bitcoin/bitcoin/pull/32528#issuecomment-2886989763)
> After this PR, it will mean your chain tip's timestamp is within 2 hours of now.

I think that's a worse cure than the disease. In case we **know** there are unprocessed blocks in the chain (because we have their headers), we shouldn't say progress: 1.