Skip to content
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

client/dcr: investigate dcrwallet confirmation bug #2556

Open
buck54321 opened this issue Oct 3, 2023 · 4 comments
Open

client/dcr: investigate dcrwallet confirmation bug #2556

buck54321 opened this issue Oct 3, 2023 · 4 comments

Comments

@buck54321
Copy link
Member

See #2444, from which I'll copy some critical info here.

There is an issue given:

  • taker's swap tx is DCR
  • you shutdown dexc after the (taker) DCR swap transaction is broadcast, but before it is mined
  • start dexc, login
  • wait for DCR block(s), transaction always appears unconfirmed, swap never proceeds (except refund)

I believe you must be both maker and taker (self trade) for it to halt the swap because if you are not also the taker who authored the DCR swap transaction, then for maker, the SwapConfirmations method will fallback to cfilters scan when lookupTxOutput fails to find the transaction. Or so I would expect since the counterparty contract transaction would not be a wallet transaction.

The above is not always reproducible, but I managed to get it to happen twice with the native SPV wallet.

I tracked the culprit down to dcrwallet/wallet/udb.(*Store).TxDetails. It will find and return an unmined transaction that it finds with existsRawUnmined and unminedTxDetails (but it's really mined, several confs even).

https://github.com/decred/dcrwallet/blob/master/wallet/udb/txquery.go#L180-L194


This has been confirmed as a dcrwallet bug.

As per convo with @jrick, there's a very long standing known bug with wallet startup when there are unconfirmed transactions, whereby they are often never confirmed without a rescan. That appears to be what we are seeing.

dcrwallet appears to miss the transaction while doing its startup scan. Both @chappjc and I investigated, and while we didn't pin down the issue, I felt like there was hope.

Related #2442

@JoeGruffins
Copy link
Member

I can help investigate. I often see this on mainnet and so I just rescan every time I start up dcrwallet.

@JoeGruffins
Copy link
Member

I guess to reproduce I will need to undo #2555

@JoeGruffins
Copy link
Member

I was able to reproduce once so far. I wonder if chapp was on testnet or simnet and if he waited between mining blocks if on simnet. Because of the randomness, I wonder if it has to do with a block coming in during sync? Or during shutdown?

@JoeGruffins
Copy link
Member

JoeGruffins commented Dec 12, 2023

I tried quite a few times today with dcrwallet on master and could not get this bug to happen. I think I was on the last release last time I tried. Unsure if fixed so leaving for now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants