Simple replay attack protection

[Wollac]

In the current IOTA protocol, the same transaction works on Mainnet, Testnet, private Tangles or potential forks. This can be prevented in a clean way, by adding some form of network identifier to the signed part of a transaction. There are two general alternatives:

1. Introduce a new field Network ID to the Transaction Essence (e.g. as proposed in b7d0077). As the entire essence is signed, this will have the desired effect.
2. Introduce a Network ID configuration parameter. Then, each Unlock Block must hold the signature signing H(Network ID || Serialize Essence), where H corresponds to BLAKE2b-256.

Option 1 is arguably the cleaner solution as it does not use hidden configuration parameters to the signing. However, the explicit Network ID is technically redundant information and validation must assure that they are all the same.

Option 1 is arguably the cleaner solution as it does not use hidden configuration parameters to the signing. However, the explicit Network ID is technically redundant information and validation must assure that they are all the same.
Another point to consider is the type of the Network ID field (in any option):

• The Message has a uint64 parameter for a very similar effect. I was chosen to be a uint64 as it is supposed to store the hash of the descriptive Network Name (including the network version). Here, a uint64 effectively prevents random collisions of different names. (Having a uint32 and a few thousand different network names already has a significant probability of collision.)
• Should the Network ID of the Essence also contain hashes, or just an incremental counter uint8, where operators need to agree to prevent clashes?
• If the Network ID is added to the Essence, can we remove it from the Message?
• The Network ID of the Message is supposed to contain the version in order to prevent the dissemination of incompatible messages, however for the Network ID of the Essence to contain the version would be counterproductive as we'd lose support for backward compatible versions.

What combination do you prefer?

[jorgemmsilva]

I like solution 2, just not sure about the versioning part, we could keep that logic separated so that tx's are still valid in the same network, across versions.
If we want txs to be incompatible when updating the testnet or something like that, why not just change the networkID? Its the same thing in the end.
I feel that in production (mainnet) the network ID shouldn't change (and txs should always be valid, unless there is a breaking change in the protocol).

[alexsporn]

From a L1 node standpoint, doing it implicitly in the signature is better, because we save precious bytes in the ledger database and we have all the required values while verifying the signatures anyway. Same applies to #51
Especially this networkId will be equal for ALL UTXOs created in the ledger database, so should be optimized away and not stored.

The (imho small) downside is that parties implementing the signing step need to add a little bit more logic.

[samuel-rufi]

Same here: prefer option 2) as we don't have to waste extra bytes.

[luca-moser]

I prefer option 2. as to not put more data into the transaction essence, otherwise it will just be duplicated data. Ultimately I believe versioning for breaking changes re our data models will have to be handled by some combination of checking the milestone index and the new updated data types (increment the type prefixes accordingly and de/serializers). So I would even prefer to reduce the networkID to a byte.

Re networkID in the message envelope: I am actually not so sure about its purpose anymore. I believe we added this also for some kind of replay protection as you could otherwise simply disseminate messages to other networks but is this in practice really an attack vector if messages are only gossiped on solidification? Nodes should probably disconnect malicious peers sending vast amount of messages which don't solidify relatively quickly.

[alexsporn]

Depending on what we decide here, we should also probably rename the networkId in the /api/v2/info response to networkName, since there we provide the human-readable string used to calculate the networkId

[amidmm]

Doesn't make more sense if the Network ID field introduced in the TIP-0020 be outside of the Transaction Essence and next to the Payload Type?

[lzpap]

If Network ID is not part of the signed Transaction Essence it does not prevent transaction replay on other networks. The signed content or the signature method itself must commit to a specific Network ID. TIP-20 defines the former, while in the latter case Network ID would not even have to be present in the transaction, it'd be just a global config parameter.