We have found few recent reports of 32-bit Bitcoin Core node use, yet we regularly run into problems with architecture-dependent types such as size_t.
- Reviewers must account for two integer widths even in ordinary size calculations. Cache partitioning, serialized-size validation, and fee-estimator file checks have all needed fixes for 32-bit overflow. Routine descriptor-parsing optimization also prompted another review of Base58 arithmetic for 32-bit overflow.
- 64-bit sanitizer runs do not exercise 32-bit-only overflows, and there is no supported way to run the integer sanitizer on ARM32.
- 32-bit CI has needed system-call workarounds and extra configuration and emulation work, and it restricts the choice of CI providers.
- Limited virtual address space requires separate resource limits, allocator workarounds, and database settings. ARM32 alignment differences have also caused an out-of-memory regression.
- Keeping 32-bit builds working has required Qt compatibility patches and ARM32 reproducible-build workarounds.
Previous discussions focused on shipping 32-bit x86 Linux binaries and ARM32 release binaries. Keeping source support retains the code and testing burden even after binary distribution ends.
Given these recurring costs, I propose requiring a 64-bit target for Bitcoin Core node builds, including builds from source. That would let us retire the 32-bit node CI and release configurations and simplify node code that exists only to accommodate 32-bit targets.
<details> <summary>Further examples of the work created by 32-bit support</summary>
- #33709 and #33724 replaced architecture-dependent serialized-size arithmetic after the published crash mitigation. The review discussion explains the recurring need to reason about intermediate overflow and checked narrowing.
- #35097 changed byte-unit literals because
size_tprevented expressing larger storage sizes and limits on 32-bit targets. - #7848 fixed UTXO hash results that differed between 32-bit and 64-bit builds because a
size_tcounter wrapped. - #24214 made interpreter arithmetic independent of host width and reduced integer-sanitizer suppressions.
- #34110 exposed a 32-bit Base58 overflow during wallet fuzzing and documents the additional effort needed to reproduce it.
- #30307 needed different handling for file-position errors that occurred earlier on 32-bit systems.
- #29415's review revisited architecture-dependent counter types during private-broadcast work. #32497's review compared arithmetic across compilers and 32-bit/64-bit targets for a small allocation optimization.
- #34108 and #34136 required changing a functional test whose memory-accounting assumptions failed on 32-bit builds. #34132's review needed different storage-corruption test setup because the 32-bit database path behaved differently.
- #28531's test discussion describes the difficulty of maintaining memory-usage expectations across both widths. #35773 needed a sanitizer suppression for intentional hash truncation on 32-bit targets.
- #16096 raised declining developer testing and assumptions about
size_t,time_t, andlong. #35466 later repaired ARM32 IPC test coverage that had been skipped because a dependency was missing. - #27879, #31965, and the later hosting discussion show ARM32 execution restricting CI hardware and provider choices. #33302 needed an additional runner/cache exception.
- #35546 revisited an i686 compiler choice originally made to avoid memory exhaustion. #31772 records another 32-bit compiler/build-mode combination causing an IPC test failure.
- #3324 documents longstanding virtual-address-space exhaustion. #28906 and #28913 show ARM32 alignment assumptions causing a later memory regression.
- #33333 needed arithmetic ordering chosen to avoid 32-bit overflow. #34692 retained a separate 32-bit cache default. The unmerged #35620 also illustrates separate database-cache behavior complicating proposed changes.
- #2203, #2236, #438, and #439 needed large-file accommodations for 32-bit builds.
- #29980 and #29985 required dependency changes during the time64 transition. #25573's ARM32 discussion describes extra toolchain and IPC work for static PIE.
- #28096 found a nominally 32-bit build producing a 64-bit executable after losing target flags. #22889 and #22923 prompted additional 32-bit Clang coverage after compilation failures.
- #18686, #19735, and #22464 are smaller examples of warning and narrowing fixes needed specifically for 32-bit targets.
- #15939 and #22908 retired Win32 release and build configurations. #18104 stopped default i686 release builds while explicitly retaining source builds and CI, leaving later cleanup in #19745.
- #23744 removed an i686 Android target that had been broken unnoticed for months. #24448, #24639, and #26075 show the compatibility work and eventual cleanup around discontinued i686 release builds.
</details>
