I'm on v0.8.2 on linux. After reading all documentation thoroughly, I attempted to purchase a ticket for the first time today. My transaction was rejected due to insufficient fees. Code: $ ./dcrctl --wallet purchaseticket default 79 1 "" 1 "" 0 121895 -22: TX rejected: transaction 1e34262146923049e43ca59f49799a667ef15b6c66a8f84eaa21a01beb2f77cd has a 300 fee which is under the required threshold amount of 296000 So I set the fees to a higher value and tried again. However, now all my DCR have vanished: Code: $ ./dcrctl --wallet settxfee 0.0001 true $ ./dcrctl --wallet purchaseticket default 79 1 "" 1 "" 0 121895 -4: insufficient funds available to construct transaction (Incidentally, it's not clear which of txfee or ticketfee caused this problem. As you can see, I guessed txfee.) My original transaction is still floating around unconfirmed in the mempool, even though its fees are insufficient and even though the transaction has long since expired. (Observe that I set expiry to block 121895.) https://mainnet.decred.org/tx/e1d7bc75ed0b24ec6e89718c8921d69d65d055c3be4dd09ed3c3a11460c08317 Other threads on this forum suggest that lost funds can be recovered by reseeding the wallet, though that solution doesn't seem to work for everyone. I will attempt it shortly. In the meantime... Questions/feedback: 1. It was not at all clear from the documentation that the 0.01 fee is a mandatory minimum. --> Why does the software even allow me to set a fee below the mandatory minimum? 2. It was not at all clear from the documentation that transactions with insufficient fees will lock up my funds while they sit unconfirmed in the mempool for some unknown amount of time. --> Why does the software broadcast a transaction it already knows to be invalid? And why does an invalid transaction continue to lock up my DCR? 3. It seems that the expiry setting on my transaction has been completely ignored. Even if the observed behaviour so far is by design (which it should not be), my transaction has now expired and so it should no longer be in the mempool. --> What exactly does the expiry setting do, and why does my expired transaction continue to lock up my funds? --> When will my DCR become available to me? 4. Finally, it should be clear by now that this observed behaviour is an absolutely terrible user experience. After reading all the documentation I should be able to muddle through ticket purchases on my own. It is unfathomable that something so simple as insufficient tx fees can result in funds being locked up for an indeterminate period of time.
To clarify... 1. The command dcrctl --wallet settxfee sets the fee rate per kB of the transaction that is generated. If you have a large transaction with lots of inputs, your total transaction size goes up. Therefore, I don't believe there's a minimum value that you can set for the fee rate; however, there is a minimum fee acceptable by the network. Individual ticket purchases are usually around 295 bytes, so if your fee rate is set to is 0.01, your actual fee is 0.295*0.01 = 0.00295. I believe the minimum fee allowed by the network is somewhere in the area of 0.01 DCR, so you will have to adjust your fee rate using settxfee accordingly. Secondly, the dcrctl --wallet settxfee command applies only to normal transactions (sending DCR). Ticket purchases are a different type of transaction (sstx), and have a different command to set the fee rate. The syntax for setting a ticket purchase fee rate is Code: dcrctl --wallet setticketfee 0.25 where 0.25 is my example of a fee rate for a ticket purchase transaction. Again, 0.25 is not the fee that you will pay. Instead, it is the fee rate in terms of DCR per kB. With a normal ticket purchase transaction totaling to 295 bytes (or 0.295 kB), the fee for this example would be 0.25 * 0.295, or 0.07375 DCR. 2. To my knowledge, the software creates the transaction, sends it to the network, and the network checks certain criteria and calculates the total fee. Any transaction that doesn't meet any of the criteria will be rejected, but IIRC, you may have to wait for a block to complete before the network agrees that your coins are back in your wallet. DCR is stored in a number of unique addresses in your wallet. When you create a transaction, the software finds the most appropriately sized address (containing the closest amount of coins to meet the requirement of your transaction), and sends the entire balance in the address(es) to the network. The network will then return your change to a new address in your wallet. This means that your balance will be artificially low until your transaction is confirmed and your change is sent back to you, 1 block later. 3. The expiry option in a ticket purchase simply means - if you don't get your tickets by block N, the transaction will be canceled and your funds will be returned. I haven't actually paid close enough attention to see if this happens in block N, or in block N+1, but it should happen somewhere around there. Since your expiry was set to block 121895, I would assume you have your funds back. Perhaps there is also a bug with using the expiry option when having too low of a fee rate.
Thank you David for the prompt reply. Some additional information: 1. To clarify: for my original sstx I had manually set *both* the tx fee and the ticket fee to something very small (eg 0.00001) via separate calls to settxfee and setticketfee. My logic was as follows: a) for ticket fee: I was bidding at a time when stake tickets cost 78.33 DCR. There is no competition at this price, so I thought I could win the auction with only a tiny ticket fee. b) for tx fee: there is currently a low volume of transactions on the network, so I thought I could get my sstx mined for only a tiny fee. 2. All of my DCR became accessible since my original post. I now see that the transaction linked above was mined in block 121938, two hours after I created this thread and long after the expiry block of 121895. It seems, then, that the locked funds were the result of a normal case of having a large utxo temporarily inaccessible while waiting for a transaction to be mined. (Incidentally, it's strange that it took so long to mine the transaction. Perhaps the delay was caused by my absurdly low tx fee?) 3. Given that my sstx was set to expire by block 121895, it seems wrong to me that this transaction could be mined after its expiry. Nodes should know to drop unconfirmed transactions if they've already expired. Advantages: (i) the sender doesn't waste transaction fees, (ii) the sender's utxo is not locked up waiting for the transaction to be mined, (iii) it reduces blockchain bloat by keeping expired transactions off the chain. 5. It's not clear why my funds were returned to me. Now that my sstx has been mined, shouldn't the amount of my bid be locked away until the auction is won or lost? My guess is that my funds were returned because ticket bid was rejected due to insufficient ticket fee. (By "insufficient" I mean that the ticket fee is below the mandatory minimum of 0.01, not that the ticket fee was above 0.01 but not large enough to outbid other bidders.) If that guess is correct then this behaviour must be spelled out more clearly in documentation. Also, it would be nice if the software produced some explanatory output at the time the sstx is mined. It seems wrong to me that a sstx with ticket fee set below the mandatory minimum of 0.01 is considered valid and can be mined into a block even though the Decred consensus protocol dictates (via the 0.01 minimum fee hard-coded into the protocol) that it could never possibly win an auction, even when there are no other bidders. The software should never allow such transactions to be broadcast in the first place. But even if such a transaction finds its way onto the network, nodes should know to drop it for the same reasons listed in item 3 above. 6. I'm aware that the fee is actually the rate per kB, but thank you for clarifying. Since my transaction eventually made it into the blockchain, we have proof that the network does not enforce an artificial minimum for the tx fee. However, it seems that the network does enforce an artificial minimum for ticket fees.
I was using purchaseticket with expiry parameter like 20 times now and it always expired as expected. Also on 0.8.2 Linux. Aside from that I'd like to know the answers to your questions too.
I'm guessing it was because of the very low fee. I've seen all sorts of weird things happen if the fee is below 0.01DCR. Exactly what the cause of that is, a dev would need to answer.
The expiry parameter is for the ticket transaction, not the consolidate transaction. When you buy a ticket, first the wallet creates a transaction output of the correct size to make the ticket. This is a normal transaction, and so should be mined in the next block, since there isn't competition. The Ticket transaction is the one where the fee normally really matters,as only 20 can be mined / block. The expiry setting is for the ticket transaction. The default minimum fee is 0.01 DCR/kb, so by lowering yours you created a transaction that most miners wouldn't mine. This meant that your consolidate transaction didn't get mined for a long time. This is what caused you the issues! However, the minimum fee isn't a consensus rule; it's just a config setting. The default will be changing to 0.001 DCR/kb in the next version, so some nodes might be running with the lower setting already. This would explain why your first transaction was mined, after a long delay. Your SStx transaction, was not mined, however, as it expired.
Very clear explanation, thank you Kandiru! I think I tried sending a normal tx with fee rate below 0.01 DCR/Kb and it was rejected. But that was only one attempt a month ago. I shall try again.