📝 dergoegge opened a pull request: "fuzz: Improve fuzzing stability for txorphan harness"
(https://github.com/bitcoin/bitcoin/pull/29031)
The `txorphan` harness has low stability as eviction of orphan txs is entirely random at the moment.

Fix this by passing the rng to `LimitOrphans`, which can be deterministic in tests.

Also see #29018.

👋 dergoegge's pull request is ready for review: "fuzz: Improve fuzzing stability for txorphan harness"
(https://github.com/bitcoin/bitcoin/pull/29031)

💬 brunoerg commented on pull request "fuzz: Improve fuzzing stability for txorphan harness":
(https://github.com/bitcoin/bitcoin/pull/29031#issuecomment-1847155802)
Concept ACK

nice!

💬 furszy commented on pull request "wallet: batch all individual spkms setup db writes in a single db txn":
(https://github.com/bitcoin/bitcoin/pull/28894#discussion_r1420492611)
no, it doesn't. Initially, the `wallet_path` was inside the `bench.run()` lambda to create wallets under different paths. This was to avoid flushing the wallet to disk and removing the directory within the benchmark execution (which has nothing to do with what we are trying to benchmark). Then, at the end, I changed the approach to occupy less memory.

But.. thinking it further now, we could go back to the previous approach and not be concerned about memory by setting the max iterations number
...

💬 maflcko commented on pull request "fuzz: Improve fuzzing stability for txorphan harness":
(https://github.com/bitcoin/bitcoin/pull/29031#issuecomment-1847221427)
lgtm ACK 15f5a0d0c8ce6b306cdeba6a4777334b848a76aa

Didn't test the stability score.

💬 0xB10C commented on pull request "tracing: Only prepare tracepoint arguments when actually tracing":
(https://github.com/bitcoin/bitcoin/pull/26593#issuecomment-1847225184)
Rebased with https://github.com/bitcoin/bitcoin/pull/28349 merged.

> While this is rebased and ready for review again, I'd prefer progress on https://github.com/bitcoin/bitcoin/pull/25832 while we're exploring alternatives to https://github.com/bitcoin/bitcoin/pull/26593. I'll leave this as work-in-progress until we're clearer on alternatives.

I've also been working on a branch that adds tracepoint support for macOS and FreeBSD based on this branch. Doesn't need dtrace and doesn't need any
...

💬 dergoegge commented on pull request "fuzz: Improve fuzzing stability for txorphan harness":
(https://github.com/bitcoin/bitcoin/pull/29031#issuecomment-1847231728)
> Didn't test the stability score.

I'm seeing 87% stability locally, up from 51% reported by oss-fuzz. Not sure why it isn't a 100%, can't see anything else in the orphanage that would be non-deterministic.

👍 brunoerg approved a pull request: "fuzz: Improve fuzzing stability for txorphan harness"
(https://github.com/bitcoin/bitcoin/pull/29031#pullrequestreview-1772435486)
utACK 15f5a0d0c8ce6b306cdeba6a4777334b848a76aa

💬 maflcko commented on pull request "[POC] C++20 `std::endian`":
(https://github.com/bitcoin/bitcoin/pull/28674#discussion_r1420514261)
Could split this up from the other changes?

💬 nikodemas commented on issue "test: Add TestNode wait_until helper":
(https://github.com/bitcoin/bitcoin/issues/29029#issuecomment-1847303336)
Hi, I would like to work on this

💬 maflcko commented on pull request "build: no-longer disable WARN_CXXFLAGS when CXXFLAGS is set":
(https://github.com/bitcoin/bitcoin/pull/25972#issuecomment-1847306375)
```
./prevector.h:159:9: error: unknown pragma ignored [clang-diagnostic-unknown-pragmas]
159 | #pragma pack(pop)
| ^
clang-tidy-17 -p=/ci_container_base/ci/scratch/build/bitcoin-x86_64-pc-linux-gnu -quiet -load=/tidy-build/libbitcoin-tidy.so /ci_container_base/ci/scratch/build/bitcoin-x86_64-pc-linux-gnu/src/net_processing.cpp
./prevector.h:151:9: error: unknown pragma ignored [clang-diagnostic-unknown-pragmas]
151 | #pragma pack(push, 1)
| ^

📝 Sjors opened a pull request: "signet: fixing mining for OP_TRUE challenge"
(https://github.com/bitcoin/bitcoin/pull/29032)
[BIP325](https://github.com/bitcoin/bips/blob/master/bip-0325.mediawiki) mentions the following rule:

> In the special case where an empty solution is valid (ie scriptSig and scriptWitness are both empty) this additional commitment can optionally be left out. This special case is to allow non-signet-aware block generation code to be used to test a custom signet chain where the challenge is trivially true.

Such a signet can be created using e.g. `-signetchallenge=51` (`OP_TRUE`). However `c
...

💬 furszy commented on pull request "wallet: birth time update during tx scanning":
(https://github.com/bitcoin/bitcoin/pull/28920#issuecomment-1847314631)
Updated per feedback, [small diff](https://github.com/bitcoin/bitcoin/compare/a41393d3297934ee16bf0ca807206bc590624ce0..1ce45baed7dd2da3f1cb85c9c25110e5537451ae). Thanks. Ready to go.
Renamed `NO_KEY_TIME` to `UNKNOWN_TIME` and made it accessible for other modules.

💬 Sjors commented on pull request "signet: fixing mining for OP_TRUE challenge":
(https://github.com/bitcoin/bitcoin/pull/29032#issuecomment-1847317278)
My own goal with this is to test Stratum v2 stuff, e.g. #28983. It's nice to have a test network _with_ difficulty adjustment. Regular testnet difficulty is too high for my humble S9 (let alone a CPU miner) to win blocks.

Using real mining equipment as opposed to a CPU miner is useful, because of the many quirks real devices have (e.g. version bit grinding). Afaik there's no good emulator.

cc @ajtowns, @kallewoof

💬 maflcko commented on pull request "rpc: add 'getnetmsgstats' RPC":
(https://github.com/bitcoin/bitcoin/pull/28926#discussion_r1420642801)
C++20 is available to use now

💬 TheCharlatan commented on pull request "build: Require C++20 compiler":
(https://github.com/bitcoin/bitcoin/pull/28349#issuecomment-1847367777)
Post-merge ACK.

💬 maflcko commented on pull request "build: no-longer disable WARN_CXXFLAGS when CXXFLAGS is set":
(https://github.com/bitcoin/bitcoin/pull/25972#issuecomment-1847401098)
This one's fixed in clang-14:

```
libtool: link: /usr/bin/ccache clang++-13 -stdlib=libc++ -std=c++20 -fdebug-prefix-map=/ci_container_base/ci/scratch/build/bitcoin-x86_64-pc-linux-gnu=. -Wstack-protector -fstack-protector-all -fcf-protection=full -fstack-clash-protection -Wall -Wextra -Wgnu -Wformat -Wformat-security -Wvla -Wshadow-field -Wthread-safety -Wloop-analysis -Wredundant-decls -Wunused-member-function -Wdate-time -Wconditional-uninitialized -Woverloaded-virtual -Wsuggest-override
...

💬 maflcko commented on pull request "build: Enable -Wunreachable-code":
(https://github.com/bitcoin/bitcoin/pull/28999#issuecomment-1847411927)
> > They seem harmless, so if the author wants them and reviewers are fine with them, it seems fine?
>
> Similar rationale as in your OP -- it seems confusing to have unreachable code. Happy re-review if you agree otherwise NBD.

Ok, but that'd require touching leveldb, which is a subtree, so I can't touch it here.

💬 maflcko commented on pull request "wallet: batch all individual spkms setup db writes in a single db txn":
(https://github.com/bitcoin/bitcoin/pull/28894#discussion_r1420689322)
> Also, probably for another working path, wouldn't be bad to introduce a way to clean up stuff within the benchmark execution that is deliberately not included in the bench results.

Sgtm, but if the cleanup only takes a very short time, I think it is fine to just leave as-is.

⚠️ Wolfstorm321 opened an issue: "Software wont launch"
(https://github.com/bitcoin/bitcoin/issues/29033)
### Is there an existing issue for this?

- [X] I have searched the existing issues

### Current behaviour

Version 0.23.0.0
I ran a full node between 2015 and 2020, pruned since 2020.
I decided to run a full node recently, as I want to import keys to a new wallet.
However, the program wont open while running a full node.

Started synching yesterday at morning, it synched up to 2018.
Closed the program, turned off the computer, went to sleep.
Waked up today, turned on the computer, o
...