In RFC-0313, an algorithm is specified for determining when a validator node's shard key is reassigned (the terminology used is shuffled, but that's not quite what happens). In particular, if a node's public key is V, then for a given epoch and a fixed ShufflePeriod, the node's shard key is reassigned if and only if the modular equivalence V + epoch mod ShufflePeriod == 0. This ensures that a node's shard key is reassigned precisely once per ShufflePeriod, but with the assumed design goal that the alignment of this reassignment is uniformly distributed across nodes in a manner that nodes should not be able to control.

However, the design means nodes can manipulate their reassignment alignment. Because ShufflePeriod is small, and because the modular equivalence is independent of chain and validator set state, a node can trivially generate its public key V by brute force to set its alignment prior to registration. This is almost certainly not desirable.

One alternative design is to uniformly sample and fix a hash function H, and use the equivalence test H(V, B) + epoch mod ShufflePeriod == 0, where B is the hash of the block where the registration of V occurs. This shifts control of the alignment from the node to the block producer and, in the absence of influence at that level, ensures that alignment is uniformly distributed.

It looks like the RFC's use a multitude of different date formats.
I have spotted: MMDDYY, DDMMYY, DD Month YY etc.
We need to pick one and update all dates to the specified one

Discussion in #101 included in a suggestion to include comparative performance data in range proof RFC-0181. That PR was merged without this addition in order to better assist reviewers in an ongoing audit, but it would still be useful to include.

Adding this here, so it's not forgotten:

#48 (comment)

The one-sided payment example in RFC-0204 is out of date. It references the use of RFC-0180 Bulletproof range proof rewinding. In addition to Bulletproofs being superseded by Bulletproofs+ for range proving and mask recovery, value communication is now done using a separate encryption.

This should be changed to reflect the work-in-progress PR for Bulletproofs+ range proving.

In this RFC, the FTL section has this statement:

The FTL is calculated as (T*N)/20 with T and N defined as: T: Target time - This is the ideal time that should pass between blocks that have been mined. N: Block window - This is the number of blocks used when calculating difficulty adjustment

I'd like to know what the basis is for this being the ideal time. It is currently 9 minutes, which is 4.5 blocks, which would mean that N is 90, which seems ok, so I would want to know where the formula comes from

Therefore, the threshold for moving from this stage to Stage 3, STAGE_TWO_THRESHOLD_BALANCE is relatively low; somewhere in the region of 10to50.

What are the units of 10to50

Possibly the Dollar sign is converting this to latex

The emoji id for a wallet should not change when a restore is done. If the seed words are removed, then the restored wallet will have a different emoji id.

I suggest storing the secret key for the emoji id in stage 1b, or at least mentioning that it should be explicitly removed

In RFC-0313, validator node registration binds a locked UTXO to a validator node public key through the use of a Schnorr signature, with the intent that the node operator signals its willingness to participate as a validator node.

Because this signature only binds the UTXO commitment and not an epoch, block producers can influence if and when the registration takes effect, as long as the registration transaction remains valid. It should be asserted that this is intended behavior.

in https://rfc.tari.com/RFC-0313_VNRegistration.html#validator-node-set-definition

The function get_vn_set(ϵstart,ϵend)→S⃗  that returns an ordered vector S⃗  of VN_Shard_Keys that are registered for the epoch ϵn. As all UTXOs are already ordered in the base layer, we can rely on deterministic ordering based on order the registration [UTXO](https://rfc.tari.com/Glossary.html#unspent-transaction-outputs)s are placed in the blockchain.

This should read "The order is based on the VN_Shard_Key"

Under blocks

* each [transaction input](https://rfc.tari.com/Glossary.html#transaction) MUST:

  * spend an existing valid [UTXO](https://rfc.tari.com/Glossary.html#unspent-transaction-outputs)
 * have a maturity greater than the current block height
  * be in a canonical order (see [Transaction ordering](https://rfc.tari.com/RFC-0120_Consensus.html#transaction-ordering)

The maturity check should surely be in the output section.

There are checks done on Tariscript that are missing

In RFC-0313, there is mixed notation. Both V and P (possibly with indexes) are used to represent validator node public keys. This should be fixed so the notation is consistent.

If a user's seed words are stored in the unencrypted database on the cloud and the user's cloud is compromised, the attacker can steal future funds because they have the seed words.

I don't have a solution right now, but potentially: making a change to remove the seed words from the unencrypted db and maybe generating new seed words for recovery.

For example, RFC 201 references the Clacks sidechain which will not be implemented