Closed curtislacy closed 10 years ago
I'm not certain I fully understand the scope of this issue; the value of the balance on that address for SP3 is fractional, but the real unit for all SP currencies is (for lack of a better term) the Satoshi, Willet, or whole number. In this sense, even Bitcoins are represented in whole numbers (because the blockchain is read as a series of bytes) and only transformed into the usual 1.00 wBTC value on the UI/User side for ease of understanding.
If its preferred, we could convert all balance data to Satoshi/Willet/Whole numbers, and leave the rest to the UI, but otherwise, if the UI wants to use fractions (as in traditional wBTC or mBTC conversions) that should be fine as long as the appropriate conversion is done to whole numbers on the backend before use or before sending it to the backend.
Okay, if you just pull the balance from mastercoin-tools for an address, you get a float in most cases. This is fine in the case of bitcoins, mastercoins, or divisible properties like user currencies or shares. Indivisible properties are different though - If I make a property that represents a dozen eggs, it's indivisible. I can't give you half an egg. So if I send you one, and query your balance of eggs, I shouldn't see "0.00000001" - I should just see "1". This is how I'd expect it to appear in the JSON, if I was making a product that just built directly on mastercoin-tools.
Now, when we come along in the omniwallet side of things, the API handler already takes those float values and converts them to satoshis. Assuming that we've already made the fix in the previous paragraph, we're now going to try to convert the balance of "1 egg" into satoshis, which will result in reporting 100000000 eggs. That's clearly not right either, so the endpoint that packs the balances is going to have to understand the difference between divisible an dindivisible properties, and not split do a conversion in the case of indivisible properties. Then everything will look right at the Omniwallet API level.
Then, in the Omniwallet UI, the code will need to understand the concept of divisible or indivisible properties, and determine if it needs to treat the value as whole units or satoshis.
Yes, we're duplicating some effort here, but it's in order to make the various API points sane.
Ok, its starting to make sense, but I do have some clarifying points:
Right now, I've added a commit to make divisible properties show a balance to the 8th decimal place (satoshi) and indivisible properties in whole values only. Commit 5416020
Tested over several transactions e2f6c94f71282eb3c19a6cb0a94f67caab1dd59c7c5dbfb9e49f8655a83fe4e5 d94a7885f1d694c4f4fc5d8bf9d10e6925fbba4d075a08ce6ee171840b613e37 7fc6c3ba628c435c059b551c78453349de1e83cdd501ed8816888f1806b26044
Take a look at the balance on 1471EHpnJ62MDxLw96dKcNT8sWPEbHrAUe in /www/addr. The SP issued to that address looks like it was issued as 500 inseparable tokens, but then the balance on that address is { symbol: 'SP3', value: '0.000005' }. If the SP is inseparable, we should get a whole number there in the JSON.
This would require a corresponding change in omniwallet (probably here: https://github.com/mastercoin-MSC/omniwallet/blob/master/api/get_balance.py#L29), to make sure these whole values aren't converted to satoshis. Also the UI will need to display them properly, and should keep the user from sending fractions of an inseparable property.