Implement notifyreceived and notifyspent at confirmed-only fidelity - #935
Merged
Merged
Conversation
Reuses loadtxfilter's cursor-based address/outpoint history matching. notifyreceived's address watch is permanent (like loadtxfilter's); each match auto-arms a one-shot spent-watch (also reachable via an explicit notifyspent), fired once and removed, kept in separate maps (receive_watches_/spent_watches_) so the one-shot lifecycle can't corrupt loadtxfilter's permanent semantics for a client using both. recvtx/redeemingtx fire individually ([txHex, blockDetails], real btcd's wire shape), independent of the notifyblocks subscription -- unlike blockconnected/filteredblockconnected. This required extending handle_chase's post-do_connected gate (previously subscribed_blocks_ only) with a second flag, watching_legacy_, since a client using only notifyreceived never subscribes to notifyblocks. No mempool in v4, so notifynewtransactions remains unimplemented; the matched output's vout for auto-arming is found by walking the already serialized transaction's own outputs by script hash, no new query needed.
Replaces the four not_implemented regression tests with real coverage: input validation, register/unregister acks, a recvtx delivery test (notifyreceived without notifyblocks, proving the two subscriptions are independent), and a redeemingtx delivery test against mock_block10's known spend of block1's coinbase. Updates btcd_methods::names and the served/unserved static_asserts in test/interfaces/btcd.cpp now that these four methods are no longer tagged unimplemented.
Removes the DEPRECATED_STUBS blanket "always not_implemented" table and its regression test, now that these methods are real. Adds ack/reject tests for notifyreceived/stopnotifyreceived/notifyspent/stopnotifyspent mirroring the existing loadtxfilter test pattern. No live recvtx/ redeemingtx delivery test here -- would need real mainnet funds arriving on cue; the C++ mock-store tests already cover the wire behavior deterministically.
Member
These are deprecated by btcd, but if they are still in use we can keep them. Unfortunately neither btcd nor bitcoind which it sits on are versioned. Also btcd's implementation of bitcoind is ancient and includes drift, so there could be more issues for applications that reply on those breaks. |
johnconstant99-dev
approved these changes
Sep 14, 2026
Member
Please explain or be blocked for spam. |
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.
Summary
btcd's legacy
notifyreceived/notifyspent/stopnotifyreceived/stopnotifyspentwere previously stubbednot_implemented. lnd's btcwallet dependency calls these directly against a btcd backend —NewAddress/NewChangeAddressfor receive-address watching, and the ChainNotifier'sRegisterSpendNtfnfor channel breach/force-close detection — so without them,lncli newaddresshard-fails and channel spend detection can't arm.Implemented at confirmed-only fidelity (no mempool in v4), reusing loadtxfilter's cursor-based address/outpoint history matching wholesale. notifyreceived's address watch is permanent, like loadtxfilter's; each match auto-arms a one-shot spent-watch (also reachable via an explicit notifyspent) that fires once and is removed, per real btcd's own behavior. Kept in separate maps from loadtxfilter's permanent ones so the one-shot lifecycle can't corrupt loadtxfilter semantics for a client using both.
Test plan
recvtx(withoutnotifyblocks) andredeemingtxlncli newaddress(p2wkh/np2wkh/p2tr) now succeeds instead of-1: misc_error