LOL We wouldn't want anyone to think that Bottlecaps were toxic.
Actually that's radioactive...
(Sort-of)
Might want to make the arrows matching the wallet icons, the curved ones... For the top icons. (Just my 2-cents. It would be easier to follow. More standardized/themed.)
Yea, those floating point values are no good for anything other than 3D and generalization. (No possible way to fix them, due to them being pre-calculated from LUTs in the CPUs and backed by LUTs in the OS's, which all have variations and quirks.)
Decimal and "format" or Currency is more reliable, unless you really need 13 decimals of sort-of precision. (I believe true 64-bit linux and OSX may use native double-double, converted to double, which is not the same as just a double answer.)
It's always math that screws us in the end...
Where possible, you get faster results if you do the multiple instead of the screwed-up division, where possible. EG, replace all /2 with *0.5, all /4 with *0.25, etc... or even x*(1/2) is faster than x/2, because the LUT for 1 is the largest and fastest, and the multiply function is 10,000x faster than division of a variable value, then the LUT of the fixed values. (Constants help there too. Acts like a custom LUT for you. Using div_2 = 0.5, div_3 =0.3333333333333333, div_4 = 0.25, etc... Then all your answers are the same on every machine. 100% Then you use them like this... if X * div_3 >= Y then...) {LUT = Look-up-table}
I like the sounds of the mentioned plan of attack for the updates. Sounds like some logically wise choices. However, for a future update, I would still like to see the suggestion of the DB separated into two parts. The archive of blocks, relevant to the last hard-coded block, which never has to be deleted, and only gets updated when the program becomes updated. And the separate self-repairing "new blocks", that would be the only portion we would have to delete, in the event of failure to self-repair when trying to connect to a larger block-height. Since the programs seem to choke and keep us mining on the wrong chain.
Actually, we only need the last tallest block to mine on the correct chain. The database can be fixed at a leisure, if it just got the last block hash of the tallest chain that others have already confirmed as valid. Might want to look into that idea first.
EG, I have block 85000 but the tallest chain that 3 more have confirmed was block 85150... Just give me that block, and let me build off that. WHEN the wallet fixes itself, now that it knows it is forked, it will end-up showing my block that I found 85151... eventually... as opposed to keeping us mining on the smaller chain, mining block 85001, which it KNOWS will be an orphan anyways.
That would put your wallet/system above and beyond what any other wallet/system offers...
Poll
