Bitcoin Forum
December 10, 2016, 04:51:07 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 [5]  All
  Print  
Author Topic: why JSON RPC values not use INT64 instead of float string?  (Read 16841 times)
BitterTea
Sr. Member
****
Offline Offline

Activity: 294



View Profile
March 31, 2011, 02:13:17 AM
 #81

If you want to operate on string, just add suffix "String" to every parameter/attribute name.

It's not a matter of what you "want" to operate on, it's a matter of the API version, and the Bitcoin version, of the user. Any code using the API would have to detect that and modify its behavior.
1481388667
Hero Member
*
Offline Offline

Posts: 1481388667

View Profile Personal Message (Offline)

Ignore
1481388667
Reply with quote  #2

1481388667
Report to moderator
There are several different types of Bitcoin clients. Header-only clients like MultiBit trust that the majority of mining power is honest for the purposes of enforcing network rules such as the 21 million BTC limit. Full clients do not trust miners in this way.
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481388667
Hero Member
*
Offline Offline

Posts: 1481388667

View Profile Personal Message (Offline)

Ignore
1481388667
Reply with quote  #2

1481388667
Report to moderator
1481388667
Hero Member
*
Offline Offline

Posts: 1481388667

View Profile Personal Message (Offline)

Ignore
1481388667
Reply with quote  #2

1481388667
Report to moderator
1481388667
Hero Member
*
Offline Offline

Posts: 1481388667

View Profile Personal Message (Offline)

Ignore
1481388667
Reply with quote  #2

1481388667
Report to moderator
jgarzik
Legendary
*
qt
Offline Offline

Activity: 1470


View Profile
March 31, 2011, 02:25:15 AM
 #82

We can use different names for parameters, like

SendCoinsString 100.00000000
Instead of
SendCoins 100.00000000

That would eleminate such problems forever.

If you want to operate on string, just add suffix "String" to every parameter/attribute name.

Which is, again, a second API to support on top of the first.  Twice bugs, twice the pain.


Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
March 31, 2011, 12:04:07 PM
 #83

Ok.... so Gavin asked me (many times before and now) for the proof that the banking/financial industry avoids floats.

HOW MANY TIMES DO I HAVE TO YELL THIS?Huh??

Of COURSE you shouldn't use floats internally (unless you are doing something trivial like adding up items in a shopping cart).

We are talking about the JSON-RPC api.  Which is an api for communicating between bitcoin and other applications, in which all values are turned into strings.

So:  what are the best practices in the banking world for representing monetary values in strings?  As far as I can tell, the answer is "write them out as decimal values and convert them to Decimal() or integer as you read in or write out."

Which is exactly what Bitcoin does, and which is what I think we should recommend to people.

How often do you get the chance to work on a potentially world-changing project?
BitterTea
Sr. Member
****
Offline Offline

Activity: 294



View Profile
March 31, 2011, 02:54:11 PM
 #84

So the difference mainly lies in that the banking world isn't using JSON to shuttle data back and forth.
ShadowOfHarbringer
Legendary
*
Offline Offline

Activity: 1470


Bringing Legendary Har® to you since 1952


View Profile
March 31, 2011, 03:28:27 PM
 #85

Ok.... so Gavin asked me (many times before and now) for the proof that the banking/financial industry avoids floats.

HOW MANY TIMES DO I HAVE TO YELL THIS?Huh??

Of COURSE you shouldn't use floats internally (unless you are doing something trivial like adding up items in a shopping cart).

We are talking about the JSON-RPC api.  Which is an api for communicating between bitcoin and other applications, in which all values are turned into strings.

Ok, my mistake.

So:  what are the best practices in the banking world for representing monetary values in strings?

Unfortunately, I do not posess this information.

error
Hero Member
*****
Offline Offline

Activity: 574



View Profile
March 31, 2011, 11:55:38 PM
 #86

So the difference mainly lies in that the banking world isn't using JSON to shuttle data back and forth.

This is the heart of the issue. JSON is very weakly typed, while much or most financial software is written in strongly typed languages.

When a weakly typed language attempts to handle JSON, that large number, with or without a decimal point, may be converted into a floating-point number by the language. So, really, it's the language losing, but we have to somehow deal with it.

15UFyv6kfWgq83Pp3yhXPr8rknv9m6581W
BitterTea
Sr. Member
****
Offline Offline

Activity: 294



View Profile
April 01, 2011, 12:04:07 AM
 #87

So the difference mainly lies in that the banking world isn't using JSON to shuttle data back and forth.

This is the heart of the issue. JSON is very weakly typed, while much or most financial software is written in strongly typed languages.

When a weakly typed language attempts to handle JSON, that large number, with or without a decimal point, may be converted into a floating-point number by the language. So, really, it's the language losing, but we have to somehow deal with it.

Then I say in the short term, we deal with JSON's quirks and leave the number as a number (which some languages may treat as a float instead of decimal), but take this into account when designing Bitcoin RPC v2.
jgarzik
Legendary
*
qt
Offline Offline

Activity: 1470


View Profile
April 01, 2011, 01:22:22 AM
 #88

FWIW, this is the python recipe, straight from Python documentation:

Code:
>>> import decimal
>>> json.loads('1.1', parse_float=decimal.Decimal)
Decimal('1.1')

Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2100



