Bitcoin Core Github
44 subscribers
119K links
Download Telegram
πŸ€” glozow reviewed a pull request: "p2p: Increase tx relay rate"
(https://github.com/bitcoin/bitcoin/pull/28592#pullrequestreview-3245717908)
utACK b81f37031c8f2ccad9346f1b65ee0f8083c44796
πŸ’¬ glozow commented on pull request "rpc: Always return per-wtxid entries in submitpackage tx-results":
(https://github.com/bitcoin/bitcoin/pull/33427#discussion_r2363502186)
is optional now false?
πŸ’¬ hebasto commented on issue "v30rc1 Weird GUI windowing behavior":
(https://github.com/bitcoin/bitcoin/issues/33432#issuecomment-3312837619)
Thanks, @benthecarman!

From the provided logs, it appears that the reported bug occurs when building with the system’s Qt 6.4.2, rather than with the statically linked release binary.

The requirement to install `libxcb-cursor0` is already a known issue and is being tracked elsewhere.
πŸ’¬ PiRK commented on pull request "test: Fix TestFlushBehavior when coin has non-zero dynamic memory usage":
(https://github.com/bitcoin/bitcoin/pull/33381#issuecomment-3312853835)
let's see if this works. I moved the problematic test line to its own test suite, where it does not affect other flush tests.

The failure I'm trying to solve seems intermittent. It happens about 75% of the time on master if I just add the scriptPubKey to MakeCoin.
After my commit I get no failure in 10 runs of `./build/bin/test_bitcoin --run_test=coins_tests`
πŸ’¬ PiRK commented on pull request "test: Fix TestFlushBehavior when coin has non-zero dynamic memory usage":
(https://github.com/bitcoin/bitcoin/pull/33381#issuecomment-3312873728)
To clarify the rationale for this PR: the `SanityCheck` test added to `flush_all` in https://github.com/bitcoin/bitcoin/pull/28280/commits/a14edada8a051e280af6fedd5130be40247e2d7a does not have full coverage if `cachedCoinsUsage` is not exercised.

This PR ensure that the `cachedCoinsUsage` part of `SanityCheck` now actually does something useful for the `TestFlushBehavior` suite.
πŸ’¬ john-moffett commented on pull request "rpc: Always return per-wtxid entries in submitpackage tx-results":
(https://github.com/bitcoin/bitcoin/pull/33427#discussion_r2363560078)
I'd think it stays optional, as successful (and partially successful) submissions won't have an error for every tx. See, eg, [this test](https://github.com/bitcoin/bitcoin/blob/edb871cba22a658714ce97e843ff84cfe1ba9ac4/test/functional/rpc_packages.py#L417), where only the child has an error.
πŸ’¬ fanquake commented on pull request "ci: run s390x job":
(https://github.com/bitcoin/bitcoin/pull/33436#issuecomment-3312901010)
Thanks @willcl-ark. Pulled in (some version) of your change, and added a `NO_QT=1` for now.
πŸ’¬ glozow commented on pull request "rpc: Always return per-wtxid entries in submitpackage tx-results":
(https://github.com/bitcoin/bitcoin/pull/33427#discussion_r2363629883)
Oh I did not read that carefully 🀦 yes.
πŸš€ fanquake merged a pull request: "p2p: Increase tx relay rate"
(https://github.com/bitcoin/bitcoin/pull/28592)
πŸ’¬ fanquake commented on pull request "p2p: Increase tx relay rate":
(https://github.com/bitcoin/bitcoin/pull/28592#issuecomment-3312961173)
Backported to `v30.x` in #33424.
πŸ’¬ fanquake commented on pull request "ci: run s390x job":
(https://github.com/bitcoin/bitcoin/pull/33436#issuecomment-3312993728)
Looks like this passed in `98m` (without Qt and nothing cached).
πŸ€” enirox001 reviewed a pull request: "fuzz: reduce iterations in slow targets"
(https://github.com/bitcoin/bitcoin/pull/33429#pullrequestreview-3246274219)
Concept ACK 6a33970

While working on #32870, I considered reducing iterations to speed up fuzzing, but wasn’t sure it was feasible since that wasn’t the issue’s intended goal. However, I noticed that reducing iterations did speed up the MiniMiner fuzz test.

This seems like a good approach to solving the issue, pending the reimplementation of MiniMiner.
πŸ‘ brunoerg approved a pull request: "fuzz: reduce iterations in slow targets"
(https://github.com/bitcoin/bitcoin/pull/33429#pullrequestreview-3246433430)
ACK 6a33970fef1b7b4d634f28277607b882958c95ac

I verified the perfomance gain. e.g. mini_miner target is now 10x faster on my machine.

mini miner (master):
```
#256 pulse cov: 4182 ft: 24483 corp: 253/57Kb exec/s: 128 rss: 278Mb
#512 pulse cov: 4234 ft: 27611 corp: 501/1139Kb exec/s: 8 rss: 761Mb
#602 INITED cov: 4235 ft: 28000 corp: 576/4293Kb exec/s: 5 rss: 797Mb
#602 DONE cov: 4235 ft: 28000 corp: 576/4293Kb lim: 489495 exec/s: 5 rss: 797Mb
Done 602 runs in 113 second(s)
```

...
πŸ’¬ l0rinc commented on pull request "system: silence unused variable warning and make GetTotalRAM() work on FreeBSD":
(https://github.com/bitcoin/bitcoin/pull/33435#issuecomment-3313378297)
Thanks @hebasto for finding it, thanks @vasild for the quick PR.

I'm working on trying to reproduce this on the mentioned platforms, but there's a reason I didn't add them originally since I couldn't test them via godbolt (https://xania.org/202506/how-compiler-explorer-works indicates they don't have native BSD or s390x servers).

@vasild if you edit again, can you please add @hebasto as a coauthor for the change?

Concept ACK for both changes in the PR (the maybe unused + adding BSD), I'
...
πŸ’¬ Crypt-iQ commented on pull request "fuzz: reduce iterations in slow targets":
(https://github.com/bitcoin/bitcoin/pull/33429#issuecomment-3313486792)
crACK 6a33970fef1b7b4d634f28277607b882958c95ac
πŸ€” furszy reviewed a pull request: "fuzz: reduce iterations in slow targets"
(https://github.com/bitcoin/bitcoin/pull/33429#pullrequestreview-3246723125)
A few extra optimizations (plus a bug fix) to the mini miner target: [https://github.com/furszy/bitcoin-core/tree/2025\_fuzz\_improve\_mini\_miner](https://github.com/furszy/bitcoin-core/tree/2025_fuzz_improve_mini_miner). They don’t seem to add much gain per @brunoerg’s feedback, but might help on the long run. Feel free to take them.
πŸ€” mzumsande reviewed a pull request: "net: Provide block templates to peers on request"
(https://github.com/bitcoin/bitcoin/pull/33191#pullrequestreview-3242205039)
Would be helpful to link the BIP PR/Delving Post in the OP.

I looked through the code, but will leave any low-level comments for later.

On a conceptual level, this seems like a strong fingerprinting vector (tor/clearnet response would be identical if requests happen roughly at the same time and the same template is used).
I'm not sure if we have given up on that, considering that there seems to be no lack of other existing fingerprinting methods.
πŸ’¬ mzumsande commented on pull request "net: Provide block templates to peers on request":
(https://github.com/bitcoin/bitcoin/pull/33191#discussion_r2364203706)
Any reason to do this here instead of using the scheduler like, for example, `ReattemptInitialBroadcast` does?
πŸ’¬ ryanofsky commented on pull request "mining: add applySolution() to interface":
(https://github.com/bitcoin/bitcoin/pull/33374#issuecomment-3313660257)
Have a few questions and comments:

1. Main question is why is this new applySolution method needed at all if submitSolution() modifies the block and there is already a getBlock() method?
2. I think it would be good if submitSolution documented fact that calling it changes getBlockHeader, getBlock, getCoinbaseTx values.
3. New comments say that coinbase witness is not added automatically, but it's not really clear what happens if client doesn't add it. Block is rejected or invalid? Behavior
...