💬 stickies-v commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#discussion_r2086553680)
nit: I think it's strange to let one test handle another test's pre's, would just keep this in `test_block_max_weight`?

<details>
<summary>git diff on c164064c26</summary>

```diff
diff --git a/test/functional/mining_basic.py b/test/functional/mining_basic.py
index 21451a9aaf..415a370b06 100755
--- a/test/functional/mining_basic.py
+++ b/test/functional/mining_basic.py
@@ -186,9 +186,6 @@ class MiningTest(BitcoinTestFramework):
assert tx_below_min_feerate['txid'] not in
...

💬 stickies-v commented on pull request "policy: uncap datacarrier by default":
(https://github.com/bitcoin/bitcoin/pull/32406#discussion_r2086563850)
nit: would make sense to actually use `test_framework.script.MAX_SCRIPT_ELEMENT_SIZE` here?

🚀 fanquake merged a pull request: "refactor: Remove unused HaveKey and HaveWatchOnly"
(https://github.com/bitcoin/bitcoin/pull/32476)

💬 fanquake commented on pull request "doc: Add hint about avoiding spaces in paths when building on Windows":
(https://github.com/bitcoin/bitcoin/pull/32397#issuecomment-2876150177)
What is the status of this? Do we need to add something to the docs?

💬 fanquake commented on pull request "doc: update unix build doc with build flags":
(https://github.com/bitcoin/bitcoin/pull/32269#issuecomment-2876162598)
As mentioned, what you're adding is already present in this file, so if you're re-ordering things, you'll need to remove the second occurence.

💬 bufo24 commented on pull request "doc: update unix build doc with build flags":
(https://github.com/bitcoin/bitcoin/pull/32269#issuecomment-2876171103)
@fanquake Just did that!

💬 fanquake commented on pull request "doc: update unix build doc with build flags":
(https://github.com/bitcoin/bitcoin/pull/32269#issuecomment-2876174166)
Thanks. You'll need to squash your commits.

👍 l0rinc approved a pull request: "lint: Check for missing trailing newline"
(https://github.com/bitcoin/bitcoin/pull/32477#pullrequestreview-2836345824)
Concept ACK - thanks for automating yet another nit that I hate being brought up during review!

Should we apply this to a few other file types as well - and take advantage of the naturally independent and parallelizable nature of the problem?

💬 l0rinc commented on pull request "lint: Check for missing trailing newline":
(https://github.com/bitcoin/bitcoin/pull/32477#discussion_r2086617492)
would it help if we used `.par_iter()` here instead (not sure if that would require adding a new lib or not, but seems like a naturally parallelizable task)?

💬 l0rinc commented on pull request "lint: Check for missing trailing newline":
(https://github.com/bitcoin/bitcoin/pull/32477#discussion_r2086587961)
Should we add any other ones here?
```bash
$ find . -type f -exec grep -Il . {} + | rev | cut -d. -f1 | rev | sort | uniq -c | sort -nr
1266 json
721 cpp
704 h
461 d
344 py
275 cmake
228 md
162 ts
145 make
89 cc
73 txt
49 sh
43 mk
32 patch
32 hex
28 c
27 in
26 internal
20 svg
19 ui
16 yml
14 sample
14 gitignore
13 marks
11 m4
10 capnp
9 sage
8 xml
8 1
6 rc
6 ninja
6 include
6 fish
6 bash
5 x
...

💬 l0rinc commented on pull request "lint: Check for missing trailing newline":
(https://github.com/bitcoin/bitcoin/pull/32477#discussion_r2086594083)
haven't tried it, but was wondering it this would also work with [chaining](https://doc.rust-lang.org/std/iter/struct.Chain.html#examples) the iterators?
```suggestion
get_subtrees()
.into_iter()
.chain(["doc/release-notes/release-notes-*"]) // archived notes
```

💬 bufo24 commented on pull request "doc: update unix build doc with build flags":
(https://github.com/bitcoin/bitcoin/pull/32269#issuecomment-2876181111)
Done

💬 Sjors commented on pull request "doc: update CWallet::SignTransaction doc to mention SIGHASH_DEFAULT":
(https://github.com/bitcoin/bitcoin/pull/32411#issuecomment-2876195871)
They're only the same for Taproot inputs.

cc @achow101

💬 fanquake commented on pull request "doc: document workaround and fallback for macOS fuzzing":
(https://github.com/bitcoin/bitcoin/pull/32084#discussion_r2086633989)
I agree. We might be best changing this documentation to something like: "If you have issues fuzzing on macOS, try using Linux".

💬 fanquake commented on pull request "doc: corrected lockunspent rpc quoting":
(https://github.com/bitcoin/bitcoin/pull/31275#issuecomment-2876201952)
@Talej Can you rebase this?

👍 willcl-ark approved a pull request: "[28.x] Backports"
(https://github.com/bitcoin/bitcoin/pull/32299#pullrequestreview-2836453276)
crACK a325ca34653872534529e7934d07fe4e2ca29cae

Backports all look clean to me.

Would only check that #32299 was left out of the release notes intentionally (it's not really "notable")?

💬 l0rinc commented on pull request "contrib: add xor-blocks tool to obfuscate blocks directory":
(https://github.com/bitcoin/bitcoin/pull/32451#discussion_r2086632854)
we would reapply the xor on restart in that case, since we wouldn't detect that we've processed it already.

Alternatively we could keep a counter of processed blocks - modify the `xor.dat` to make sure we can't start `bitcoind` (or @LarryRuane's lock would probably also do the same) and add a height of how many blocks we've processed so far (though that would make parallelization more difficult). When we're done we'd restore the `xor.dat` file (which we have to modify anyway if we're xor-ing)
...

💬 l0rinc commented on pull request "contrib: add xor-blocks tool to obfuscate blocks directory":
(https://github.com/bitcoin/bitcoin/pull/32451#discussion_r2086624487)
would it help if we used `.par_iter()` here instead (not sure if that would require adding a new lib or not, but seems like a naturally parallelizable task)?

💬 l0rinc commented on pull request "contrib: add xor-blocks tool to obfuscate blocks directory":
(https://github.com/bitcoin/bitcoin/pull/32451#discussion_r2086608673)
xor is an implementation detail - I'd make it more user friendly and call it obfuscation instead

💬 l0rinc commented on pull request "contrib: add xor-blocks tool to obfuscate blocks directory":
(https://github.com/bitcoin/bitcoin/pull/32451#discussion_r2086626017)
We're regularly loading blocks into memory - if we want any performance out of this, we definitely want that in my experience