BirthdayResearch / defichain-app

DeFi Blockchain desktop app for Windows, Linux and Mac.
https://defichain.com
MIT License
158 stars 57 forks source link

Input not found or already spent #1077

Open RomanShumkov opened 3 years ago

RomanShumkov commented 3 years ago

What happened:

After running a node for some time I'm starting to get following error for any command I'm trying to run

utxostoaccount {"censored":"1@DFI"} Can't sign TX: [{"txid":"censored","vout":1,"witness":[],"scriptSig":"","sequence":censored,"error":"Input not found or already spent"}]

Workaround is to restart the node and to re-run the command and then it works fine without changing anything else (meaning that I have enough UTXO and DFI tokens).

What you expected to happen:

Expecting utxostoaccount to work fine even when node was running for some time already

How to reproduce it (as minimally and precisely as possible):

Not sure yet

Anything else we need to know?:

  1. This is something new and could be related to todays release.
  2. Running via console in desktop app v2.7.2
  3. I have tried locking and unlocking wallet when facing this issue and it does not help, so it's not due to locked wallet.
  4. I was also affected by DeFiCh/ain#913, not sure if it's related, but mentioning just in case
defichain-bot commented 3 years ago

@RomanShumkov: Thanks for opening an issue, it is currently awaiting triage.

The triage/accepted label can be added by foundation members by writing /triage accepted in a comment.

Details I am a bot created to help the [DeFiCh](https://github.com/DeFiCh) developers manage community feedback and contributions. You can check out my [manifest file](https://github.com/DeFiCh/ain/blob/master/.github/governance.yml) to understand my behavior and what I can do. If you want to use this for your project, you can check out the [DeFiCh/oss-governance-bot](https://github.com/DeFiCh/oss-governance-bot) repository.
RomanShumkov commented 3 years ago

After clearing local state and restoring latest snapshot it's running fine so far. I'll post an update if the problem comes back again.

defichain-bot commented 3 years ago

@RomanShumkov: Thanks for opening an issue, it is currently awaiting triage.

The triage/accepted label can be added by foundation members by writing /triage accepted in a comment.

In the meantime, you can:

  1. Checkout DeFiChain’s Github issue page to see if your issue has already been reported
  2. Submit any logs if you have them, this will greatly expedite the process for us.
  3. You can also join our Telegram or Reddit community channels.
Details I am a bot created to help the [DeFiCh](https://github.com/DeFiCh) developers manage community feedback and contributions. You can check out my [manifest file](https://github.com/DeFiCh/app/blob/master/.github/governance.yml) to understand my behavior and what I can do. If you want to use this for your project, you can check out the [DeFiCh/oss-governance-bot](https://github.com/DeFiCh/oss-governance-bot) repository.
RomanShumkov commented 3 years ago

After clearing local state and restoring latest snapshot it's running fine so far. I'll post an update if the problem comes back again.

Problem is still there. I think it has something to do with initiating more parallel transaction than there are unspent utxos available in the wallet. Once this threshold is reached, utxos remain unspendable even when utxos are transferred back to the same wallet during those parallel transactions.

So after facing the problem I'm getting this:

listunspent | jq . | grep spendable | grep true | wc -l
       0

After node restart utxos are spendable again:

listunspent | jq . | grep spendable | grep true | wc -l
       9
RomanShumkov commented 3 years ago

Here are more accurate steps to reproduce the issue in tests:

  1. Create 10 utxos (e.g. 10 * 1 DFI outputs)
  2. Publish 10 parallel poolswap transactions with maxprice attribute
  3. Wait for a block where some of transactions are mined and some of them are rejected because of price moving higher than maxprice
  4. Verify that you still have 10 utxos (something like 10 * 0.99999 DFI)

I assume that assertion in step 4 will fail, because utxos related to rejected transactions will be in some sort of limbo state until node is restarted. I would expect all 10 utxos to be available (spendable) again in step 4, but they are not.

@Bushstar, could you please take a look at this example and possibly reconsider moving it to app repo as it seems to be a node issue :)

JohannesBauer98 commented 2 years ago

Hey Roman,

i have already the same problem as you.

Did you find a solution for the problem?

dnamurphy commented 2 years ago

@JohannesBauer98 - I encountered a similar problem, albeit running from the CLI. The suggestion was to clear the mempool:

./defi-cli clearmempool

But there's perhaps no GUI option to do this in the app. Perhaps you can try in the console within the app?

GiaLinh1 commented 2 years ago

Hey Roman,

i have already the same problem as you.

Did you find a solution for the problem?

RomanShumkov commented 2 years ago

Hi @GiaLinh1, unfortunately not.

One workaround is to create more utxos, but this will only delay the problem and will require restart anyway.

I assume that the problem could be fixed by transaction expiration feature team is currently working on, but don't take my words for granted.

cc @uzyn

benameless commented 2 years ago

Any news how to solve this without a restart?