|
It is likely this will go into 0.3.21.
|
|
|
|
A more efficient binary data protocol for this has already been implemented: http://bitcointalk.org/index.php?topic=3493.0This is what I plan to add to bitcoind, as it supports multi-mining / push mining / block broadcasting and a host of other applications. The linked implementation is usable in production already. Patches for cpuminer will be forthcoming. If you could add BDP support to poclbm, that would be great! |
|
|
|
Using the ID count is clever. Would it maybe be a good idea to either make that a class variable? For when people instantiate multiple Proxies across threads or something.
ID is unique per connection, and multiple threads / instances should use their own id counter. It is used to match query and response. |
|
|
|
The class on the wiki already supports automatic introspection and uses python's Decimal class:
[...]
How does this improve on that? I saw that you're using httplib instead of urllib. Any reasons for that?
There is a list in the source code and top post that answers these questions... |
|
|
|
See this thread for a python class that handles bitcoin's JSON-RPC, including proper decoding of JSON float-like numbers into python Decimal. |
|
|
|
When hacking JSON-RPC calls together for bitcoin, in python, a common solution appears to be using python-jsonrpc. This choice is less than optimal, for [at least] two reasons: (1) no way to use Decimal with JSON values, as is required in monetary software, and (2) does not support HTTP/1.1 persistent connections. So, I have created the python AuthServiceProxy class specifically for bitcoin users, based on the usage model of python-jsonrpc: http://yyz.us/bitcoin/authproxy.pyThis creates a python object whose methods are the JSON-RPC method calls. Example: import authproxy
import pprint
BITCOINRPC = 'http://myusername:sekritpass@127.0.0.1:8332/'
pp = pprint.PrettyPrinter(indent=4)
bitcoin = authproxy.AuthServiceProxy(BITCOINRPC)
data = bitcoin.getwork() # call bitcoin 'getwork' RPC
pp.pprint(data)
data = bitcoin.getinfo() # call bitcoin 'getinfo' RPC
pp.pprint(data)
This should be all that is needed for python programmers to use bitcoin's unique flavor of JSON-RPC over http or https. In the latter 'getinfo' case, you can see that Decimal values are properly returned, rather than floats, as recently discussed in this thread: { 'balance': Decimal('1.10000000'),
'blocks': 116260,
'connections': 48,
'difficulty': Decimal('68978.89245792'),
'errors': '',
'generate': False,
'genproclimit': 1,
'hashespersec': 0,
'keypoololdest': 1296778330,
'paytxfee': Decimal('0.01000000'),
'proxy': '',
'testnet': False,
'version': 32100}
|
|
|
|
Good one  |
|
|
|
Prove it.
Show it being done. Not theories on paper. Give me a reasonably sized data set proving it, in comparison to daily payouts when not pool hopping, with a comparable set of control data.
And then slush offered to prove it... geebus, fairuser - any response to my cheating offer? As you don't believe that pool hoping can damage pool users, there should not be a problem with that...
But then... You have your own pool. Go run it instead of trying to run ours.
So... you demand evidence of a particular cheating method. Then, when someone offers to satisfy your demands, you tell him to go away? Um, ok. |
|
|
|
Default user/password dont work in 0.8.1.
You're not really supposed to use the default name/password... |
|
|
|
Well you get more if the pool operator pays extra, like BTCMine was doing recently. |
|
|
|
FWIW, this is the python recipe, straight from Python documentation: >>> import decimal
>>> json.loads('1.1', parse_float=decimal.Decimal)
Decimal('1.1')
|
|
|
|
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. |
|
|
|
Is adding a "string mode" creating a second API ? I don't think so. This is just a switch, how can you call this a second api ?
Because it changes the data format of every number in every RPC call. |
|
|
|
There is also one reputable pool operator who's integrating the CoinCard API into his pool to automate PayPal payments. I don't know if his plans are public, so I won't mention the pool by name. hmmm.... I might have to try this with my pool. |
|
|
|
This is expected. As mentioned, sse2_64 only works on 64-bit Linux at the moment, so this high speed is not available under Windows. |
|
|
|
If you're writing a banking application in a language that doesn't support Decimal types from JSON, then you should pack up your bags and go home.
Is there a language that does produce fixed-precision from JSON? jansson (C) and python's json both produce float, from a JSON number containing "." |
|
|
|
yes, but it's 1,4Mhash/s w/ LP vs. 3,8Mhash/s w/o LP on one core E7200@3,16Mhz
I think you've got a configuration problem, because nobody else is reporting such bizarre behavior Maybe you could head over to the cpuminer thread and provide technical details sufficient for a bug report? |
|
|
|
People keep claiming that, and yet I just did YET ANOTHER google search for "banking apis", clicked through to the Open Financial Exchange standard (from Microsoft and Quicken), and what do you know! Money amounts look like floats:
Don't assume a decimal (".") implies floating point. Explanation by example: Remember the difference in SQL between a FLOAT and DECIMAL. Float is Approximate-number data type, which means that not all values in the data type range can be represented exactly. Decimal/Numeric is Fixed-Precision data type, which means that all the values in the data type range can be represented exactly with precision and scale. Anyone who deals with money demands DECIMAL-like behavior. Bitcoin's internal use of int64 for values provides that fixed-precision, DECIMAL-like behavior. Decimals (".") are common in monetary software. Floating point data types are not. |
|
|
|
The api doesn't need to be changed, we can just add an option to the command line that will specify int64 with float being the default.
Thus creating a new, second parallel API, conditionally present or absent? Ugh, no thanks. |
|
|
|
And why do I defend floats: because simple things should be simple. Using GMP/BCMATH is overkill for 98% of what bitcoin JSON-RPC users will be doing.
As an aside: Using GMP (or similar) is overkill for two big reasons: - We already link with and use OpenSSL's bignum (CBigNum), so there is no need for an additional library for Big Maths
- It's just silly to want GMP when we already handle money properly internally, as int64. The only issues present are interface issues, and you don't need to link with GMP in order to display an int64 with a decimal point somewhere in the middle.
|
|
|
|
|
Show Posts
