Allow transactions to explicitly specify mutual exclusion (up to transaction lifetime).

[derbear]

(idea originally from @zeldovich)

When a transaction is first submitted, its fee may be too low for it to clear, as the network might be congested with many transactions.

When that happens, it would be nice to submit a new copy of that transaction, but with a higher fee. However, this is currently unsafe, as now both transactions may execute, causing the spender to send funds twice as an unintended consequence.

Moreover, for the upcoming TEAL contracts, it is oftentimes nice to leave the fee field unconstrained (but capped at some max value) so that a transaction submitter can later pick a fee appropriately at submission time. However, for contracts that don't close accounts, this leaves the possibility of replay open.

It would be useful to add a field to transactions that provides explicit mutual exclusion with other transactions. Transactions could have an additional field (maybe called CollidesWith) which has the following semantics: if specified, then duplicate detection performs an additional check when evaluating the block: the duplicate detector hashes the Sender field of the transaction with the CollidesWith field and first checks if this hash image has appeared in the MaxTxnLife previous blocks (in addition to checking the transaction's ID). (Hashing the Sender in prevents a malicious user from blocking another user's transaction by setting CollidesWith adversarially.)

[tsachiherman]

Interesting. I can think of two variation of the above feature -

• inclusion ( include a transaction iff we have another transaction with a given hash in the current block or the past x block )
• exclusion ( don't include a transaction if we have had the other transaction with a given hash in the current block or the past x block )

As Derek mention above, we might not want this feature for all transaction. Maybe we can mark a transaction for potentially being updated later on ? ( for the fee updates )