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

occasional ticket purchase error: "insufficient funds" #3974

Open
norwnd opened this issue Oct 20, 2024 · 0 comments
Open

occasional ticket purchase error: "insufficient funds" #3974

norwnd opened this issue Oct 20, 2024 · 0 comments

Comments

@norwnd
Copy link

norwnd commented Oct 20, 2024

When trying to buy a mixed ticket, occasionally Decrediton outright (once you've typed in your password) throws an error along the lines of "insufficient funds",

I do have enough funds because I've just ran mixer that resulted in sufficient sum showing in my mixed account (and previously the button to purchase ticket was locked out while now I can press on it),

restart/rescan doesn't seem to necessarily help right away, after certain number of retrying (waiting between attempts) eventually I'm able to purchase a ticket.

Also note, this is somewhat similar to #3057 (which I didn't encounter recently but if it is still a thing - it would probably be better to hide the issue from the user by creating intermediate transaction that splits single UTXO into 2 and uses these 2 resulting UTXOs to proceed accordingly).

I've looked into relevant code a bit, my guess would be - it says "insufficient funds" because those mixer transactions just don't have enough confirmations yet ... looks like Decrediton requires 4 confirmations when asking dcrwallet to do ticket purchase. I guess it's 4 and not 0 because a bunch of people participate in mixing, hence we wouldn't want to abort the whole mixed-ticket-purchase transaction (that buys tickets for a bunch of people) just because 1 participant's UTXO got forked off the main chain. At the same time, it seems mixing algo itself must pick only those participants who supply sufficiently robust UTXOs to it (and delay unreliable UTXOs until later iterations) because it's a potential DoS attack vector - so to me it seems strange to have Decrediton self-limit to 4 confirmations (which btw seems to do it not only for ticket purchases but also for other kinds of outgoing transactions).
Also note, having these 4 confirmations isn't a 100% guarantee for Decrediton that ticket purchase will succeed, which means it still need to handle unsuccessful outcome regardless (so why not just handle it slightly more often by setting required confirmations to 0 on ticket purchase, and all other outgoing transactions for that matter).

And if there is a reason for requiring a certain number of confirmations (> 0) for outgoing transactions on Decrediton side, perhaps it would be better to just set it to the same value for all types of transactions (incoming and outgoing, balance counting, etc.) so that your balance value actually reflects the true value you can use at any given moment. However suboptimal this would be, it would at least result in consistent behavior.

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

1 participant