avoid_reuse=true is incorrectly skipping one of my UXTOs #26317
Comments
|
Interesting bug but I could not reproduce. Would be helpful if there was some research and steps to reproduce. Not sure RBF does it because I tried with custom change address as well. Zap config doesn't exist anymore. |
|
I've been using the same wallet since 2011 so it's really hard to know when this happened. I don't see anything in the code that ever clears the 'used' key once it is set on an address. I was thinking that bumping the fee using RBF might occasionally drop one input for a bigger input when necessary but I see from the code that that doesn't happen:
So I don't know. It could well be that this happened long ago due to a bug that has already been fixed. I'm just going to spend the missing UTXO back to a new address using a raw transaction and forget about it but thought it might be useful to mention here that it happened to me. |
|
I think you misunderstand me. I'm not looking for help. I am reporting an issue. It is apparently rare and I can work around it by spending the hidden UTXO using the raw transaction RPCs. |
|
@dooglus how did you sum your unspent outputs, using I did manage to re-create "losing" UTXOs from a wallet. Setting the We can also see in the Miniwallet source that it is somewhat (obscurely?) known that transactions might get "lost" if the transaction was RBFed after a re-org. |
|
I summed the outputs listed by the I don't remember whether I ever manually enabled the "avoid reuse" flag on my wallet, or it is it on by default, but maybe you don't have it on, and I do? Check this code in Do your "lost" UTXOs show up with |
|
I'm not sure exactly how to check the current state of a flag on a wallet (perhaps Perhaps you can force disable the wallet flag with |
|
Yes, that fixes it: Interesting that it suggests rescanning the blockchain to fix which destinations are marked as used. Does that mean running I tried running that on just the block that created the UTXO in question but it didn't change anything. Perhaps I have to rescan the whole chain? I didn't see any code that is capable of clearing the 'used' key for a destination, so suspect that it might not work, unless it starts off by clearing all the 'used' keys. I'll try rescanning the whole chain and report back - it seems like it's going to take a while. |
I think that would be the only way that this could happen. It does not look like there is a way to clear the used status of an address, although the capability is there. The "easy' way to resolve this would be to spend that UTXO. You could also attempt to modify the db directly and remove that particular record. In terms of long term solutions, we could add a RPC that removes the record, but that seems potentially dangerous as that could work on any address that is used. We could also have a RPC to recompute the used state of each address. The question with that is whether a rescan should occur, or whether it should scan just |
|
The rescan took over 9 hours, finished a few hours ago, and has left bitcoin-qt unresponsive. Here is the end of Note no new log activity since the rescan completed even though new blocks were being downloaded while the rescan was in process. I got timeout errors on both the rescan and the following listunspent: I guess this is a separate issue related to a semaphore deadlock or some such, but don't know how to investigate that. The bitcoin-qt is currently still frozen and running in gdb if there is anything useful I can do before killing and restarting it. |
|
Never mind - the gdb window shows that bitcoin-qt had crashed. It shows: This is the thread 35 backtrace: And here are all the backtraces: |
|
I restarted bitcoin-qt after the rescan and crash and the UTXO that hasn't been used is still marked as used. |
|
@dooglus Spammers |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
and others
I noticed that the sum of my unspent outputs is greater than my balance.
Upon investigating it turns out that this is because one of my outputs is marked as "used", even though it hasn't been.
Tracing through the execution I see that
CWallet::IsSpentKey()is returning here:and
IsAddressUsed()is looking for keyusedin the address book for that address, and presumably finding it.The address of the UTXO in question only has a single transaction, creating my UTXO. The address isn't reused, and no other address with the same public key is used either.
The UTXO was created in Feb 2020 and I've used many different versions of Bitcoin Core since then, so I don't know when or why the UTXO's address was marked as "used".
Could it be that I made a transaction that spent that UTXO but the transaction never confirmed and I later "zapped" it? Or RBF'ed it, causing different inputs to be used?
The text was updated successfully, but these errors were encountered: