protocol 1.7: revert adding chaintip to responses#17
Merged
ecdsa merged 1 commit intoJul 1, 2026
Conversation
partially reverts 9c32658 I just realised the implementation in ElectrumX (server) was not including the chaintip in the notifications for "blockchain.outpoint.subscribe". (I missed this previously as the integration tests between Electrum Wallet and ElectrumX were passing: the client saw the missing field, logged an error and disconnected from the server, but then the client reconnected, re-subscribed to the outpoints, and got responses from the server with the chaintip included - as only the notifications were missing the chaintip, the responses were not.) Turns out with ElectrumX's architecture and how it is using bitcoind, it is not simple at all to also include the chaintip in the notifications... "blockchain.outpoint.subscribe" is implemented using bitcoin core's txospenderindex. ElectrumX calls "getrawtransaction" to find the funder tx, and then it calls "gettxspendingprevout" to find the spender tx, and for both responses bitcoind gives the containing blockhash for the tx - but not the chaintip. After that, ElectrumX uses its own mempool to enrich the "blockchain.outpoint.subscribe" response with the mempool state of funder tx and spender tx. So the server needs to make sure bitcoind's chaintip does not move and its own mempool stays consistent during all this. This was doable when serving the initial request: ElectrumX checked the chaintip before doing all the calculations and then checked the chaintip again, and if it changed, it tried again, which was already hackish. In the worst case, the server would fall back to sending a json-rpc-error to the client. but this is not practical at all while sending out notifications... I am assuming that other server implementations would eventually run into a similar issue. Also, note that when serving the history of an spk or the status of an outpoint, if all the txs touching it are somewhat-deeply mined, it is almost of no interest if the chaintip moves. Even a small reorg is not interesting if it does not affect the relevant txs as they are deeper. So, now I think the right approach is that instead of adding the chaintip to responses, we could add the blockhash corresponding to the last relevant tx. - e.g. for spk.get_history, the last tx touching the spk, - or for outpoint.get_status, the spender if it exists, or the funder if that exists, or none - also note that if a server implements this using bitcoind's txospenderindex, "getrawtransaction" and "gettxspendingprevout" already provide the relevant blockhash However, I think this needs more discussion, so the simplest approach is to just revert this for now, and see how to include something along these lines in the next version.
SomberNight
added a commit
to spesmilo/electrum
that referenced
this pull request
Jul 1, 2026
This was motivated by wanting to include the chaintip in responses but that part was reverted and postponed to later. ref spesmilo/electrum-protocol#17
SomberNight
added a commit
to SomberNight/electrumx
that referenced
this pull request
Jul 1, 2026
SomberNight
added a commit
to spesmilo/electrum
that referenced
this pull request
Jul 1, 2026
This was motivated by wanting to include the chaintip in responses but that part was reverted and postponed to later. ref spesmilo/electrum-protocol#17
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
2 participants
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.
partially reverts 9c32658
ref #2 (comment)
This does not revert the change of return type (array->dict) for
blockchain.scriptpubkey.get_historyblockchain.scriptpubkey.get_mempoolblockchain.scriptpubkey.listunspentas that makes it easier and more backwards-compatible to add new fields to the responses.