extension: Transaction delay causes nonce issue and 'locked' wallet for many hours
I have gone through this issue on many occasions now over many weeks and it makes the network quite impotent for things like limited NFTs.
- Initiate a transaction via the web wallet. The correct nonce is generated. Let’s say,
285
. - A
txid
is created but it does not show in the explorer (nor, obviously, under Activity in the wallet). - I initiate a second transaction a few minutes later and a new
txid
is generated which is shown in the explorer immediately with the next nonce;286
. - Now I have nonce
285
(which is still not shown) and nonce286
(which is ‘pending’ in the explorer). - If I try a third transaction, the web wallet goes back to nonce
285
and issues the same initialtxid
, which still does not show in the explorer.
And then I’m stuck; my wallet is useless for many hours. Even if I manually go to the next nonce (287
) with a third transaction (and get a new txid
), that will usually not show in the explorer either. But even if it does, it’s moot because none of them will go through until that first txid
that is missing in action shows up.
When I come back 6 or so hours later it is usually resolved but everything that came after the missing txid
either never shows up or fails because it’s taken so long. Meanwhile, many other wallets and transactions are going through just fine in a timely manner. Even that second txid
that is ‘pending’ would have gone through quite quickly if it weren’t for the fact that the prior nonce is nowhere to be found for hours.
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Reactions: 6
- Comments: 22 (4 by maintainers)
Interesting update.
The original
txid
w/ nonce285
that did not show in the stacks.co explorer, did show up immediately in the planbetter.org explorer. However, after about 2 hours it dropped from there and is now showing as “Transaction not found” in both explorers.So, I tried a nonce
285
transaction again for a Stacks Pop and this time, it produced a newtxid
. But as before, it is not showing in the stacks.co explorer, and it is in the planbetter.org explorer. I imagine the same series of events will occur and it will eventually show up as not found in the latter explorer, too.Either way, unless I can get a transaction with nonce
285
to successfully broadcast to the stacks.co explorer, my wallet is effectively useless (as are all pending/missing transactions after nonce285
).@gigawatson I’m not seeing that “Non-canonical” message in either the Hiro or PlanBetter explorers when checking now, so it appears to have been temporarily displayed? It’s the first I’ve ever seen it in general. @aulneau may have insight on what it means.
I’m not sure why these wait time differences would be the case, but I’d suggest filing this observed behavior directly in the API repository since I suspect the potential problem and solution are API or node-side.
I’m seeing the nonce listed now on your address page as
308
. All pending or “in microblock” transactions appear to have nonces of307
or below.I’m inclined to suggest you try another transaction, this one with
307
, to see if it succeeds (though I realize you’ve tried this manual setting approach before and it hasn’t worked, so I’m 🤞 here a bit). Want to give that a go?We’ll be investigating and discussing these issues in general as a team as our top priority this week.
What is this?
@markmhx
What am I to do at this point? The previous “nonce issue” was resolved by pushing the UI change to the wallet to allow people to adjust the nonce manually but this issue is different and not resolved by adjusting nonces.
I am now 23 hours without the ability to transact at all. My last successful nonce was
284
.The next nonce,
285
, will not show in the mempool and yet I get the “nonce conflict” error in the web wallet when trying another transaction with nonce285
.I have found that sometimes (or all the time?) these transactions get mined even though they do not appear in the explorer or the “activity” tab of the Hiro Wallet extension for web. This behavior seems unrelated by how full the mempool is.