Tx validity interval instead of block_hash+global validity length

[ilblackdragon]

Currently to defend against:

• tx replay attack from alternative chains (testnet, fork of mainnet),
• delay attack by validator, where tx are hoarded and then released in one swoop

We require transaction to specify block_hash for some block on the chain it needs to be applied on. We also have global validity length, which specifies maximum amount of time from given block_hash this transaction can be included.

Algorand uses different method: they require in transaction to specify an interval of block heights where transaction is considered valid.

Pros:

• Actually less bytes in tx
• More flexibility for transaction construction, as provides people both with lower bound (to make sure tx doesn't land too early) and upper bound (from tx hoarding).
  Cons:
• Doesn't give very good protection against tx from alternative chains an forks. As one can still send tx from testnet that during the same block height period or if fork of mainnet happened prior to the tx validity.
• Anything else?

Also for alternative chains, we can leverage epoch_id or few other alternatives to identify chain.

[bowenwang1996]

Also for alternative chains, we can leverage epoch_id or few other alternatives to identify chain.

If we use epoch id then it doesn't make transaction any smaller.

Doesn't give very good protection against tx from alternative chains an forks. As one can still send tx from testnet that during the same block height period or if fork of mainnet happened prior to the tx validity.

This seems pretty important to me.

[SkidanovAlex]

What problem you are trying to solve with the height intervals? You mention replay attacks at the beginning, but then (correctly) point out that height ranges doesn't solve replay attacks.

Replay attacks from the testnet can be solved by adding one byte network ID in the transactions. Replay attacks from other forks doesn't really need to be solved because it's practically a non-existent problem in a BFT-chain.

To defend against a delay attack we can include a 3-byte epoch ordinal. With half-a-day epochs it gives you 23K years until you run out of range. Thus 4 bytes gives you both a replay attack protection and the delay attack protection.

[abacabadabacaba]

I think that users should be able to specify validity period for their transactions. Maybe they need more time to sign a transaction (e.g. because they need to physically move it to some airgapped device with a private key), or they want to sign it now and release later.

If we want to save 32 bytes of transaction size, we can use signatures that allow key recovery, then we won't need to store the key. Or replace the key with some short ID (actual keys are stored in account state anyway). Also, when storing a transaction in a block, the included block hash can be replaced with the corresponding block height.

[SkidanovAlex]

Then we can include the height range and the chain ID, and that should be enough.

[ilblackdragon]

@evgenykuzyakov mentioned today that we also need tx validity from the gas side to limit how high can gas price go.

Question if we can just use height range for this?

[bowenwang1996]

we can just use height range for this

Wouldn't that result in having pretty short height range?

[SkidanovAlex]

we can just use height range for this

Wouldn't that result in having pretty short height range?

From this standpoint it will be no different than the validity interval.

[bowenwang1996]

we can just use height range for this

Wouldn't that result in having pretty short height range?

From this standpoint it will be no different than the validity interval.

I don't think it's the same thing. In the case of preparing transactions very securely (from cold storage) it will likely take some time so the interval cannot be too small (at least several hours), which is unfit for the purpose of limiting gas price.

[SkidanovAlex]

we can just use height range for this

Wouldn't that result in having pretty short height range?

From this standpoint it will be no different than the validity interval.

I don't think it's the same thing. In the case of preparing transactions very securely (from cold storage) it will likely take some time so the interval cannot be too small (at least several hours), which is unfit for the purpose of limiting gas price.

I don't think it contradicts my point that from this standpoint it is no different from the validity interval?

For the case of preparing the transaction from the cold storage, if we use validity interval, we need a large validity interval. If we use a height range, we need a long height range.

For the case of limiting gas price, if we use validity interval, we need a short validity interval. If we use a height range, we need a short height range.

From this standpoint height range is not different than the validity interval, no?

[bowenwang1996]

Oh I see what you mean. Yes that's true.