Automatically merged updates to draft EIP(s) 3074 (#3415)

Hi, I'm a bot! This change was automatically merged because:

 - It only modifies existing Draft, Review, or Last Call EIP(s)
 - The PR was approved or written by at least one author of each modified EIP
 - The build is passing

EIPS/eip-3074.md

@@ -184,12 +184,28 @@ An important note is that invoker contracts **MUST NOT** be upgradeable. If an i
 
 The reason for banning signatures from `tx.origin` is that subsequent `AUTHCALL`s would result in `msg.sender == tx.origin`. This however is a frequently used pattern to test for top-level execution (i.e. being called directly from an EOA). Banning `tx.origin` as signer keeps this invariant intact.
 
+In its current form, this restriction complicates the use of the EIP for simple transaction batching, as the sender of the outer transaction must be different from the signing account. It is possible to lift or otherwise mitigate this restriction in the future. Potential alternative approaches are:
+
+* Simply allow `tx.origin` as signer. This would require research into the impact on existing applications.
+* Set `tx.origin` to a constant `ENTRY_POINT` address for `AUTHCALL`s.
+* Set `tx.origin` to the invoker address for `AUTHCALL`s.
+* Set `tx.origin` to a special address derived from any of the sender, invoker, and/or signer addresses.
+
 ### On Call Depth
 
 The EVM limits the maximum number of nested calls, and naively allowing a sponsor to manipulate the call depth before reaching the invoker would introduce a griefing attack against the sponsee. That said, with the 63/64th gas rule, and the cost of `AUTHCALL`, the stack is effectively limited to a much smaller depth than the hard maximum by the `gas` parameter.
 
 It is, therefore, sufficient for the invoker to guarantee a minimum amount of gas, because there is no way to reach the hard maximum call depth with any reasonable (i.e. less than billions) amount of gas.
 
+### Source of `value`
+
+Any non-zero `value` passed into an `AUTHCALL` is deducted from the invoker's balance. A natural alternative source for `value` would be the `authorized` account. However, deducting value from an EOA mid-execution is problematic, as it breaks important invariants for handling pending transactions. Specifically:
+
+* Transaction pools expect transactions for a given EOA to only turn invalid when other transactions from the same EOA are included into a block, increasing its nonce and (possibly) decreasing its balance. Deducting `value` from the `authorized` account would make transaction invalidation an unpredictable side effect of any smart contract execution.
+* Similarly, miners rely on the ability to statically pick a set of valid transactions from their transaction pool to include into a new block. Deducting `value` from the `authorized` account would break this ability, increasing the overhead and thus the time for block creation.
+
+At the same time, the ability to directly take ether out of the `authorized` account is an important piece of functionality and thus an desired future addition via an additional opcode similar to `AUTHCALL`. The prerequisite for that would be to find satisfying mitigations to the transaction invalidation concerns outlined above. One potential avenue for that could be the addition of account access lists similar to EIP-2930, used to signal accounts whose balance can be reduced as a side effect of the transaction (without on their own constituting authorization to do so).
+
 ## Backwards Compatibility
 
 No known issues.