💬 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

💬 fanquake commented on pull request "doc: improve NODE_NETWORK_LIMITED documentation per BIP159":
(https://github.com/bitcoin/bitcoin/pull/31805#issuecomment-2876206872)
What is the status of this?

💬 fanquake commented on pull request "[28.x] Backports":
(https://github.com/bitcoin/bitcoin/pull/32299#issuecomment-2876216158)
> was left out of the release notes

Fixed that up.

💬 l0rinc commented on pull request "doc: document workaround and fallback for macOS fuzzing":
(https://github.com/bitcoin/bitcoin/pull/32084#discussion_r2086646426)
Mac did trick me a few times into thinking the code was ok :/
Should I just close the PR?

💬 Kixunil commented on pull request "contrib: add xor-blocks tool to obfuscate blocks directory":
(https://github.com/bitcoin/bitcoin/pull/32451#discussion_r2086650095)
Oh, it's actually very easy to get 8B of non-secure entropy and this is sufficient for masking: `std::hash::DefaultHasher::new().finish().to_ne_bytes()` So it can cut the dependency entirely.

👍 willcl-ark approved a pull request: "[28.x] Backports"
(https://github.com/bitcoin/bitcoin/pull/32299#pullrequestreview-2836475325)
ACK 812e6375213e883a0c22aa926ebcde5da4d23a3e

Only changes to release note since previous ACK.

💬 Kixunil commented on pull request "contrib: add xor-blocks tool to obfuscate blocks directory":
(https://github.com/bitcoin/bitcoin/pull/32451#discussion_r2086653142)
Requires the `rayon` dependency. But I strongly suspect the entire thing is bottlenecked on IO.

💬 Kixunil commented on pull request "contrib: add xor-blocks tool to obfuscate blocks directory":
(https://github.com/bitcoin/bitcoin/pull/32451#discussion_r2086658185)
Oh, I see, that's clever! But then yes, this code tries to be atomic but it isn't because it doesn't call `sync_data`.

💬 Kixunil commented on pull request "contrib: add xor-blocks tool to obfuscate blocks directory":
(https://github.com/bitcoin/bitcoin/pull/32451#discussion_r2086662922)
Could also do it with like 4096B blocks at the time. I don't see how it would be slower since that's what `read` has to do anyway. (Though perhaps using `BufReader` would be better.)

👍 theStack approved a pull request: "signet: omit commitment for some trivial challenges"
(https://github.com/bitcoin/bitcoin/pull/29032#pullrequestreview-2836450095)
Code-review ACK 6adec89e3961508875e79240a19bc981e5addf1a

Left a few non-blocking nits below. I was wondering whether OP_2...OP_16 should also be treated as trivial, i.e. extend the OP_TRUE check to a range (0x81-0x96)? On one hand I can't imagine why anyone would want to use those (and even if, they could always do it via the one byte longer `0102`...`0110` instead), on the other hand one could just include them for consistency reasons.