💬 fanquake commented on issue "Warn about / refuse unsupported clang version":
(https://github.com/bitcoin/bitcoin/issues/30947#issuecomment-2450109402)
> Which clang version are we suposed to use?

https://github.com/bitcoin/bitcoin/blob/master/doc/dependencies.md

💬 hodlinator commented on pull request "optimization: change XOR obfuscation key from `std::vector<std::byte>(8)` to `uint64_t`":
(https://github.com/bitcoin/bitcoin/pull/31144#discussion_r1824645305)
> This pattern has been [used before](https://github.com/bitcoin/bitcoin/blob/master/src/coins.cpp#L64)

In the example you give, the variable is used in a more "positive" sense. Here we test the negated value, which is part of what makes it jarring.

One could maybe improve readability by moving the negation and renaming:
```suggestion
if (bool unknown_key = !Read(OBFUSCATE_KEY_KEY, obfuscate_key_vector); unknown_key && params.obfuscate && IsEmpty()) {
```

> I meant to narrow the
...

💬 maflcko commented on issue "bench: `linearizeoptimallyexample11` benchmark now running 4x slow than previously":
(https://github.com/bitcoin/bitcoin/issues/31178#issuecomment-2450130161)
> so unless the compiler knows `<check expression>` does not have side effects, must execute it and can't optimize it out?

Correct, but the that hasn't been changed by `g_fuzzing` at all. It is not the execution of `<check expression>`, but the execution of the negation of it, and the corresponding expensive branch in hot paths which has to be emitted for the unlikely case that the negation evaluates to true.

💬 fanquake commented on pull request "depends: For mingw cross compile use -gcc-posix to prevent library conflict":
(https://github.com/bitcoin/bitcoin/pull/31013#issuecomment-2450135287)
Backporting to 28.x in #31104 for consistency.

💬 l0rinc commented on pull request "optimization: change XOR obfuscation key from `std::vector<std::byte>(8)` to `uint64_t`":
(https://github.com/bitcoin/bitcoin/pull/31144#discussion_r1824651933)
You're right, I've used `xor_key` in the same case before

💬 l0rinc commented on pull request "optimization: change XOR obfuscation key from `std::vector<std::byte>(8)` to `uint64_t`":
(https://github.com/bitcoin/bitcoin/pull/31144#discussion_r1824652007)
But done anyway

💬 l0rinc commented on pull request "optimization: change XOR obfuscation key from `std::vector<std::byte>(8)` to `uint64_t`":
(https://github.com/bitcoin/bitcoin/pull/31144#discussion_r1824652156)
Removed, thanks

💬 l0rinc commented on pull request "optimization: change XOR obfuscation key from `std::vector<std::byte>(8)` to `uint64_t`":
(https://github.com/bitcoin/bitcoin/pull/31144#discussion_r1824652216)
Simplified, thanks

💬 l0rinc commented on pull request "optimization: change XOR obfuscation key from `std::vector<std::byte>(8)` to `uint64_t`":
(https://github.com/bitcoin/bitcoin/pull/31144#discussion_r1824652442)
Done, thanks

💬 l0rinc commented on pull request "optimization: change XOR obfuscation key from `std::vector<std::byte>(8)` to `uint64_t`":
(https://github.com/bitcoin/bitcoin/pull/31144#discussion_r1824655597)
Removed in the end, not that important

💬 sipa commented on issue "bench: `linearizeoptimallyexample11` benchmark now running 4x slow than previously":
(https://github.com/bitcoin/bitcoin/issues/31178#issuecomment-2450144705)
> Correct, but the that hasn't been changed by `g_fuzzing` at all.

Ah, right, it's possible that the compiler can turn `Assume(<expr>);` into `if (g_fuzzing) { bool x = <expr>; if (!x) { ... } }`, where `<expr>` is not evaluated at all if `g_fuzzing` is false. I was operating under the assumption that with the emitted branch, `<expr>` would always be evaluated even if side-effect free, but that is indeed not the case.

Still, just the fact that the `g_fuzzing` condition is there means a con
...

⚠️ darosior opened an issue: "(Past issue) On Windows, pruned nodes could crash while deleting a block file"
(https://github.com/bitcoin/bitcoin/issues/31193)
This was reported by @andrewtoth to the security list on 2022-12-20 and fixed in #26533. The security team at the time determined it was indeed a bug but not a vulnerability.

I'm opening this issue in public in order to leave a trace of this bug, which as far as i know wasn't public yet.

Original email from Andrew Toth on 2022-12-20:
> Hello,
>
> I have discovered a bug that can cause pruned nodes running on Windows to crash. Keeping an open file handle to a blk*.dat file on Windows c
...

✅ darosior closed an issue: "(Past issue) On Windows, pruned nodes could crash while deleting a block file"
(https://github.com/bitcoin/bitcoin/issues/31193)

💬 TheCharlatan commented on pull request "kernel, refactor: return error status on all fatal errors":
(https://github.com/bitcoin/bitcoin/pull/29700#issuecomment-2450150408)
Can you rebase this?

⚠️ pinheadmz opened an issue: "Remove libevent as a dependency (HTTP / cli / torcontrol)"
(https://github.com/bitcoin/bitcoin/issues/31194)
## Immediate advantages
### UNIX domain sockets for JSON-RPC
- Old feature request: https://github.com/bitcoin/bitcoin/issues/5029
- UNIX sockets have been added to [ZMQ](https://github.com/bitcoin/bitcoin/pull/27679) and [Tor proxy](https://github.com/bitcoin/bitcoin/pull/27375) already
- UNIX sockets with libevent [doesn't work](https://github.com/bitcoin/bitcoin/issues/5029#issuecomment-2203469108)
### Remove a dependency
- libevent hasn't had a release since 2020
- The [xz utils back
...

💬 maflcko commented on issue "bench: `linearizeoptimallyexample11` benchmark now running 4x slow than previously":
(https://github.com/bitcoin/bitcoin/issues/31178#issuecomment-2450166919)
In any case https://github.com/bitcoin/bitcoin/pull/31191 should fix the recently introduced `g_fuzzing` regression. If there are suggestions for other (more fundamental) changes or alternative code patches, separate pull requests would probably be best going forward. I am happy to review any of them, if they exist.

💬 andrewtoth commented on issue "(Past issue) On Windows, pruned nodes could crash while deleting a block file":
(https://github.com/bitcoin/bitcoin/issues/31193#issuecomment-2450172504)
Reason for reporting is that a user on the same system with only read access to the bitcoind datadir could cause bitcoind to crash. This could be seen as a form of privilege escalation. I thought it was low, but still reported in case there was something I was missing.

💬 hebasto commented on issue "Remove libevent as a dependency (HTTP / cli / torcontrol)":
(https://github.com/bitcoin/bitcoin/issues/31194#issuecomment-2450190667)
> * libevent hasn't had a release since 2020

Moreover, the new non-released code breaks our fuzzing tests. See: https://github.com/bitcoin/bitcoin/issues/30096.

⚠️ darosior opened an issue: "(Past issue) The alert system enabled a disk-filling attack"
(https://github.com/bitcoin/bitcoin/issues/31195)
This is about a low severity issue impacting a feature removed for a decade. I can't find any public discussion about it so i'm just opening an issue to leave a trace.

This was reported on 2013-03-01 by @SergioDemianLerner that the alert system could fill-up the disk with "signature failed" messages.

That's all the information i could recollect about this old issue.

✅ darosior closed an issue: "(Past issue) The alert system enabled a disk-filling attack"
(https://github.com/bitcoin/bitcoin/issues/31195)