View Profile
April 01, 2011, 06:00:04 AM
 #89

Then I say in the short term, we deal with JSON's quirks and leave the number as a number (which some languages may treat as a float instead of decimal), but take this into account when designing Bitcoin RPC v2.
Exactly: https://en.bitcoin.it/wiki/Wallet_protocol

genjix
Legendary
*
expert
Offline Offline

Activity: 1232


View Profile
April 01, 2011, 10:56:42 AM
 #90

FWIW, this is the python recipe, straight from Python documentation:

Code:
>>> import decimal
>>> json.loads('1.1', parse_float=decimal.Decimal)
Decimal('1.1')


Except Python's JSON-RPC has no support for that. You have to use my (non-standard) modified version:
https://en.bitcoin.it/wiki/API_reference_%28JSON-RPC%29#Python

I prefer wherever possible that people stick with official libraries.

Bitcoin now is effectively saying that all other languages are broken therefore we won't fix our API.

Oh but there's a hack you can use to workaround... It's mostly accurate to the 8th decimal place.

Not the point!

By exposing an API which nearly all languages interpret as floats, you are expressing a statement of intent that it's fine to use floats for clients (API users). It should be passed as strings (without the decimal point preferably) that users have to explicitly cast to mutable objects. Then they realise that since these values are in INT51 strings (since we can't use large ints in JSON), they'll hopefully understand to deal with the values using ints.

You're encouraging users to deal with floats ATM. Bad practice, and shouldn't be encouraged.

I am really paranoid about leakage, and for me to even touch a float when dealing with people's money is unacceptable. On Britcoin, there's a whole system of balances and checks at every stage of the various transactions to ensure consistency to all decimal places, and I would not want to throw a spanner in the works because of a tiny rounding error (which would throw up flags and warnings everywhere). Even hearing the words round(...) is like heresy.
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
April 01, 2011, 11:58:01 AM
 #91

I am really paranoid about leakage, and for me to even touch a float when dealing with people's money is unacceptable. On Britcoin, there's a whole system of balances and checks at every stage of the various transactions to ensure consistency to all decimal places, and I would not want to throw a spanner in the works because of a tiny rounding error (which would throw up flags and warnings everywhere). Even hearing the words round(...) is like heresy.

Am I the only person here who looks at our documentation for how to use bitcoin from PHP and thinks "people are going to run away screaming" ?  See:  https://en.bitcoin.it/wiki/API_reference_(JSON-RPC)

I strongly believe you are making the common cases (simple shopping carts or "hold a bitcoin balance for a customer and let them spend it") much, much more complicated than necessary.

What do other people think?  I'd especially like to hear from people who have prior experience using PHP to implement shopping carts and other simple applications that deal with money.  Did you use BCMATH/GMP?

How often do you get the chance to work on a potentially world-changing project?
genjix
Legendary
*
expert
Offline Offline

Activity: 1232


View Profile
April 01, 2011, 12:52:59 PM
 #92

Instead of removing all of this:

https://en.bitcoin.it/w/index.php?title=PHP_developer_intro&action=historysubmit&diff=6404&oldid=5737

Maybe we should add it to the bottom of the page, with an opening paragraph about how it isn't strictly necessary, but can help avoid problems. Because I did take time to write that for people, and doubtless others will find it useful, but not everyone may wish to use it Wink
Luke-Jr
Legendary
*
expert
Offline Offline

Activity: 2100



View Profile
April 01, 2011, 03:35:06 PM
 #93

round(100000000 * amount) works fine in PHP. The new Wallet protocol will use ints properly, so this should be good enough.

jgarzik
Legendary
*
qt
Offline Offline

Activity: 1470


View Profile
April 02, 2011, 06:28:21 AM
 #94

See this thread for a python class that handles bitcoin's JSON-RPC, including proper decoding of JSON float-like numbers into python Decimal.

Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
bytemaster
Hero Member
*****
Offline Offline

Activity: 728

BitShares


View Profile WWW
May 21, 2011, 05:57:02 AM
 #95

https://en.bitcoin.it/wiki/Original_Bitcoin_client/API_Calls_list says that the sendtoaddress and sendfrom "rounds to the nearest 0.01"   

I am guessing that this documentation is out of date?   Is the a new, "non original",  RPC documentation?

https://steemit.com  Blogging is the new Mining
wumpus
Hero Member
*****
qt
Offline Offline

Activity: 798

No Maps for These Territories


View Profile
May 21, 2011, 06:06:31 AM
 #96

OP is right in that financial software generally uses fixed point instead of floating point (the SQL/Python DECIMAL type). This is because you can guarantee that every picocent is accounted for, when handled correctly there will never be any loss due to precision issues.

Twitter had the same problem with their TweetIDs running out of the 53 bit range that JSON is able to represent with numbers. They opted with using strings:

http://blog.programmableweb.com/2010/10/19/the-twitter-id-shuffle-text-vs-numbers/

Bytemaster: yes, it is out of date. No rounding happens in AmountFromValue.

Bitcoin Core developer [PGP] Warning: For most, coin loss is a larger risk than coin theft. A disk can die any time. Regularly back up your wallet through FileBackup Wallet to an external storage or the (encrypted!) cloud. Use a separate offline wallet for storing larger amounts.
Pages: « 1 2 3 4 [5]  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!