Pre-Paid preauth fee #293
Description
One issue with Pre-Auth transactions is that there is no way of guaranteeing there will be sufficient fee and reserves at the time it executes for it to properly execute. This can result in a pre-auth transaction failing.
A solution for this is a new kind of pre-auth which bundles an amount of lumens to be made available when that transaction is executing or having fee assessed.
When such a key is added as such H(H(PreAuth) || Fee Amount). The Fee Amount is revealed when adding the key, which is then subtracted from the account. When the preauth is being executed/fee checked in validation, that amount is added back to the account.
This doesn't fix the issue of fees increasing or changing, but makes it easier for protocol developers to ensure sufficient fees and reserves are available for their contracts to execute.
Such pre-paid fees should not be counted for the general reserves of an account, as they should not permit another transaction with insufficient fees or reserves to succeed.
To address the issue of fees changing on the network, it might be possible to allow a third party to 'pay into' a fee reserved preauth by revealing the preimage to H(H(preeauth) || fee amount) and then making a payment to it to be H(H(preauth) || fee + payment). This would require users to listen for such payments as they could make it difficult to execute transactions if an attacker updates the fee frequently. A cache of the last N ledgers of updated preimages (e.g., H(H(Preauth) || fee) -> H(H(preauth) || fee + payment)) which could be consulted at validation time could fix this as long as the user is aware of fee bumps at least N ledgers old.