Transactions may include the hash of the previous transaction (i.e. transaction dependencies)

[moodysalem]

When sending a transaction, you should be able to include the expected hash of the transaction with the previous nonce. Doing so would prevent the transaction from being mined unless the transaction with the previous nonce and specified hash has already been included.

This adds security against replay attacks since a signed transaction with a specific nonce will only be valid if the previous transaction hash exists (I realize this protection is redundant given EIP155), and it also allows you to cancel a transaction and all the following transactions if the following transactions were sent with reference to their expected previous transaction hashes.

For example, I broadcast transactions A, B, C with nonces 0, 1, and 2 respectively using this feature. B references A and C references B. I decide I want to cancel transaction B and broadcast no-op transaction B' which has a much higher gas price and nonce 1. With this feature, A and B' are included, but C is thrown out because C referenced the transaction hash of B, which will never be included. Without this feature, C is not cancelled and can still be included.

[Arachnid]

This would require nodes to store hashes of all past transactions, which is currently outside what nodes are expected to retain, and would be a significant additional burden.

An alternative that I've advocated for before is to allow transactions to specify a past block hash; this would have to be one of the most recent 256 hashes, or with #210, one of the hashes still stored by that contract.

[moodysalem]

Wouldn’t they just have to store the last hash of every address along with the nonce?

[Arachnid]

That would still be a significant additional storage burden, as well as requiring a change to consensus.

[moodysalem]

Would the storage burden be on the same magnitude of the amount of storage required for the storing the blockchain?

256 bits for a transaction hash times 30 million addresses gives you about 8 million bits or 1 megabyte of raw data.

Yes it would require a fork but I’d think an optional feature like this would be uncontested and could go into the next major hard fork

[moodysalem]

Was totally off on my math, it's 30 million * 256 = about 8 billion bits (lol) so 1 gigabyte of raw data, plus whatever it costs to store that in a way where you can do fast lookups

edit: still not sure if that's prohibitively expensive in terms of storage

[moodysalem]

An alternative that I've advocated for before is to allow transactions to specify a past block hash; this would have to be one of the most recent 256 hashes, or with #210, one of the hashes still stored by that contract.

I don't understand how this would work if I'm sending all my transactions before any transaction is included in a block. E.g. A,B,C are all broadcast but none are included, how would I specify a dependency on a block hash that includes A when broadcasting B?

[github-actions]

There has been no activity on this issue for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

[github-actions]

This issue was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment.