l0rinc

#!/usr/bin/env python3
"""Time large mempool-only gettxspendingprevout requests."""

from statistics import median
from time import perf_counter

from test_framework.test_framework import BitcoinTestFramework
from test_framework.util import assert_equal

l0rinc

#!/usr/bin/env python3
"""Send an empty headers response and wait for a replacement request."""

import sys

sys.path.insert(0, "test/functional")

from test_framework.messages import msg_headers
from test_framework.p2p import NetworkThread, P2PInterface
from test_framework.util import wait_until_helper_internal

l0rinc

commit c978cc44712cc3637d961981a5c9f8932c9d42a6
Author: Lőrinc <pap.lorinc@gmail.com>
Date:   Thu Apr 30 13:47:56 2026 +0200

    temp: log CCoinsMap bucket distribution
    
    Log CCoinsMap bucket counts before cache flush and sync operations.
    
    This temporary measurement commit records size, bucket count, load factor, maximum bucket size, and bucket-size histogram bins for comparing outpoint hashers during reindex-chainstate.

l0rinc

Script-execution cache poisoning via activation-boundary reorg

Disclaimer

It's no secret that I'm strongly opposed to this consensus change (trying to punish everyone just to send a signal to those we disagree with doesn't resonate with me).

But regardless of my views on it, I think it's important to disclose a serious consensus-critical bug in the current BIP-110 implementation, since it could harm users who choose to run this software even more.

Context

The new restrictions here don't apply to UTXOs created before the activation height. This is tracked via per-input flags that relax the mandatory verify flags for old UTXOs.

l0rinc

Pi 5, 4 GB, pruned node:
• Raspberry Pi 5 (4 GB RAM) - $66 - https://amazon.com/Raspberry-Pi-4GB-2023-Processor/dp/B0CK3L9WD3
• 128 GB NVMe SSD - $20 - https://www.amazon.com/Silicon-Power-128GB-P34A60-SP128GBP34A60M28/dp/B09HMWH1DG
• M.2 HAT for SSD - $8 - https://amazon.com/ZDE-ZP517A-Peripheral-Raspberry-Compatible/dp/B0D1QYDJJJ
• Aluminum heatsink - $4 - https://amazon.com/Raspberry-Aluminum-Heatsink-Cooling-Dissipation/dp/B0DY83ZZ31
• 5.1 V/5 A power supply - $13 - https://www.amazon.com/RasTech-Power-Supply-Raspberry-Adapter/dp/B0CLV6WB4L
Total: $111

----

l0rinc

diff --git a/src/script/script.cpp b/src/script/script.cpp
--- a/src/script/script.cpp	(revision 6ddb22a8c89a40ec0d4d75a195c2bc0231933285)
+++ b/src/script/script.cpp	(revision b34e14355d94b21064cc64977955bf696e09992e)
@@ -4,7 +4,8 @@
 // file COPYING or http://www.opensource.org/licenses/mit-license.php.
 
 #include <script/script.h>
-
+#include <script/solver.h>
+#include <logging.h>

l0rinc

Benchmarking meeting notes

Add a macro benchmark suite with longer-running operations, exercising a different set of functionality that is performance-critical.

• One of them could be the speed of an assumeUTXO load-and-dump (this would check block read/write and (de)serialization, but only part of validation).
• Another one could be an actual IBD for 840-880k blocks (small part of IBD, but should produce a representative comparison quickly).
• Another one would be a reindex-chainstate up to e.g. 880k blocks (more realistic, but takes long and doesn't involve reading/writing blocks).
• Lastly, several full IBDs to make sure the previous quick checks are representative (likely only required for big changes). We don't have to run all of these for every PR; it could be tied to labels added to PRs where the author/reviewers think they're relevant (e.g., not for doc typo fixes). This would require integration with CoreCheck.

Other suggested macro benchmarks by the participants:

• Compact block reconstruction

l0rinc

#!/bin/bash

# Set up the working directory and output folder
DATADIR="/mnt/bitcoin-data"
OUTPUT_DIR="$DATADIR/stale_blocks"
LOG_FILE="$OUTPUT_DIR/stale_blocks.csv"

mkdir -p "$OUTPUT_DIR"
while read -r bhash; do
    # Fetch block information (height and hash) and skip if unavailable

l0rinc

This guide helps you compare the performance of two different versions of Bitcoin Core during the initial block download (IBD) process. You will run two builds and share the results.

Background and Purpose

I am working on improving the performance of the first phase of Bitcoin Core, specifically the process of downloading and validating the blockchain on a fresh machine. I have proposed several modifications that, based on my own measurements, result in measurable speed improvements. However, to ensure broader acceptance, I need help reproducing these results by having others run similar tests.

This is a technical process (though not overly complex, in my opinion), requiring the source code to be compiled. The goal is to validate these improvements on multiple setups and environments, which will help accelerate their adoption.

Requirements:

l0rinc

Ez az útmutató segít abban, hogy összehasonlítsd a Bitcoin Core két különböző verziójának teljesítményét az első blokklánc-letöltési (IBD) folyamat során. Két buildet fogsz futtatni, és az eredményeket megoszthatod.

Kell hozzá:

• GitHub fiók (az eredmények publikálásához).
• Linux alapú rendszer (például Ubuntu/Debian).
• Legalább 1 TB szabad hely a blokklánc adataihoz (ideiglenes, utána törölhető).

Először telepítsd a szükséges csomagokat (Debian/Ubuntu rendszeren). Csak megbízható forrásból telepíts!