-
Notifications
You must be signed in to change notification settings - Fork 321
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
fix(electrum): fixed chain sync issue #1145
fix(electrum): fixed chain sync issue #1145
Conversation
07d282f
to
330dfc5
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've added a debug print: diff --git a/crates/electrum/src/electrum_ext.rs b/crates/electrum/src/electrum_ext.rs
index 1ce16627..759732da 100644
--- a/crates/electrum/src/electrum_ext.rs
+++ b/crates/electrum/src/electrum_ext.rs
@@ -313,6 +313,7 @@ fn construct_update_tip(
.map(|h| h.block_hash());
(start_height..).zip(hashes).collect::<BTreeMap<u32, _>>()
};
+ println!("Found blocks: {:?}", new_blocks);
// Find the "point of agreement" (if any).
let agreement_cp = { I then sent some signet coins to my address, the txid of the transaction is
|
With this patch applied, what I saw is that after the transaction is confirmed in the block on signet, I sometimes would have to sync 2-3 times for the balance to show 0 unconfirmed sats. Before the patch, what I saw was that the local chain tip was always a block behind, so the balance would always show unconfirmed sats until after the second confirmation (again, sometimes requiring running sync 2-3 times). Console output after 1 confirmation:
|
I can try again later, I just wanted to say, I'm not opposed to merging the PR, I just want to make sure that it actually fixes the issue before closing it. I tried syncing multiple times and while the tx had only one confirmation it would still show up as unconfirmed. |
Hmm. Maybe @evanlinjin can see if this fixes the bug in his environment? |
If I'm wrong, and after merging this PR nobody is able to reproduce the bug again, we can just close the issue and calling it a day; but I'd like to be sure before closing. I've reproduced the bug again:
|
WRT to whether there's still an issue. Can we write a test against |
See also earlier PR from @vladimirfomene to add tests: https://github.com/bitcoindevkit/bdk/pull/979/files |
Replaced by #1163. We will close this PR when that one is merged |
I've closed #1163 as I agree with @LLFourn's points and we can update the bug fixes to electrum crate separately. @LagginTimes I think the next steps should be
|
Since I'm the only one being able to reproduce the bug still, do you need help with debugging? :) |
330dfc5
to
d58f13d
Compare
Rebased with #1182 CI fixes. |
Fixed a logic error in `construct_update_tip` in `electrum_ext.rs` that caused the local chain tip to always be a block behind the newest confirmed block.
d58f13d
to
1010efd
Compare
A chain sync test was written as part of #1171 that successfully reproduced the issue described in #1125. This PR seems to at least partially fix #1125 w.r.t. patching a logical flaw that was confirmed with the #1171 test. However, I am uncertain if it fixes @danielabrozzoni's issue that both @evanlinjin and I have unfortunately been unable to reproduce. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Description
This may or may not fix #1125.
Fixed what appeared to be a logic error in
construct_update_tip
inelectrum_ext.rs
that caused the local chain tip to always be a block behind the newest confirmed block.Checklists
All Submissions:
cargo fmt
andcargo clippy
before committingBugfixes: