Possible to create new rent-paying accounts

[jstarry]

Problem

The new require_rent_exempt_accounts feature introduced by #22292 still allows new rent-paying accounts to be created when a transaction fee payer account is rent exempt but after tx fees becomes rent-paying. This can happen in two ways:

1. The pre_account_state_info variable captures accounts post fee collection and if a previously rent-exempt fee-payer account became rent-paying after tx fees, it will appear to be a pre-existing rent-paying account and will be allowed to remain rent-paying.
2. Failed transactions which are committed to a block are not checked for rent-exemption at all. So if a rent-exempt fee payer account becomes rent-paying from the tx fees and the tx also fails, it will be stored as rent-paying.

Proposed Solution

Add a check that previously rent-exempt fee payer accounts do not become rent-paying after tx fees are deducted.

[jackcmay]

Do we allow non-rent-exempt fee payer accounts? Looks like the fee payer either has to contain no data, or be a nonce in which case it is checked that its balance - fee is still exempt.

[CriesofCarrots]

Easy repro of case 1:

$ solana-test-validator
$ solana transfer <ACCOUNT> .00089088 --allow-unfunded-recipient
$ solana transfer <RECIPIENT> 1 --fee-payer <ACCOUNT> --allow-unfunded-recipient

$ solana account <ACCOUNT>
Public Key: <PUBKEY>
Balance: 0.000878441 SOL
Owner: 11111111111111111111111111111111
Executable: false
Rent Epoch: 1

$ solana rent 0
Rent per byte-year: 0.00000348 SOL
Rent per epoch: 0.000002439 SOL
Rent-exempt minimum: 0.00089088 SOL

As Justin pointed out, the pre-rent-state considers the balance with fee substracted, so if the fee takes the payer account below rent-exempt minimum, it is grandfathered in to remain rent-paying when it shouldn't be.

[jackcmay]

Does that account hold data?

[CriesofCarrots]

Does that account hold data?

Nope

Do we allow non-rent-exempt fee payer accounts? Looks like the fee payer either has to contain no data

Yeah, if there is no data, a rent-paying fee payer is totally allowed.

[jackcmay]

Ah, got it, keep forgetting that zero-data length accounts can still be rent payers (overhead).

[CriesofCarrots]

@jstarry , the fix is mostly straightforward, but there's one case I can't figure out how to handle: when a fee-payer account has a small enough balance that the fee would make the account RentPaying, but the contents of the transaction would empty the account. Do you have any thoughts? Can we just fail those transactions (requiring users to pay the fee with another account, or transfer in enough to cover the fee before closing)?

The reason I'm stuck on this is because if we allow such a transaction to go through to processing in order to find out if it would be emptied by the transaction, there really isn't a way to catch transactions in case 2 above (without some awful fee rollback, which I'd rather not do).

[jstarry]

@jstarry , the fix is mostly straightforward, but there's one case I can't figure out how to handle: when a fee-payer account has a small enough balance that the fee would make the account RentPaying, but the contents of the transaction would empty the account. Do you have any thoughts? Can we just fail those transactions (requiring users to pay the fee with another account, or transfer in enough to cover the fee before closing)?

I think it's best to reject those transactions and agree that trying to handle them would introduce too much implementation complexity. It wouldn't be great if we had to fully process a transaction to see if it's valid or not. I think this approach is clearer for users as well, that there is no case that a transaction can be committed if the fee payer account can't stay rent exempt after fees.

[CriesofCarrots]

Excellent, that's what I did :)

[github-actions]

This issue has been automatically locked since there has not been any activity in past 7 days after it was closed. Please open a new issue for related bugs.