Pre-Paid preauth fee

[JeremyRubin]

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.

[github-actions]

This issue is stale because it has been open for 30 days with no activity. It will be closed in 5 days unless the stale label is removed, or a comment is posted.

[MonsieurNicolas]

Deterministic behavior of chains of transactions despite fee/reserve changes. This would be needed especially if we want to support base reserve increase

[leighmcculloch]

Is this problem less of an issue now that CAP-15 Fee Bump Transactions and CAP-33 Sponsorship are implemented?

Fee bump allows a pre-authorized transaction to pay zero fee and another account to pay the at the time of submission, so there is no need to predict the fee ahead of time. The fee can be set to zero for the preauth.

Sponsorship is not quite as powerful for this use case because it can't be defined at submission time, but at the least it allows all reserves to come from some other account so that any accounts created or operated on in the pre-authorized transactions do not need to provide reserve.

@MonsieurNicolas @JeremyRubin Do these CAPs sufficiently solve this problem?

[MonsieurNicolas]

no @leighmcculloch : this is tracking something different. If we were to raise the base reserve, we would potentially invalidate existing pre-signed transactions.

You can't wrap an existing transaction with a "sponsorship" construct similar to how you can wrap an existing transaction to pay for fees.
Also, unlike fees, a presigned transaction can get submitted to the network and would fail, breaking the smart contract.