objects: update account id scheme

[hackaugusto]

closes #140

Opened the PR because the tests are green, but there is still some changes that are needed, namely the kernel is not checking the total PoW.

edit: well ... the tests that run with cargo test, turns out some tests are gated by the testing feature flag, which is great, because I thought we had no tests for the new accounts

[hackaugusto]

I pushed the latest version of the code. The tests are still not passing, I just realized that I'm computing the digest in the kernel using account id instead of account config, I also have to update the masm patching. Will follow up and hopefully fish this tomorrow.

[hackaugusto]

Changed the procedure to receive the data over the stack, so that it can be tested. This only has the cost of two additional instrucitons swapw and a movdnw.2

[hackaugusto]

Note: These types are using u64 conversion to and from their mask position! This is confusing at times, I had a few instances that tried to PoW 80bits because I used u64::from(pow) instead of pow.as_int()

[hackaugusto]

humm, it seems the tests are timing out in the CI, they are also taking longer time for me locally, around 1min to complete.

[bobbinth]

The schemes that we have been discussing (including the one implemented here) have a very serious flaw: the attacker could build a "rainbow table" of all (or many) account IDs and then as soon as a public note directed to a specific account appears on chain, they would use one of their pre-computed accounts to highjack the note.

Assuming there are $2^{60}$ possible account values, the storage required for such a rainbow table would be about $2^{64}$ bytes (8 bytes for ID + ~8 bytes for the seed). This is approximately 16M TB. Is is by no doubt a lot, but storing 1TB of data can cost as low as $10 USD/month. So, monthly storage costs of this rainbow table could be as low as $160M USD. What's worse, the attacker does not need to store the entire table - they could store just 1/1000 of it. The cost would be 160K/month, but effectively this would disrupt the network as any account would have a 1/1000 chance of being highjacked.

Building such a rainbow table (assuming some efficient GPU-based implementation) could cost anywhere between $1B and $10B USD. It is probably not something we'd worry about for the next couple of years, but beyond that, this would be a real problem.

Taken the above into account, I think ~64 bits for account ID is too little. So, one of the decisions we should make is what should be the ID size. A few preliminary thoughts:

1. Something around ~100 bits is probably enough from the security standpoint, but we might as well go higher.
2. 120 bits could be a good choice as it is high enough to be beyond any doubt and fits well into 2 field elements.
3. 128 bits could also be an option as it cleanly fits into 2 field elements.

Increasing the size of the ID would have the following implications:

1. We probably no longer need to encode PoW into the ID as even no PoW should be good enough to prevent account highjacking.
2. We may again consider encoding ticker symbol into the ID (though, not sure if this is a good idea).
3. Note metadata will need to be updated as now the sender_id will need to take up ~2 field elements.
4. Structure of assets may need to be updated. For fungible assets this may not be an issue as we have 2 "free" elements, but not quite sure what to do with non-fungible assets. We may consider changing asset format to always be 2 words - but also not sure if that's a good idea.

[hackaugusto]

closing this PR following the comment above