Quote
Actually it's 44720, sorry, didn't notice the rounding.
There are only 44720 different balances possible at the same time, for one billion coins, starting from 1, for integer balances. It's the sum of an arithmetic sequence summing to one billion.
For smallest increase 0.01, it's 447114 different balances possible at the same time, still with 1 NXT minimum balance.
Im not following, what is the signifigance of the number 44720 in regards to 1 billion? I feel dumb for not knowing, it seems like I probably should not have to ask this question There are only 44720 different balances possible at the same time, for one billion coins, starting from 1, for integer balances. It's the sum of an arithmetic sequence summing to one billion.
For smallest increase 0.01, it's 447114 different balances possible at the same time, still with 1 NXT minimum balance.
The largest n so that the sum is not larger than one billion is 44720. Therefore, there are at most 44720 different balances possible at the same time. Or 447114 for 0.01 step.
Sorry - my mistake in wording - so in your approach the account id is effectively a "transient" determined when you load an index node into memory?
I'm not sure what you're asking here. What is an 'index node'?I have an array of pairs (public key, balance index), and I sort them by first 64 bit of public key's sha256, which is an account id.
If I want to find account's public key and balance I binary search for it in this sorted array, which gives me public key and balance index.
Balance index is an index into an array of all currently existing balances.
no i think hes right, and i was wrong. you didnt quote his edit to add the blurb about merchants storing old accounts. things could get very hairy and mixed up that way.. kinda dangerous the more I think about it, to completely purge. wed have to well publicize the risk
would also have to handle the upcoming ability to transfer your effectiveBalance to lease your forging power out. Wed either have to track that as well or just make it kick back to account owner upon pruning
Accounts should be 256 bit public keys and that's it. 64 bit account numbers are a complete idiocy. would also have to handle the upcoming ability to transfer your effectiveBalance to lease your forging power out. Wed either have to track that as well or just make it kick back to account owner upon pruning
The only way to both have a secure system and finite blockchain is to make accounts 256 bit, with extra code for backward compatibility with current accounts. Which is obviously not going to happen.