Veil-Project / veil

Veil-Project
MIT License
118 stars 91 forks source link

sending RingCT "min relay fee not met" settxfee 0.0001 workaround #985

Open seanPhill opened 2 years ago

seanPhill commented 2 years ago

The first spend from RingCT in a (mainnet) wallet (restored from seed words) succeeded, but subsequent spends failed with messages similar to this (when sendringcttoringct):

Transaction commit failed: min relay fee not met, 37268 < 37584 (code 66) (code -4)

If sendringcttostealth then the error is like this:

Transaction commit failed: bad-commitment-sum (code 16) (code -4)

No amount of fiddling with transaction size, or waiting and rescanringctwallet, would fix this until doing the workaround settxfee 0.0001 which has been occasionally mentioned in Discord, but I don't see it in Github issues.

After a wallet has had the txfee set like this, this appears to never again be an issue for that user, which may be why this has not become an urgent issue for regular users.

Note: While the txfee by this method is set to 0.0001, the actual txfee in operation may calculate to 0.00372680 for example, perhaps depending on the number of utxos input.

After running the settxfee 0.0001 fix I ran a spending script with about a hundred spends into a fresh seed wallet (a pause of ten minutes, a rescanringctwallet, pause ten seconds, and spend again), which had zero failures.

What I would like to see is that the dynamic fee setting mechanism should consider the possibility of needing the settxfee as a minimum (with value of 0.0001). Note: 0.00001 did not work in the case of these large RingCT spends possibly involving a lot of utxo inputs.

seanPhill commented 1 year ago

For testing, people might like to unset settxfee, by using settxfee 0

Refer to: https://developer.bitcoin.org/reference/rpc/settxfee.html I noticed that when sending 6600 Veil (or similar amounts) from CT (Stealth) to RingCT it was requiring a fairly high fee, in that it failed to find enough for the fee if I sent anything more than sendstealthtoringct svAddress 6599.9, such as 6599.91, which would result in

error code: -4
error message:
AddBlindedInputs failed: ringctwallet Insufficient funds..

Bear in mind that all my CT UTXOs are normally the result of sending 200 Veil from tens, the stake rewards, and as they are always split into two UTXOs, the average UTXO size is 100 Veil, meaning that the above would have 64 inputs. Sending 6599.9 is fine, but I don't remember if I have previously settxfee 0.0001 on this particular wallet. Using settxfee 0 to see how it goes next time.

Note: "high fee", effectively 0.1 Veil (ten times the minting fee for a zerocoin — and possibly having to do it twice, to get an available 10000.01 Veil in the RingCT balance) to move the CT funds to RingCT before minting, while not much at present prices, would potentially dissuade some people from firstly sending to RingCT (for maximum privacy), as they can mint a single 10K zerocoin for a fee of only 0.01 Veil (more conveniently from CT than RingCT)! Of course, if they got their CT balance from another source they might have only a couple of UTXOs, and would therefore likely have a very low fee, but it's worth my time to see if I have unnecessarily set my fee calculation too high.

seanPhill commented 1 year ago

For those who don't know, the figure of 200 Veil per spend comes from 20 ten denom zerocoins being spent to CT, and even if you spend 10000 all at once it will still auto split this one action into fifty transactions of 20 zerocoins at a time. 20 x 10 = 200. There is a maximum of twenty zerocoins in a single transaction.

seanPhill commented 1 year ago

Using settxfee 0 to see how it goes next time.

I have since sent another 9199 Veil from Stealth (CT) to RingCT from this wallet, having used settxfee 0 to eliminate the manual override of the minimum transaction fee calculation. Having taken it from a stealth balance of 9200 Veil I received 0.9 Veil in change, as the main output went to a different wallet (where I will be minting a 10000 denomination zerocoin), which means the total fee of this larger transaction was still 0.1 Veil, the same as it was with the 6599.9 transaction. The earlier transaction might potentially have had a slightly less than 0.1 Veil fee, but as I only allowed 0.1 for the fee (difference between the spend and the balance (total of utxos) it came from, the difference might have been less than the dust limit.

So, the settxfee 0.0001 (per Kb) workaround for a failed tx might not usually be necessary, as waiting another block for fee calculation really does fix it usually, we have this fix for the odd occasion it might be necessary. However, now we know how to reset the wallet to potentially charge us a smaller fee per kilobyte, as it would by ordinarily.

seanPhill commented 1 year ago

Just a follow up. For comparison I just moved 699 Veil out of a 700 Veil CT balance and the fee was hardly less than for the larger transactions. 0.09594136 Veil, when it would have been out of only eight utxo inputs. Currently that is barely 3.8 hundredths of a cent, but given a coin price of say, $10, it would be 95.9 cents (against a transaction value of $6,990), so probably as the coin price approaches and exceeds a dollar we would be looking at factors that influence fees. Presently fees are burned, but well before we reach maximum supply we will be switching to rewarding full node holders with transaction fee income.

These notes might be used for another FAQ on the Support Desk website, but leaving this issue here open for further reference.