💬 Sjors commented on pull request "mining: add getCoinbase()":
(https://github.com/bitcoin/bitcoin/pull/33819#discussion_r2504862983)
To sum up what needs to happen if we delete instead of deprecate these old methods:

1. `sv2-tp` needs a new release that includes https://github.com/stratum-mining/sv2-tp/pull/59 (no problem, will happen anyway)
2. the SRI TP (draft) https://github.com/stratum-mining/sv2-apps/pull/59 needs to be updated to support both the old and new method (like `sv2-tp` does), sometime before v31 comes out (support for the old method can be dropped after v31 comes out, at the cost of dropping support for
...

💬 ismaelsadeeq commented on issue "Header-only support for waitNext()":
(https://github.com/bitcoin/bitcoin/issues/33756#issuecomment-3504051962)
Thanks for the context.

> This provides miners with additional revenue because they are less likely to mine a stale block [0]

Before doing this, I think we should benchmark in practice the usual latency between knowing about a valid new block header, downloading, validating, and switching the chain tip.
As you mentioned, for a node with a good connection and reasonable policy rules, compact block reconstruction should prevent any measurable latency. Also, we are likely going to have `SENDTEMPL
...

👍 maflcko approved a pull request: "ci: Add IWYU job"
(https://github.com/bitcoin/bitcoin/pull/33810#pullrequestreview-3435561658)
lgtm

💬 Sjors commented on pull request "mining: add getCoinbase()":
(https://github.com/bitcoin/bitcoin/pull/33819#issuecomment-3504056653)
@plebhash can you try to see if it's easy for you to support both `getCoinbase()` and `getCoinbaseTx()` in https://github.com/stratum-mining/sv2-apps/pull/59, preferring the first and falling back to the latter if it doesn't exist?

💬 Sjors commented on issue "Header-only support for waitNext()":
(https://github.com/bitcoin/bitcoin/issues/33756#issuecomment-3504084601)
> we should benchmark in practice the usual latency between knowing about a valid new block header, downloading, validating, and switching the chain tip

Agreed, ideally I'd like to see data from actual miners.

> compact block reconstruction should prevent any measurable latency

Yes, but with the recent trend of people using incompatible policies, we should prepare for a scenario where compact block relay (often) doesn't work.

I don't know if `SENDTEMPLATE` can fully compensate for broken com
...

🤔 marcofleon reviewed a pull request: "doc: reference fuzz coverage steps in quick-start"
(https://github.com/bitcoin/bitcoin/pull/33536#pullrequestreview-3435606541)
Concept ACK

💬 marcofleon commented on pull request "doc: reference fuzz coverage steps in quick-start":
(https://github.com/bitcoin/bitcoin/pull/33536#discussion_r2504902827)
nit: Not sure if "coverage reports" needs the backticks here?

💬 l0rinc commented on issue "malloc: Failed to allocate segment from range group - out of space":
(https://github.com/bitcoin/bitcoin/issues/33806#issuecomment-3504302105)
### 29

Seems v29 already had this problem:

<details>
<summary>-dbcache=45000 OOM @ height=500515, cache=8553.2MiB</summary>

```
2025-11-07T16:03:59Z UpdateTip: new best=0000000000000000008abb306f6c51b4dfd3aed47a3e46099a92dc164d4d6059 height=500515 version=0x20000000 log2_work=87.707859 tx=284945541 date='2017-12-22T09:02:59Z' progress=0.225917 cache=8553.2MiB(63023361txo)
Process 74025 launched: '/Users/lorinc/IdeaProjects/bitcoin/build/bin/bitcoind' (arm64)
Process 74025 stopped
* thread #35
...

💬 l0rinc commented on pull request "build: add `-W*-whitespace`":
(https://github.com/bitcoin/bitcoin/pull/32482#issuecomment-3504370470)
reACK 854269a785fc51602cc5ae018c666fc1d2659776

`git range-diff b271b34...854269a` indicates it's a simple rebase.

💬 gmaxwell commented on pull request "validation: reduce persisted UTXO set size by prioritizing positive lookups (RFC)":
(https://github.com/bitcoin/bitcoin/pull/33817#issuecomment-3505120463)
Hm. I don't know we were aware that you could turn off the filters in leveldb-- I thought they were used to also decide what level an entry might be in!

Have you tried to characterize if this opens up any DOS attacks with unconfirmed transactions?

💬 waketraindev commented on pull request "Prevent re-execution of sensitive commands from console history":
(https://github.com/bitcoin-core/gui/pull/909#discussion_r2505990347)
You’re right, a separate signal/slot wasn’t necessary here. I revisited the implementation, removed both the signal and slot, and consolidated the logic directly into RPCConsole::on_lineEdit_returnPressed, as you suggested, cleaning everything up. Thanks for taking a look at the PR!

💬 waketraindev commented on pull request "Prevent re-execution of sensitive commands from console history":
(https://github.com/bitcoin-core/gui/pull/909#issuecomment-3505624298)
* Blocking character was changed from '#' to '!' in order to reserve '#' for printing comments such as like bash
* Removed noop slot and signal
* Added alert window when a command starting with ! is entered
* Commands starting with ! don't print, and don't go to history

💬 yuvicc commented on pull request "kernel: Add block header support and validation":
(https://github.com/bitcoin/bitcoin/pull/33822#issuecomment-3506002531)
Fixed some lint errors.

🤔 yuvicc reviewed a pull request: "kernel: Expose `CheckTransaction` consensus validation function"
(https://github.com/bitcoin/bitcoin/pull/33796#pullrequestreview-3437677428)
Approach ACK

Great addition exposing `CheckTransaction` to the kernel API. This will be useful to external users needing context-free transaction validation.

💬 yuvicc commented on pull request "kernel: Expose `CheckTransaction` consensus validation function":
(https://github.com/bitcoin/bitcoin/pull/33796#discussion_r2506321358)
```suggestion
/**
* @brief Run consensus/tx_check::CheckTransaction on a transaction.
*
* Performs context-free consensus validation on a transaction without
* requiring blockchain state.
*
* @param[in] tx The transaction to validate
* @param[out] out_state Pointer to receive the validation state (always set,
* caller must destroy with btck_tx_validation_state_destroy)
* @return 1 if valid, 0 if invalid
*/
```

💬 ArmchairCryptologist commented on issue "dnsseed.bitcoin.dashjr-list-of-p2p-nodes.us appears to be violating DNS seed policy":
(https://github.com/bitcoin/bitcoin/issues/33734#issuecomment-3506113602)
> For the record, the current range of accepted versions is 0.21.1-28.*. If you are observing other versions, it is most likely because the node operator recently upgraded since the last crawl. There are currently 3567 "good" nodes being chosen from for results, which seems more than sufficient for now. (While this doesn't break the policy in any way, maybe it would be about time to expand the scope since 28.x is no longer maintained.)

It seems to me that intentionally configuring your DNS seed
...

💬 big14way commented on issue "ASAN use-after-free in `m_reconnections`":
(https://github.com/bitcoin/bitcoin/issues/33615#issuecomment-3506144248)
@maflcko please assign this issue to me let me fix the bug

💬 big14way commented on issue "Inconsistent CJDNS address handling in Local addresses and AddLocal logs":
(https://github.com/bitcoin/bitcoin/issues/33471#issuecomment-3506148172)
@willcl-ark please assign me this issue i can fix this bug

📝 maflcko opened a pull request: " ci: Use cmake --preset=dev-mode in test-each-commit task "
(https://github.com/bitcoin/bitcoin/pull/33823)
Using the preset should reduce the bloat and need to maintain several places to list the same cmake cache variables.

The only difference should be that `bitcoin-chainstate (experimental)` will be enabled, which seems fast and in line with the goal of the CI task.

* Before: https://github.com/bitcoin/bitcoin/actions/runs/19174075826/job/54814118651#step:8:315
* After: (this pull)

diff:

```diff

👍 danielabrozzoni approved a pull request: "log: avoid collecting `GetSerializeSize` data when compact block logging is disabled"
(https://github.com/bitcoin/bitcoin/pull/33738#pullrequestreview-3437924068)
Code Review ACK 10e0e96e703a40b298b87e9943f85d5189b9e3dc

Code looks good to me, I ran the tests locally, but I didn’t perform any additional testing beyond that.