Prevent replay attacks with Update proposals

[nc6]

Update proposals are subject to a potential replay attack where:

• A proposal is rejected (and thus removed from the set of active proposals) without a subsequent/contrary proposal being accepted (and thus bumping the protocol/application version in question).

This is not an especially harmful replay, since it can only be replayed once every 10,000 slots (the update proposal TTL on mainnet). We could prevent it by storing rejected proposals until a new proposal is accepted, at the cost of carrying some extra state around.

[dcoutts]

Our tentative consensus is that though this is clearly a design flaw in the original system, it is not a serious security threat because it only allows replay of rejected proposals (& corresponding votes), and only every 10k slots, and only until the end of the Byron era.

So our tentative plan is to analyse this further to confirm or refute our analysis, and not implement any further mitigation, and live with the possibility of very slow replays of rejected proposals.

By contrast, the Shelley ledger has a comprehensive replay attack prevention mechanism, using the UTxO. In Shelley everything is a transaction, and all transactions must consume at least one UTxO entry. Certificates, update proposals, votes etc are all embedded within transactions.

[kevinhammond]

Seems reasonable. What’s the time period for 10k slots?