🤔 mzumsande reviewed a pull request: "refactor: validation: mark CheckBlockIndex as const"
(https://github.com/bitcoin/bitcoin/pull/32364#pullrequestreview-2810060421)
Given that #30214 wants to removes `GetAll()` anyway in 64fc6603525f515c5303f557b038753904c6541(FYI @ryanofsky), the simplest solution might be to just not use `GetAll` and just iterate over `m_ibd_chainstate.get()` and `m_snapshot_chainstate.get()` by hand - this would have the added benefit that we could replace the (`IsUsable(cs)` by just a not-nullptr check for cs, because I don't see a conceptual reason why a disabled chainstate (whether it's invalid, or fully validated) shouldn't be subjec
...

💬 darosior commented on pull request "policy: allow more than one OP_RETURN outputs per tx":
(https://github.com/bitcoin/bitcoin/pull/32381#issuecomment-2845092974)
> Would it be possible to summarize the pros and cons raised across the internets in the PR description - if for no other reason, to avoid repeated comments on the same topic?

I gave the rationale for this [on the mailing list](https://gnusha.org/pi/bitcoindev/rhfyCHr4RfaEalbfGejVdolYCVWIyf84PT2062DQbs5-eU8BPYty5sGyvI3hKeRZQtVC7rn_ugjUWFnWCymz9e9Chbn7FjWJePllFhZRKYk=@protonmail.com/). I also gave more background in [a blog post](https://antoinep.com/posts/relay_policy_drama/) i just published
...

💬 TheCharlatan commented on pull request "[IBD] specialize block serialization":
(https://github.com/bitcoin/bitcoin/pull/31868#issuecomment-2845097684)
> If IBD speedup is not the main motivation, what else is the motivation, given that the title mentions [IBD]?

I think block serialization being fast could be useful for future kernel users. Reading and de-serializing blocks is one of the common operations I'd expect outside of just pure block validation.

💬 achow101 commented on issue "Moving this repo to bitcoin-core":
(https://github.com/bitcoin/bitcoin/issues/32340#issuecomment-2845199058)
One thing to mention is that several contributors are not comfortable with transferring the ownership of the bitcoin github org to anyone else, so regardless of any moves, the current bitcoin org owners will remain unchanged and no new owners added.

💬 adamandrews1 commented on issue "combinerawtransaction confusing with distinct transactions":
(https://github.com/bitcoin/bitcoin/issues/25980#issuecomment-2845219326)
> Could I try this issue?

Would you mind reviewing https://github.com/bitcoin/bitcoin/pull/31298 instead?

This solution is still up to date, it just hasn't gotten the right reviewers.

🤔 adamandrews1 reviewed a pull request: "rpc: Support v3 raw transactions creation"
(https://github.com/bitcoin/bitcoin/pull/31936#pullrequestreview-2810199344)
utACK 63d9b9e3b8e225eccd55209e7a4213604ec88425

Suggested some improvements, but not blocking ones IMO

💬 adamandrews1 commented on pull request "rpc: Support v3 raw transactions creation":
(https://github.com/bitcoin/bitcoin/pull/31936#discussion_r2070507164)
The final parameter (tx version) for this test should be set to `TX_MAX_STANDARD_VERSION + 1` or at least to a number with headroom like `999`.

💬 adamandrews1 commented on pull request "rpc: Support v3 raw transactions creation":
(https://github.com/bitcoin/bitcoin/pull/31936#discussion_r2070505150)
This RPC error should be a formatted string so that it remains accurate as `TX_MIN_STANDARD_VERSION` and `TX_MAX_STANDARD_VERSION` get updated.

💬 adamandrews1 commented on pull request "rpc: Support v3 raw transactions creation":
(https://github.com/bitcoin/bitcoin/pull/31936#discussion_r2070510962)
Shouldn't this test be repeated for each valid `tx.version` in the range `[TX_MIN_STANDARD_VERSION, TX_MAX_STANDARD_VERSION]`?

💬 ismaelsadeeq commented on pull request "cluster mempool: add txgraph diagrams/mining/eviction":
(https://github.com/bitcoin/bitcoin/pull/31444#issuecomment-2845296384)
reACK https://github.com/bitcoin/bitcoin/commit/7208ec2f1f0b9d72e1b4248dae9adbcc5ab625f7

💬 BullishNode commented on issue "Allow sending untrusted utxos in the sendtoaddress api":
(https://github.com/bitcoin/bitcoin/issues/32034#issuecomment-2845322901)
No, a, unconfirmed transaction coming from an external wallet does not need external mechanism to sign.

📝 Brotcrunsher opened a pull request: "doc: Add hint about avoiding spaces in paths when building on Windows"
(https://github.com/bitcoin/bitcoin/pull/32397)
When running the configuration step

cmake -B build --preset vs2022-static

from a directory with spaces in its path, CMake issues the following warning:

Warning: Paths with embedded space may be handled incorrectly by configure

The build subsequently fails with error code 77.

While the underlying issue should ideally be resolved, this hint may help users avoid related build failures in the meantime.

💬 BullishNode commented on issue "Allow sending untrusted utxos in the sendtoaddress api":
(https://github.com/bitcoin/bitcoin/issues/32034#issuecomment-2845360188)
I meant that the transaction is coming from another wallet, not the input utxo.

💬 pinheadmz commented on pull request "bitcoin-cli: Add -ipcconnect option":
(https://github.com/bitcoin/bitcoin/pull/32297#discussion_r2070586745)
ea98a42640b9ff77a462e55887025ddd1da54727

Might want to indicate `status` is an "out" param?

I notice this also bypasses our only authorization barrier for RPC which is an HTTP header, maybe you deal with this in another commit but that should probably be documented in the `ipcbind` help text

💬 achow101 commented on issue "Allow sending untrusted utxos in the sendtoaddress api":
(https://github.com/bitcoin/bitcoin/issues/32034#issuecomment-2845443782)
Concept NACK

What problem specifically would this solve for you? If you know which untrusted inputs you want to pick and you just want to use fewer commands, the `send` RPC should work for that purposes as you can specify inputs to use, and it can fill in more if needed. If you want to be able to select any untrusted inputs automatically, I think that is a non-starter as it's a pretty big footgun.

💬 laanwj commented on pull request "doc: Add hint about avoiding spaces in paths when building on Windows":
(https://github.com/bitcoin/bitcoin/pull/32397#issuecomment-2845465336)
That's too bad, we'd finally solved all the build-with-spaces issues with the old build system.

But yes i suppose it doesn't hurt too add a warning in the meantime...

📝 strmfos opened a pull request: "chore(ci): bump docker/build-push-action to v6.16.0"
(https://github.com/bitcoin/bitcoin/pull/32398)
• update workflow to latest major for security patches & Buildx features

[Reference](https://github.com/docker/build-push-action/releases/tag/v6.16.0)

✅ achow101 closed an issue: ""Rolling forward" at startup can take a long time, and is not interruptible (after unclean shutdown)"
(https://github.com/bitcoin/bitcoin/issues/11600)

🚀 achow101 merged a pull request: "validation: write chainstate to disk every hour"
(https://github.com/bitcoin/bitcoin/pull/30611)

✅ fanquake closed a pull request: "chore(ci): bump docker/build-push-action to v6.16.0"
(https://github.com/bitcoin/bitcoin/pull/32398)

💬 andrewtoth commented on issue ""Rolling forward" at startup can take a long time, and is not interruptible (after unclean shutdown)":
(https://github.com/bitcoin/bitcoin/issues/11600#issuecomment-2845541462)
Woohoo!