💬 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!
(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.
(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?
(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)?
(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
...
(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
```
(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
(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
(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".
(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?
(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")?
(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)
...
(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)?
(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
(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
(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?
(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.
(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?
(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.
(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.
(https://github.com/bitcoin/bitcoin/pull/32299#pullrequestreview-2836475325)
ACK 812e6375213e883a0c22aa926ebcde5da4d23a3e
Only changes to release note since previous ACK.