-
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
invalid balance for wallet with multiple coinbase transactions #1051
Comments
26 tasks
danielabrozzoni
added a commit
to danielabrozzoni/bdk
that referenced
this issue
Aug 22, 2023
We would previously insert just one coinbase transaction in the database if we caught multiple in the same sync. When we sync with electrum, before committing to the database, we remove from the update conflicting transactions, using the `make_txs_consistent` function. This function considers two txs to be conflicting if they spend from the same outpoint - but every coinbase transaction spends from the same outpoint! Here we make sure to avoid filtering out coinbase transactions, by adding a check on the txid just before we do the filtering. Fixes bitcoindevkit#1051
danielabrozzoni
added a commit
to danielabrozzoni/bdk
that referenced
this issue
Aug 22, 2023
We would previously insert just one coinbase transaction in the database if we caught multiple in the same sync. When we sync with electrum, before committing to the database, we remove from the update conflicting transactions, using the `make_txs_consistent` function. This function considers two txs to be conflicting if they spend from the same outpoint - but every coinbase transaction spends from the same outpoint! Here we make sure to avoid filtering out coinbase transactions, by adding a check on the txid just before we do the filtering. Fixes bitcoindevkit#1051
5 tasks
Thank you so much for the detailed explanation of the problem! Indeed it is a bug (and it is pretty crazy that no one noticed it before). #1090 should fix. |
5 tasks
notmandatory
added a commit
that referenced
this issue
Aug 22, 2023
530ba36 ci: fix msrv dependency versions for reqest and h2 (Daniela Brozzoni) 7a359d5 fix(electrum): Don't ignore multiple coinbase txs (Daniela Brozzoni) Pull request description: We would previously insert just one coinbase transaction in the database if we caught multiple in the same sync. When we sync with electrum, before committing to the database, we remove from the update conflicting transactions, using the `make_txs_consistent` function. This function considers two txs to be conflicting if they spend from the same outpoint - but every coinbase transaction spends from the same outpoint! Here we make sure to avoid filtering out coinbase transactions, by adding a check on the txid just before we do the filtering. Fixes #1051 ### Changelog notice - Fix a bug when syncing coinbase utxos on electrum ### Checklists #### All Submissions: * [x] I've signed all my commits * [x] I followed the [contribution guidelines](https://github.com/bitcoindevkit/bdk/blob/master/CONTRIBUTING.md) * [x] I ran `cargo fmt` and `cargo clippy` before committing #### Bugfixes: * [x] I've added tests to reproduce the issue which are now passing * [x] I'm linking the issue being fixed by this PR ACKs for top commit: notmandatory: tACK 530ba36 Tree-SHA512: ebbc6af86d4433ac4083212033a23f183d109641db345cc06ab4d506995ab71657761351c03772462ab4ff0d081226ecc97f1042490194aaf8661914cbeb72cb
🥇 thanks so much for the quick fix @danielabrozzoni and team |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Describe the bug
A wallet with more than one coinbase transaction mined to addresses owned by the wallet (or even the same address) shows only 5,000,000,000 balance (50 bitcoin) no matter how many blocks are mined to addresses owned by that wallet.
To Reproduce
I'm testing using two regtest bitcoin core nodes and a Fulcrum server. I'm also using an RPC to mine blocks on regtest nodes and test various circumstances. To eliminate as many variables as possible, I've reproduced the issue using only
bdk-cli
and adocker exec
shell connected to one bitcoin node and usingbitcoin-cli
. I also verify my results with a simple Rust example near the bottom.I believe I have sufficient evidence that the issue is not with Fulcrum, as I will explain below.
First, the setup and issue:
1)
in my
docker exec
terminal Igeneratetoaddress
1 block to address bcrt1q6g0mhnwcssfulc39as04k4xazaxt2s6eg0q6yj4uylzzcfy73n3sw8h3pw.the block generated is
1ae02086845d99eda3f6d8ca2605086bd00affe71acf941b9cc1437eb9403983
.then, generate 100 blocks to another random trash wallet created within the bitcoin core instance. this unlocks the block subsidy generated to the address we care about.
examine the interesting block:
bdk-cli repl
note that the txid is from the 1st block examined in step 2. all is good so far.
get a new address from bdk-cli (note the issue also occurs even if the same address is used)
mine 1 block to the new address. block hash:
4a82362711babdf23c0c54e0c4ff060394b269473a27e009eae3311051f2c0e5
mine 100 blocks to unlock the subsidy as before.
expectated behavior:
we should expect to see transaction
bc9744bd1a19b16319e417283528fac6474b6db745ca2d0c3a2cc8b8b5e9889d
listed in the wallet transactions (and unspent) and a new confirmed balance of 10000000000.actual behavior:
extra verification of the issue
so the question I had here is whether or not BDK was even seeing the second transaction. Maybe Fulcrum has a bug?
bdk-cli
replcd ~/.bdk-bitcoin
rm -rf *
-- remove all sled databasesnow, if I reopen the repl and sync again I should expect to see either:
A) 1 transaction and the second (index 1) address returned from
wallet get_new_address
B) 2 transactions and the third (index 2) address returned from
wallet get_new_address
note that I'm seeing 1 transaction and the index 2 address as the next unused address.
note that the 2nd transaction has replaced the 1st transaction in the list of transactions.
verify results:
in Rust:
Build environment
Additional context
The text was updated successfully, but these errors were encountered: