Open jp1ac4 opened 1 month ago
As we were saying in the engineering meeting, there could be different ways to approach the v8 requirement - which is to have a syncing signal in the GUI before the first poll runs after opening it (#1373) - than using blockchain height, since this would possibly make it occur also at later stages of the wallet usage - i.e. every time we detect the blockchain height to increase before the poller runs. We will first investigate possible alternatives before proceeding.
Still, this issue could be useful to align the behavior of electrum to what we have with bitcoind.
I remove this issue from the milestone for the moment. Then, if the blockchain height approach will be decided for that, we can re-include it.
This will be useful if we want to include the current blockchain height in the
getinfo
result (related to #1361).The
chain_tip
method is part ofBitcoinInterface
. For Electrum backends, this method currently returns the height of the local chain, which means it is the blockchain height at the last poller sync.There may be cases where we want the current blockchain height on the server and someone might call this method expecting that, especially given this is what's returned for bitcoind.
The idea would be to change the implementation of this method for Electrum backends to return the current blockchain height on the server. This would require a change to the poller logic regarding how we call
new_tip()
to ensure that for Electrum, we continue to use the local chain tip resulting fromsync_wallet()
.