[29.x] Backports #35234

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

   Backports:

   • #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. A summary of reviews will appear here.

   <!--5faf32d7da4f0f540f40219e4f7537a3-->

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. depends: Unset `SOURCE_DATE_EPOCH` in `gen_id` script 1cc4fce50f
10. 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>

    8ed54b0594
11. fanquake force-pushed on May 28, 2026
12. fanquake force-pushed on May 29, 2026
13. fanquake force-pushed on May 29, 2026
14. fanquake marked this as ready for review on May 29, 2026
15. fanquake force-pushed on May 29, 2026
16. ci: switch runners from cirrus to warpbuild

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

    4f1c0ae3ec
17. doc: remove reference to cirrus

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

    e5f16c6e78
18. 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

    ea1bb13f2a
19. doc: update release notes for v29.x 3031ebc34b
20. fanquake force-pushed on May 29, 2026

Milestone
29.4