Bitcoin Core Github
44 subscribers
121K links
Download Telegram
💬 instagibbs commented on pull request "policy: ephemeral dust followups":
(https://github.com/bitcoin/bitcoin/pull/31279#discussion_r1842272710)
we do in the following lines
👍 TheCharlatan approved a pull request: "guix: remove `util-linux`"
(https://github.com/bitcoin/bitcoin/pull/31285#pullrequestreview-2436171166)
ACK 4d668549825cc2f999b349e8fcd8cc9434c409c3

Guix build:
```
b681575760a0d19445a17d0d54f50a65d705923caee3a7cd7502e6611950dc11 guix-build-4d668549825c/output/aarch64-linux-gnu/SHA256SUMS.part
7af1420fedd8b4d10df650e92840287106dd74c289b6ef6fd2fd039387824647 guix-build-4d668549825c/output/aarch64-linux-gnu/bitcoin-4d668549825c-aarch64-linux-gnu-debug.tar.gz
bd6520732b5c7805002a3227fe2d16f56a77453d913f5204e5be869aaf4a9534 guix-build-4d668549825c/output/aarch64-linux-gnu/bitcoin-4d668549825
...
💬 instagibbs commented on pull request "policy: ephemeral dust followups":
(https://github.com/bitcoin/bitcoin/pull/31279#discussion_r1842274954)
It's a sentence fragment, I can touch it up to be grammatically correct
🤔 l0rinc requested changes to a pull request: "validation: do not wipe utxo cache for stats/scans/snapshots"
(https://github.com/bitcoin/bitcoin/pull/30610#pullrequestreview-2435751891)
> It should not affect performance of the RPCs

It seems I have misunderstood multiple times what to benchmark here (IBD, reindex, RPC), so if there's anything that actually needs benchmarking, please describe it in more detail.
💬 l0rinc commented on pull request "validation: do not wipe utxo cache for stats/scans/snapshots":
(https://github.com/bitcoin/bitcoin/pull/30610#discussion_r1842018386)
It seems to me this complex condition contains a repeated hidden sub-expression that's needed later as `empty_cache`.
Could we split this up to reduce duplication and simplify the expressions?
```C++
bool should_empty_cache = (mode == FlushStateMode::FORCE_FLUSH) || fCacheLarge || fCacheCritical;
bool fDoFullFlush = should_empty_cache || (mode == FlushStateMode::FORCE_SYNC) || fPeriodicFlush || fFlushForPrune;
...
// Flush the chainstate (which may refer to block index entries).
if (shoul
...
💬 l0rinc commented on pull request "validation: do not wipe utxo cache for stats/scans/snapshots":
(https://github.com/bitcoin/bitcoin/pull/30610#discussion_r1842024022)
We should likely update the related script and docs as well:
* https://github.com/bitcoin/bitcoin/blob/master/contrib/tracing/log_utxocache_flush.py#L48
* https://github.com/bitcoin/bitcoin/blob/master/doc/tracing.md?plain=1#L130
* https://github.com/bitcoin/bitcoin/blob/master/contrib/tracing/README.md?plain=1#L251-L252

<details>
<summary>Patch</summary>

```diff
diff --git a/doc/tracing.md b/doc/tracing.md
--- a/doc/tracing.md (revision 1ede4803f1f5dffa55644d908062b52bf71394e7)
+++
...
💬 l0rinc commented on pull request "validation: do not wipe utxo cache for stats/scans/snapshots":
(https://github.com/bitcoin/bitcoin/pull/30610#discussion_r1842044510)
Same question here, is `Unconditionally` still the case here, given that `ForceFlushStateToDisk(false)` does a sync instead?
💬 l0rinc commented on pull request "validation: do not wipe utxo cache for stats/scans/snapshots":
(https://github.com/bitcoin/bitcoin/pull/30610#discussion_r1842041631)
Given that `ForceFlushStateToDisk(false)` does a `FORCE_SYNC` now, does the method name still reflect its role?
💬 l0rinc commented on pull request "validation: do not wipe utxo cache for stats/scans/snapshots":
(https://github.com/bitcoin/bitcoin/pull/30610#discussion_r1842149539)
Updating to `UTXOS_IN_CACHE = 3` and `expected_flushes.append({"mode": "NONE", "for_prune": True, "size": BLOCKS_TO_MINE})` makes these test pass again.

<details>
<summary>patch</summary>

```diff
diff --git a/test/functional/interface_usdt_utxocache.py b/test/functional/interface_usdt_utxocache.py
--- a/test/functional/interface_usdt_utxocache.py (revision eb1257260b2f4ede605241f1fb514452d63305c8)
+++ b/test/functional/interface_usdt_utxocache.py (date 1731587669301)
@@ -365,7 +365,7
...
💬 l0rinc commented on pull request "refactor: Avoid std::string format strings":
(https://github.com/bitcoin/bitcoin/pull/31287#issuecomment-2476574861)
ACK fa1177e3d7ca9ef003ded4d0c915fa6dc22bd37d
💬 instagibbs commented on pull request "fuzz: Fix difficulty target generation in `p2p_headers_presync`":
(https://github.com/bitcoin/bitcoin/pull/31213#discussion_r1842371606)
maybe leave a note that in presync we're allowed to have arbitrary nBits adjustments, within the clamped values?
💬 l0rinc commented on pull request "refactor: Check translatable format strings at compile-time":
(https://github.com/bitcoin/bitcoin/pull/31061#issuecomment-2476602210)
Concept ACK, nice to see these verifications being done earlier
💬 instagibbs commented on pull request "fuzz: Fix difficulty target generation in `p2p_headers_presync`":
(https://github.com/bitcoin/bitcoin/pull/31213#issuecomment-2476608139)
ACK https://github.com/bitcoin/bitcoin/pull/31213/commits/a6ca8f324396522e9748c9a7bbefb3bf1c74a436

seems strictly better than as-is
⚠️ dooglus opened an issue: "bitcoin-qt failed assertion on startup"
(https://github.com/bitcoin/bitcoin/issues/31289)
### Is there an existing issue for this?

- [X] I have searched the existing issues

### Current behaviour

I ran bitcoin-qt the same way I always do, but it failed to start up. The terminal shows this:

```
[New Thread 0x7fff337fe6c0 (LWP 4274)]
[New Thread 0x7fff32ffd6c0 (LWP 4275)]
[New Thread 0x7fff327fc6c0 (LWP 4276)]
[New Thread 0x7fff31ffb6c0 (LWP 4277)]
[New Thread 0x7fff317fa6c0 (LWP 4278)]
[New Thread 0x7fff30ff96c0 (LWP 4279)]
[New Thread 0x7fff23fff6c0 (LWP 4280)]
[New Thre
...
💬 fanquake commented on issue "guix: Linux and macOS builds are not cross-arch reproducible with powerpc64le build arch":
(https://github.com/bitcoin/bitcoin/issues/31207#issuecomment-2476690702)
Last I was looking at this, if you guix built (master) for `powerpc64le-linux-gnu`, once on `x86_64` and once on `aarch64`, and compared the resulting binaries, you'd end up with (a small number) of differences where two instructions are swapped. For example:
```diff
--- a/x86_64.txt
+++ b/aarch64.txt
@@ -176,8 +176,8 @@
24ea8: 78 1b 77 7c mr r23,r3
24eac: 66 01 17 7c mtfprd f0,r23
24eb0: 14 f2 37 7d add r9,r23,r30
- 24eb4: d0 00 b8
...
📝 lulapainho opened a pull request: "feati: mais moeda"
(https://github.com/bitcoin/bitcoin/pull/31290)
companheiros e companheiras, boa tarde

quero imprimir mais dinheiro
fanquake closed a pull request: "feati: mais moeda"
(https://github.com/bitcoin/bitcoin/pull/31290)
📝 fanquake locked a pull request: "feati: mais moeda"
(https://github.com/bitcoin/bitcoin/pull/31290)
companheiros e companheiras, boa tarde

quero imprimir mais dinheiro
💬 Sjors commented on pull request "Add multiprocess binaries to release build":
(https://github.com/bitcoin/bitcoin/pull/30975#issuecomment-2476779538)
I pulled in the changes from https://github.com/Sjors/bitcoin/pull/65 to enable multiprocess for non-depends builds. But I disabled it for various jobs, see TODO in PR description.
💬 andrewtoth commented on pull request "validation: do not wipe utxo cache for stats/scans/snapshots":
(https://github.com/bitcoin/bitcoin/pull/30610#issuecomment-2476798087)
@l0rinc a way to test that this PR is working properly is to first run master and sync a few blocks. In the `UpdateTip` logs you will see a `cache=` value that increases. Running either of these RPCs should make the next `UpdateTip` reset a few MB at most.
When doing the same test on this branch, the next `UpdateTip` value should be the same or higher than the previous.