chore: rebuild native libs with the electrum block.headers fix - #143
Merged
Conversation
Rebuilds both ABIs against floresta-mandacaru-ffi f9e21ce, which pins Floresta-mandacaru 111f9e33. That commit makes the Electrum `blockchain.block.headers` response report a `count` equal to the number of headers actually serialized into `hex`, so wallets no longer reject the chunk as corrupted and reconnect in a loop. Kotlin bindings are unchanged — the fix touches no FFI surface. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #136.
Rebuilds
libflorestad_ffi.sofor both ABIs against floresta-mandacaru-ffif9e21ce, which pins Floresta-mandacaru111f9e33.What the fix does
The Electrum
blockchain.block.headershandler advertised acounttaken from the requested range length, but builthexwith afilter_mapthat silently dropped any height it failed to look up. Electrum clients assertlen(hex) / 160 == count, so one dropped height made the client raiseRequestCorrupted('inconsistent chunk hex and count'), disconnect and reconnect — the wallet flipped between "Connected" and "Not connected" and never reached tip, withNew client connection/Client closed connectionscrolling in the node log.The handler now derives
countfrom the headers it actually serialized and stops at the first height it can't serve, keeping the chunk contiguous fromstart_height.References
111f9e33)f9e21ce)getfloresta/Florestamaster, so upstream carries the bug tooChanges
Two
.sofiles only. The Kotlin bindings (florestad.kt) are byte-identical — the fix touches no FFI surface. arm64-v8a keeps its 16 KB page alignment (LOAD Align 0x4000); x86_64 stays at 4 KB, and both still link Bioniclibc/libm/libdldynamically.Testing
These exact binaries were installed on an x86_64 emulator (clean install, node synced from genesis) and driven against the live on-device Electrum server on port 50001:
len(hex) / 160 == count: a full 2016-header chunk from genesis, a chunk crossing the tip, a chunk starting at the tip, and a range starting past the tip.blockchain.block.headersrequests while the chain advanced from height 118k to 196k — the moving-tip condition the bug reproduces under — with zerocount/hexmismatches.The same checks were also run before the merge against a path-dep build of the identical Floresta commit (2874 requests, tip ~416k → ~488k, zero mismatches).
Unit coverage came with the fork PR:
test_headers_chunk_is_consistent_with_countinfloresta-electrum.