forked from monero-project/monero
-
Notifications
You must be signed in to change notification settings - Fork 116
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
TX submission failing sanity check #1639
Milestone
Comments
This sanity check is not consensus code; it is called by the wallet in |
jagerman
added a commit
to jagerman/loki
that referenced
this issue
Jan 16, 2024
The checks here break wallets sometimes (see issue oxen-io#1639). They aren't really "sanity checks" anyway because there are lots of legitimate ways a wallet could end up producing such a transaction, especially with Oxen's relatively low output creation rate.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
A community member recently reached out to me for help with a wallet that failed to stake/send/sweep its balance. After some diagnostics we got down to this wallet error:
and on the receiving daemon:
where X and Y are fairly large numbers (between 1000 and 2000), with X about 79% of Y.
This in turn comes down to this condition
oxen-core/src/cryptonote_core/tx_sanity_check.cpp
Line 87 in b309bf8
@tewinget and I had a bit of discussion around this, and it seems likely to be caused by a combination of batching and the way the wallet chooses decoys: it selects some recently block heights, then goes searching for outputs around those blocks. Because because we have some blocks with 0 outputs, the selection of decoys is often going to end up selecting the same block: for example if I look randomly for an output in block heights 1000-1020 but there are only 3 batch payments in that range, there is going to be far more duplication among the outputs we select, and thus (in this user's case) the 79% was triggered.
There are a few ways we can go about fixing this, perhaps by selecting from a distribution over output indices rather than block heights, by selecting from a larger range of potential decoy blocks, or by changing the selection distribution to be more appropriate. We also might consider lowering the "sanity check" threshold here (which appears to just be a completely arbitrary value since it started at 90% then was changed to 80% because 90% triggered sometimes).
Unfortunately, all of these require a hard fork because existing nodes would reject anything that fails the sanity check here.(See comment below). We ought to be able to add an interim workaround for this with a oxen-node update that reduces the sanity check threshold.--
Avoiding the issue
If someone else runs into this same issue, the workaround to clear the wallet by sending it back to yourself in smaller chunks, as follows:
This is most likely to affect wallets that were staked and haven't been swept since long before the Oxen 10 hard fork: they tend to build up enough outputs to trigger the issue. (It's less likely to reoccur once fixed, or on a wallet swept since Oxen 10 started, since the number of outputs accumulated will be much lower with batching).
The text was updated successfully, but these errors were encountered: