[Discussion] ECIP-1105: Ancestor Hash Appended Type Transactions

[meowsbits]

trafficstars

Discussions-To for https://github.com/ethereumclassic/ECIPs/pull/421

Simple Summary

Defines a new transaction type with constraints on ancestor block hash, block author, and/or block timestamp maximum.

[meowsbits]

cc @bobsummerwill re: https://github.com/ethereumclassic/ECIPs/pull/421#issuecomment-827995921

The general intention/big idea behind this proposal comes from a few ideas happening together.

• Transactions (and their fees) are going to get more important for miner revenues and the whole economy as block reward revenues systematically fall (per the ECIP-1017 schedule). Developing the sophistication of transaction capacities seems meaningful in this context. And EIP-2718, via ECIP-1103, proposes a tidy, generic way for us to do just this.
• Transactions are unilaterally agnostic about chain state; they depend on and modify chain state intrinsically (a posteriori), but have no way of describing any dependencies on chain state as parameters for their validity (a priori). (Indeed, contracts have access to certain state values, but their use demands gas and on-chain logic). To offer an example, we might consider a transaction interacting with a DeFi contract. The transaction author saw a whale buy an asset at price X in the latest block N. The transaction author subsequently wants to get in on the action and buys at X+1, which gets mined at block N+1. Two blocks are reorged and the whale's transaction has been replaced with a buy at a lower price Z (or omitted entirely), but our victim's buy still stands at X+1. With a restrictive chain context on ancestorId, our author can specify that her transaction is only valid if the original block remains canonical. The proposed expiry field fits in here obviously, too.
• Currently, miners are almost entirely homogeneous from the perspective of a transaction author; there is no capacity to identify or articulate preference. Want a transaction Made in the USA :registered:? At this point, this effectively requires sending your preferred miner an email (and hoping they don't turn around and sell it). In other words, chain provenance is a black box for transaction authors.
• Miner omniscience and unchecked arbitration coupled with transaction passivity enable potentially malicious MEV (Miner Extracted Value) schemes. The capacity for transaction authors to spurn a miner (or reward an honest one) is a potentially significant tool in leveling this playing field.

It's been a long day, and I'm pooped, so I'm going to leave this at that for starters. I hope you have questions, and look forward to tackling them together.