[29.x] Backports #35234

1. 
   fanquake commented at 9:46 AM on May 7, 2026: member

   Backports:

   • #34228
   • #35228
   • #35283
   • #35313 (only https://github.com/bitcoin-core/leveldb-subtree/pull/61)
   • #35378
   • #35408
2. fanquake added this to the milestone 29.4 on May 7, 2026
3. DrahtBot added the label Backport on May 7, 2026
4. 
   DrahtBot commented at 9:46 AM on May 7, 2026: contributor

   <!--e57a25ab6845829454e8d69fc972939a-->

   The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

   <!--006a51241073e994b41acfe9ec718e94-->

   Code Coverage & Benchmarks

   For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/35234.

   <!--021abf342d371248e50ceaed478a90ca-->

   Reviews

   See the guideline for information on the review process.

   Type	Reviewers
   ACK	andrewtoth, marcofleon

   If your review is incorrectly listed, please copy-paste <code>&lt;!--meta-tag:bot-skip--&gt;</code> into the comment that the bot should ignore.

   <!--5faf32d7da4f0f540f40219e4f7537a3-->

   LLM Linter (✨ experimental)

   Possible places where named args for integral literals may be used (e.g. func(x, /*named_arg=*/0) in C++, and func(x, named_arg=0) in Python):

   • MaxInputWeight(*desc, CTxIn{outpoint}, coin_control, true, can_grind_r) in src/wallet/spend.cpp

   ^{2026-06-02 15:06:57}

5. doc: mention -DWITH_ZMQ=ON in BSD build guides

   The FreeBSD, NetBSD, and OpenBSD build guides state that ZMQ support is compiled in when the package is installed. Since WITH_ZMQ defaults to OFF, update the wording to mention the required CMake option.
   
   Github-Pull: #35283
   Rebased-From: ca93ab808c488324990eb91ed8297a37dd10d580

   4e3dd136b8
6. fanquake force-pushed on May 14, 2026
7. wallet: use outpoint when estimating input size

   `CalculateMaximumSignedInputSize()` is passed the outpoint being sized, but that context was not used when estimating the signed input size.
   Pass the outpoint through so externally selected inputs are not underestimated.
   
   Co-authored-by: Antoine Poinsot <darosior@protonmail.com>
   
   Github-Pull: #35228
   Rebased-From: cd8d3bd937b5515ea000408eb07d2ae3cd1aa417

   005738e3b8
8. fanquake force-pushed on May 20, 2026
9. fanquake force-pushed on May 28, 2026
10. fanquake force-pushed on May 29, 2026
11. fanquake force-pushed on May 29, 2026
12. fanquake marked this as ready for review on May 29, 2026
13. fanquake force-pushed on May 29, 2026
14. fanquake force-pushed on May 29, 2026
15. 
    andrewtoth commented at 2:25 AM on June 2, 2026: contributor

    #34228 was backported here, but not mentioned in description or in that PR's comments. Likely an oversight?

    Commit trailers for #34228 and for https://github.com/bitcoin-core/leveldb-subtree/pull/61 are missing.

    Lint fails due to not updating the leveldb subtree. I guess that's ok?

    Also this comment in the 30.x backport PR applies here as well I believe #35232 (review).

16. depends: Unset `SOURCE_DATE_EPOCH` in `gen_id` script

    Github-Pull: #34228
    Rebased-From: 9f7a2293c48f8afb5e87765a327a0c89fd21fa56

    e5613db113
17. Disable seek compaction

    Seek compaction is causing a cascade effect in the chainstate DB, causing large parts of the database to be rewritten every ~hour.
    
    Every periodic flush writes around 2 MiB. Since this is roughly the `write_buffer_size`, these writes regularly cause the memtable to rotate into a small L0 file. This file has a small seek budget, and with the random UTXO reads done during validation, it can get scheduled for seek compaction quickly.
    
    That seek compaction pushes the small file down to L1. Since most UTXOs are already lower down in L4/L5, many reads that consult this file do not find the key there and continue downward. The bloom filter makes those misses cheap, but LevelDB still decrements the file's seek budget. The file then gets scheduled for another seek compaction, and the same pattern pushes it down through L2 and L3.
    
    The expensive part happens around L3/L4. L4 has many ~32 MiB files holding the bulk of the UTXO set. When LevelDB compacts into L3, it may split the output into many smaller L3 files to limit how much L4 "grandparent" data any one output overlaps. Each of these small L3 files then gets its own small seek budget. Because chainstate keys are hash-random, each small L3 file can still have a broad key range, so many random reads consult it and quickly drain its budget. Once seek-compacted into L4, each tiny L3 file can overlap many L4 files, so compacting a few hundred KiB from L3 can require rewriting hundreds of MiB from L4. Repeating that across many small L3 files can rewrite most of the chainstate.
    
    This is a poor fit for chainstate because UTXO keys are hash-random, the DB is large enough to have many levels, writes are relatively small and periodic, and reads are frequent. The result is that read misses trigger compactions much earlier than size pressure would, and those compactions have very high write amplification.
    
    Disabling seek compaction may leave more files in upper levels for longer, so reads could theoretically consult more files. But Bitcoin Core enables bloom filters for all its LevelDB instances, so these misses are usually cheap in-memory filter checks rather than disk reads.
    
    For the other DBs, the risk is much smaller. They also use bloom filters, and most are smaller and less read-heavy. With fewer levels and less random read pressure, disabling seek compaction should have little effect there.
    
    Co-authored-by: l0rinc <pap.lorinc@gmail.com>
    
    Github-Pull: #35313
    Rebased-From: 6bfdb6093bba4710d0f8313ed0113967a8b5176f

    b631f27246
18. ci: switch runners from cirrus to warpbuild

    Github-Pull: #35378
    Rebased-From: 4bdd46ace37f02da062a53a2943caeddca4ed8f9

    1907ee01fe
19. doc: remove reference to cirrus

    Github-Pull: #35408
    Rebased-From: 265563bf75c0b8b615e28d47398098020ff0b109

    33dd5e74d8
20. ci: use ubuntu-latest instead of ubuntu-24.04

    To match the usage of -latest for the warp runners.
    
    Github-Pull: #35408
    Rebased-From: 5700a61b73342b506b0114b342499da7642c1c10

    9d62f5d0be
21. fanquake force-pushed on Jun 2, 2026
22. 
    fanquake commented at 8:25 AM on June 2, 2026: member

    @andrewtoth thanks, should all be addressed.

23. doc: update release notes for v29.x d8da418220
24. fanquake force-pushed on Jun 2, 2026
25. andrewtoth approved
26. 
    andrewtoth commented at 3:17 PM on June 2, 2026: contributor

    ACK d8da418220f4d4bdbb7c7691b78a093716266c2c

27. marcofleon approved
28. 
    marcofleon commented at 4:49 PM on June 2, 2026: contributor

    ACK d8da418220f4d4bdbb7c7691b78a093716266c2c

29. fanquake merged this on Jun 3, 2026
30. fanquake closed this on Jun 3, 2026

    ---

31. fanquake deleted the branch on Jun 3, 2026

Milestone
29.4