There have been instances of people attempting to send Veil against the flow of change, from RingCT to Stealth (CT). Some give the reason that they wanted to mint a zerocoin, and the larger balance was in their stealth balance.
Sometimes this results in the balance not being found, and rescanringctwallet and later, rescanblockchain 2246000 (or from a similarly recent block height) is used to correct the problem.
Even when it works, if they were trying to zero the RingCT balance in favour of the CT balance it's likely that change will now back to RingCT, defeating the purpose of the transaction!
This might be avoidable by educating people that Veil should always follow the flow of the target for change from a transaction, and the progress from publicly viewable amounts and addresses, to private, invisible amounts and unknowable or untraceable addresses. This is consistent with the strong, but evidently not strong enough, advice to mint (the reduced or lightened) zerocoins from RingCT instead of from basecoin or stealth (CT).
Such education cannot be complete and should be made unnecessary by automating the second step of the privacy process (in the CLI wallet, and not only the GUI wallet), such that when a basecoin utxo is sent to a stealth address, once a confirmation on the first step, arriving in the stealth (CT) balance, the stealth to ringct transaction should be automated for the full amount of CT balance.
Adequate progress information should be shown, such as the second command and transaction ID should be reported on the command line, and both transactions should appear as would be expected, in the GUI Qt wallet's transactions list on the Overview page.
There have been instances of people attempting to send Veil against the flow of change, from RingCT to Stealth (CT). Some give the reason that they wanted to mint a zerocoin, and the larger balance was in their stealth balance.
rescanringctwalletand later,rescanblockchain 2246000(or from a similarly recent block height) is used to correct the problem.