You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: