Global nonces for account initialisation

[adrianbrink]

Proposal:
The hub has two nonces, a global and a local one
A new account gets initialised with the current value of the global nonce and then the global nonce gets incremented.

Benefits:

• replay protection
• state pruning

State pruning:
When an account goes to 0 (or non-relevant state) we can prune it from the state. Later we can reinitialise the same account (same private key) and still have replay protection.

This system avoids the pitfall of Ethereum, where we have a lot of empty and unused state and all nodes have to store it in their database.

[adrianbrink]

@zmanian @sunnya97 @rigelrozanski

[zmanian]

So I designed a system very much like basecoin for Fabric that used this mechanism.

So if you use int64 for the counters, it is possible but unlikely that a number would overflow. Someone might have to think about it.

If you use hashes to increment and 32 byte nonces for the counters, no one will ever have to think about the birthday bound for the rest of life of the earth

[ebuchman]

So we can currently remove accounts when they're empty, which solves the state pruning issue, but this would allow us to also re-use them again later - that's kind of neat

[adrianbrink]

So, currently, we can remove an account (an address that is controlled by a private key) from the state and add it?
When we add this account later, doesn't that reset the nonce and opens up the account to replay attacks?

[ebuchman]

The downside to this approach is you have to know your global account number before you can spend from it - this means in general it may not be possible to receive funds for the first time and spend some of them within a single block.

An alternative is to sign a block number greater than or equal to the block in which the account was created. The "block the account was created" would need to be saved with the account so this can be checked, but its more flexible than needing to know the exact global account number.

That said, if we don't bound this number above, then a user could accidentally introduce the replay issue as follows:

• account is created at block 100
• user signs with number 1000
• user empties account at block 500
• funds are sent to account at block 900 (re creating account)
• someone can now rebroadcast the old transaction with number 1000

Of course, this can only happen if the user messes up and uses a number that is too large - so the number used should be as close as possible to the block the account was created in ...

Another thing to note is that the signed number must also be included in the transaction so folks know what it is and can check (unlike the previous solution, where it can only be one thing, the global account nonce for that account).

Given that blocks are pretty fast, and there's some weirdness here, and no real savings, I'd probably actually vote for the original solution, but just wanted to type up these thoughts

[cwgoes]

Merged.