💬 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)

💬 ryanofsky commented on issue "bench: `linearizeoptimallyexample11` benchmark now running 4x slow than previously":
(https://github.com/bitcoin/bitcoin/issues/31178#issuecomment-2450213536)
After testing this, it does seem like, in practice, the slowdown comes from checking the `g_fuzzing` variable, not from evaluating the assume condition. I don't agree with (or don't understand) Marco's logic that this was neccesarily the case, since before #31093 if the compiler knew evaluating the assume condition didn't have side effects and that result of the assume condition was not used, it would have no reason to evaluate it before #31093, but would need to evaluate it after #31093, so an
...

💬 fanquake commented on issue "Remove libevent as a dependency (HTTP / cli / torcontrol)":
(https://github.com/bitcoin/bitcoin/issues/31194#issuecomment-2450216192)
> Moreover, the new non-released code breaks our fuzzing tests. See: https://github.com/bitcoin/bitcoin/issues/30096.

I'm not so sure that's relevant. I think the conclusion in that issue was that vcpkg should probably stop shipping unstable/unreleased code, and I don't think we care about fuzzing unreleased versions of dependencies. It's less suprising that code which is still in development / might have API or other breaking changes we haven't accounted for might not work correctly.