Topic: Bitcoin Binary Data Protocol, for mining, monitorblocks, etc. (Read 26077 times)

Yes, it can work for ASICs just fine.

stratum is just another mining protocol.  You may modify the protocol to support stratum-like work, yes.

bump, I have the same question about Stratum.

Would this support ASIC miners(stratum)

?

pushpool support moved to this thread: http://forum.bitcoin.org/index.php?topic=8707.0

I can't compile pushpool in Debian.

"configure: error: Missing required libevent"

But I do have libevent.
# locate libevent                                                                                                     
/usr/lib/libevent-1.1.so.1
/usr/lib/libevent-1.1a.so.1
/usr/lib/libevent-1.3b.so.1
/usr/lib/libevent-1.3d.so.1
/usr/lib/libevent-1.3e.so.1
/usr/lib/libevent-1.3e.so.1.0.3
/usr/lib/libevent.so.1
/usr/lib/libeventdb.a
/usr/lib/libeventdb.so
/usr/lib/libeventdb.so.2
/usr/lib/libeventdb.so.2.0.0

# dpkg -l|egrep -i libevent
ii  libev-libevent-dev                3.43-1.1                   libevent event loop compatibility wrapper for libev
ii  libev3                            3.43-1.1                   high-performance event loop library modelled after libevent
ii  libevent-perl                     1.11-1                     Generic Perl event loop
ii  libevent-rpc-perl                 1.00-1                     Event based transparent Client/Server RPC framework
ii  libevent1                         1.3e-3                     An asynchronous event notification library
ii  libeventdb-dev                    0.90-4                     library that provides access to gpe-calendar data [development
ii  libeventdb2                       0.90-4                     library that provides access to gpe-calendar data [runtime]

Any ideas ?

I second this.

I'm working to package pushpool from @jgarzik

* if somebody know how compile it in ubuntu or debian, please comment here:
   https://bitcointalksearch.org/topic/m.115320
* can you suggest one short description.
* can you suggest one full description.

read more about not oficial debian/ubuntu packages:
https://bitcointalksearch.org/topic/not-oficial-bitcoin-apps-debianubuntu-packages-2207

Greeting's.

Version 0.4 released, a bugfix release.

See top post for tarball and git URLs.

Version 0.3 released, with support for mysql, postgres and sqlite databases, for both share logging and password checking.

pushpool git repo is now live at https://github.com/jgarzik/pushpool

What is occasionally?  Once a day?

Hi,

Occasionally, poclbm is throwing the following when connected to pushpoold:
Traceback (most recent call last):
  File "/home/bitcoin/src/poclbm/BitcoinMiner.py", line 141, in mine
    self.sendResult(self.resultQueue.get(False))
  File "/home/bitcoin/src/poclbm/BitcoinMiner.py", line 166, in sendResult
    d = result['work']['data']
TypeError: 'NoneType' object is unsubscriptable
Traceback (most recent call last):
  File "/home/bitcoin/src/poclbm/BitcoinMiner.py", line 141, in mine
    self.sendResult(self.resultQueue.get(False))
  File "/home/bitcoin/src/poclbm/BitcoinMiner.py", line 166, in sendResult
    d = result['work']['data']
TypeError: 'NoneType' object is unsubscriptable

But poclbm works fine via local bitcoind or via the commercial pools. Have you encountered this yet.

Hmm, I am going by the spec here:
http://deepbit.net/longpolling.php
3) Miner starts a request to long polling URL with GET method and same basic authorization as on main connection.
This request is not answered by server until new block is found by bitcoin network. The answer is the same as getwork on the main connection.
So by that reading, there is no need for an actual GETWORK JSON payload on the long poll URL as the response is assumed to be a getwork. Looking at poclbm, it's just sending get without any post data. Is this wrong behaviour?

For the moment, email to [email protected]


Already fixed in local git


A GET request without a JSON payload is a bad request   What is your preferred behavior?

Hi again,
Ok I had to fix LP in pushpoold but have it working now. Are you maintaining this on github? If so, I can feed you patches.
Basically:
sigusr1 is currently set to dump stats. It sets to lp_flush but then sets to dump stats later on so that needed fixing.
Also, lp was returning bad request on a regular GET request IE without a JSON payload. I hacked together a solution so calling /LP returns a GETWORK as specified in the spec I read.
I also have hacked sharelog to insert into the SQLITE3 db rather than using a logfile but that's strictly a matter of preference. I suppose the logfile is just as flexible as it could be a FIFO having the other end be a program that does whatever (postgresql/mysql).

Unfortunately, Python isn't my language or I'd have a go at the binary protocol implementation. Thought of rewriting the miner in C though if only to have it support things like --device=1,2,3,4 to run all of the miner threads in a single application instance.

Ah thanks didn't know about that bit.

Do you send SIGUSR1 to pushpoold, when a new block arrives?

pushpoold assumes you will implement your own block monitoring solution, and notify it when a new block arrives.

I know it isn't the object of pushpool's purpose but I think long polling might be broken in the current implementation. poclbm occasionally throws a stale so I used curl to test /LP and it never returns even when the block changes.

As I understand it, you're talking about using a binary protocol in bitcoin client. I (think Jgarzik too) also have in mind is the only mining protocol and hope that the miner would soon be removed from the official client. And, yes: JSON-RPC getwork protocol should remain in the official client. (May be need to separate the getwork-request from wallet-management commands for the possibility of mining on untrusted hosts).

I think the binary protocol should be used only in separate from a client miners through some JSON-binary proxy, or through connecting to the official client plugin/module, or in extreme cases can be easily separated part of the code in the official program.

If you think that the use of JSON-binary proxy is useless because of the overhead JSON, who do not disappear, there are two advantages:
1. JSON binary proxy can stand on the border of fast and low-band networks, using JSON in fast and binary protocol in the slow.
2. After receiving one getwork through JSON proxy can divide (cut nonce) it for a few miners through binary protocol. It must shows good results: https://bitcointalksearch.org/topic/m.48996
Perhaps we should think about the possibility of receiving getwork bundles trough JSON.

Changing the P2P protocol is not going to happen anytime soon for the above mentioned reasons (although I would welcome it)  because it would require a transition phase for the entire network to switch. I just mentioned it because someone asked me about it.

For the pushwork patch i think you are forgetting that only because you decide to use one over the other for speed reasons doesn't do anything. You have to make the format easy to implement since the miners do have to support it. The getwork interface must be enabled anyway so if the coders of the miners don't adopt the protocol you'll not have changed anything,  except a lot of work spent in a useless interface.