Bug: Unsigned note consumption can force an account to pay fees when `allow_unauthorized_input_notes=true`

[onurinanc]

Root Cause: auth_tx_acl can skip signature::authenticate_transaction when input note consumption is allowed, but transaction fees are still charged to the executing account.

Example:

• A public account uses AuthSingleSigAcl with allow_unauthorized_input_notes=true.
• An attacker submits a transaction that consumes a (possibly zero-asset) input note, creates no output notes, and calls no configured trigger procedures.
• auth_tx_acl takes the no-signature branch and the account still pays the transaction fee.

Location: miden-standards/asm/account_components/auth/singlesig_acl.masm

AuthSingleSigAcl computes auth_required as the OR of (1) "a trigger procedure root was detected as called", (2) "output notes were created and allow_unauthorized_output_notes is disabled", and (3) "input notes were consumed and allow_unauthorized_input_notes is disabled" (see the auth_required computation in auth_tx_acl). When auth_required is false, the procedure returns successfully without calling signature::authenticate_transaction, meaning the account can be executed in a "no-signature" mode.

If allow_unauthorized_input_notes=true, then input note consumption does not force authentication (see the input-note gate in auth_tx_acl). In this configuration, a transaction can consume at least one input note while avoiding both output-note creation and trigger procedures, keeping auth_required=false and skipping signature verification. Since transaction fees are still charged to the executing account, this enables fee-drain and sustained denial of service by repeatedly executing unsigned transactions until the account's fee-paying balance is exhausted; this is amplified by the no-signature nonce logic that may preserve the nonce when no pre-fee state change occurs (see the conditional nonce bump in auth_tx_acl and the fee-parameter commitment described in signature::authenticate_transaction).

How to resolve this issue?:
Approach 1:
We can consider requiring authentication whenever tx::get_num_input_notes != 0 for accounts that may be targeted by third-party executors, or otherwise ensuring that "no-signature" transactions cannot cause fee payment on behalf of the account (e.g., by forcing a nonce increment on any note consumption, or by requiring a signature for any transaction that consumes notes). Consider documenting and enforcing that allow_unauthorized_input_notes=true is unsafe for public accounts unless an additional executor authorization mechanism exists.

Approach 2:

Originally specified by @PhilippGackstatter in this comment: #2958 (comment)

We can flip the ACL semantics, mirroring the pattern already used by AuthMultisig::compute_transaction_threshold: instead of listing the procedures that trigger a signature requirement, we list the procedures that are exempt from it. Everything not on the exempt list defaults to requiring a signature, so forgetting to register a new setter can never silently leave it permissionless. This also lets us removing allow_unauthorized_output_notes and allow_unauthorized_input_notes flags.

Under the proposed semantics auth_tx_acl enforces three invariants and computes auth_required as their OR:

• any called procedure that is not on the exempt list forces auth_required = true.
• if any input note is consumed AND no procedure from the exempt list was called during the transaction, auth_required = true. This is the replacement for the removed allow_unauthorized_input_notes.
• if any output note was created, auth_required = true, unconditionally.

[bobbinth]

One other potential way to address it is for the user to install a note allowlist on their account. I think this should be a strongly recommended practice for all public accounts (right now, we are doing only for network accounts). This way, people won't be able to apply un-intended notes to the account.

[PhilippGackstatter]

We can consider requiring authentication whenever tx::get_num_input_notes != 0 for accounts that may be targeted by third-party executors

This implies removing allow_unauthorized_input_notes, right? We probably want to retain the ability for a random userl (not the owner) to create an asset-burning transaction against a public, non-network faucet.

if any input note is consumed AND no procedure from the exempt list was called during the transaction, auth_required = true. This is the replacement for the removed allow_unauthorized_input_notes.

Isn't this implicitly covered by the changed ACL logic?
Example:

• I configure a public, non-network faucet to have receive_and_burn exempt from signatures, nothing else.
• Consuming a MINT note requires a signature, since a non-exempt account procedure is called.
• Consuming a BURN note is exempt from a signature, since no non-exempt account procedure was called (only the exempt receive_and_burn).
• If a non-standard note is consumed that calls both receive_and_burn and mint_and_send, it requires a signature since the latter is not in the exempt list.

So I think we don't even need to check the number of input/output notes at all with this approach.

The problem remains that if the fee is deducted after the signature was verified, the account can still be fee-drained, afaict. Though this seems a bit orthogonal to the ACL changes, which I think would be independently good.

install a note allowlist on their account

This is conceptually very close to the AuthSinglesigAcl, as both are essentially access control list, one just based on note scripts, the other on account procedures. The note allowlist auth component would also have to cover the tx script like we do for network accounts, so that users cannot call other account procedures from a tx script. We'd still want to enable the owner to create transactions with a tx script for changing some config.

---

Even with these changes, the fee-draining may still be possible (BURN note with a zero-value or almost-zero-value asset). To prevent this, I think the auth procedure needs to differentiate between:

• transactions that require a signature (e.g. when a tx script was executed). In this case, the fee can safely be taken from the account vault itself.
• transaction that do not require a signature (e.g. consuming a BURN note). In this case, fees must be paid for in the same way as for network accounts (e.g. Separate business and fee logic for network accounts #2968, but out of scope here). Presumably, this involves the auth procedure checking that a "fee note" was consumed with a sufficient amount, or that the account delta contains an entry that says "1 USDC was received" (the fee).

Overall, I think the AuthSinglesigAcl route is a bit more flexible, as it would keep the exact fee payment note open (e.g. whether it is FeeNote or FeeNoteV2 doesn't matter), whereas the note allowlist would have to be updated by the owner to include the V2 note.