As far as I see binary division and float are basically the same problem. Float after all is only an implementation of binary. A float with 12 bits plus ?? bits of exponent is going to have the same issues.
The balance scheme is perhaps the least complex of the suggestions so far. Everyone who has coins will need something to store their coin addresses in for the coins they own. This is likely to be at least one MD, all the balance idea does is use a MD that is already needed and place a field in it for the balance. And then simply have a network wallet for the frozen coins.
To me it is more complex for the user to understand what all these 1/16 and 1/2048 and 1/4 and … they have and how do I send the guy 0.01 (a safecent) worth of a coin. Keeping a balance keeps the actual coin MDs clean with less ability to game the system and requires any attacker to create wallets to attack safe using fractions of a coin. The attacker has to spend in order to create the wallets in order to attack the system. Also recombining back to safecoin is automatic and whenever a balance amount would go over 1 coin’s worth the system give a coin from its frozen wallet, so the balance remains under 1 coin.
Split coins only requires the attacker to (temporarily) buy up coins and then split them to the max sending them to himself and cash out later on. The attacker then experiences no cost but has multiplied his attack by 4096 times or more. And in the process left the coin system in a fractured state. Only when one person owns all fractions is it possible to defracture it back to a coin.
Then there is the issue after a long time that most times most transactions will require many fractions just to spend a coin or two worth of SAFEcoin. This results in greater transaction load on the network just from normal use. Balance system ony needs one transaction for each whole coin and one for the fraction of a coin amount. (yes there maybe one more if a coin is frozen or unfrozen) This is in contrast to when most coins in circulation is fractured many times.
And the biggest issue is the fundamental principle of destroying coins when you buy PUT balance and creating coin for rewards. How does the system destroy coins when a person pays for their PUTs with a fractured coin because either thats all they have or all coins have reached the fractured state due to “microtransactions” popularity and/or attacks. The complexity mounts.
Floating point maths never satisfies the public or banking system that uses essentially a fixed-point system for keeping your bank balances (which cobol used) and now whatever language they use. And this is what the balance system would use too, so there is no rounding issues. There would be 2^62 parts to a coins and always that many with no rounding ever used.