I finally found some time to learn basics of IRC protocol. Thanks to it, I implemented IRC peer lookup mechanism into Stratum server. See node.get_peers() method...

I just implemented support for specifying vendor in the RPC method name, in the form "some.service[vendor].method".

Longer answer, especially for potential service developers:
Stratum is designed in the way that one service may be provided by many independent vendors. As an example, every exchange provides only market quote which is actively traded there, obviously. In this case, Stratum server operator or even exchange itself can implement the service for broadcasting their quotes and let the client choose the vendor from which he wants to receive quotes.

1. There's already discovery service, which provides listing of available vendors for some specified service: discovery.list_vendors('exchange.quotes') may return ['mtgox.com', 'tradehill.com']

2. Listing of two vendors means that there are two implementations of ExchangeQuotesService (located in server_repository in current server implementation), which provides the same service API for both independent sites (mtgox provides websocket, tradehill only polling?). Those two classes may contain completely independent implementation, but acts as the same service for Stratum client.

3. Client wants to receive quotes from mtgox, so he call exchange.quotes[mtgox.com].subscribe('usd'), which tell Stratum server to start broadcasting USD quotes from mtgox service implementation. If the client wants to receive tradehill quotes instead, he call exchange.quotes[tradehill.com].subscribe('usd') instead, but he don't need to care that internal implementation is different.

Edit: When brackets with requested vendor aren't specified, Stratum will use default service for given service type (default service class is marked as default=True). In the example above, it could be bitcoincharts.com as general provider of all quotes (although using specific vendor binding have some benefits, bitcoincharts is just another layer which can be down or overloaded, like during yesterday peaks on mtgox).

Thanks for suggestion, I think it's good compromise - add timestamp of signing into the message, but use it just as an additional information and don't force clients to throw away messages with old timestamps. In this case client can decide if he cares about timestamp of signature generation or not.


Well, I feel this isn't the responsibility of the protocol itself, it's more about design of exposed service. As an example, one service can provide simple method for retrieving actual information and second method accepting some range specification as an input for providing historical data. Of course that response of such method with composite result will be signed only once. I think that don't include some extended algorithms to the protocol for solving edge cases is going exactly in the KISS way.

Edit: Timestamp is the part of signed message again, in enlightened form than original implementation.

Yes, the codebase is completely different. Originally I started this project as a part of Electrum client, but then realize that it has some bigger potential than be just a backend for one particular client, so I rename it to Stratum not confuse people. Currently it shares the motivation with Electrum server and I'm also going to use same compontents for the initial implementation like Abe for blockchain indexing, but other things are different. Btw thanks for pointing me to "electrum-server", I fixed the typo :-).


Thanks, I'm simply not smart enough to write complicate code .

I'm proud to announce first instance of Stratum server on stratum.bitcoin.cz, ports 3333 (TCP transport) and 8001 (HTTP transport). Although there's not a documentation about exposed services, some samples in client.py and client2.py together with source codes in /server_repository/ directory may be useful for hardcore hackers.

In the near future I'll configure Nginx to handle HTTP transport on port 80 and add SSL certificate to enable HTTP transport over SSL on port 443, but this should be enough as a playground for some interested parties.

Almost everything on the protocol level is implemented and I'm interested in any feedback, especially in using the HTTP Poll and Push transports.

I updated Google document witch chapter describing HTTP Poll / Push transports. Any suggestions?

I'm also thinking about HTTP Long-polling transport (it's actually blocking extension of HTTP Poll transport, which enable realtime communication from server to client over HTTP without any need of polling or callback URL), but I want to provide long polling over the same connection, so I need to test HTTP pipelining firstly. In the theory HTTP pipelining should be working already in the Stratum implementation, but not so much client libraries support that...

ripper234, you were interested in implementing Stratum client library in Java with HTTP transport. Is current specification detailed enough for finish the job from your side? Everything is already implemented and commited into the Git so it should be very easy to install and run locally, but I'll provide Stratum instance today or tomorrow for more comfortable development.

jetmine, thanks for inputs. Quick answer:


Signing will be probably necessary only for some type of messages so the speed of verifying on the client won't be crucial. I decided to implement ECDSA signatures because ECDSA library will be presented on the client anyway for signing transactions, which eliminate yet another dependency.


Actually I did the oposite, I added timestamp into the signed data, to protect system against replay attacks. However now I'm rethinking the concept, as the same request should lead into the same result, at any time. Those APIs where replay attack is potentially dangerous should add timestamp as the part of the request (signature is created from both request and response).

So - thanks for suggestion!


This can be doable with some type of messages even with timestamp in the current implementation, for messages like market quotes.

Quick performance test of Stratum server implementation on my Asus EEE netbook:

TCP transport: cca 450 rq/s
HTTP transport: cca 130 rq/s

Every request is one roundtrip, including serialization and deserialization of request/response in testing client, so server part itself is at least 2x faster. However the overhead of HTTP layer is significant, as I expected. I compared those numbers with bitcoind's RPC (getblockcount, which is basically blank RPC request): ~100 rq/s.

Asus EEE is lowend machine and this test is calling RPC method in serial, so the test is far from real-world use, but I'm expecting at least 2x higher performance of this test per CPU core on standard server machine.

Excellent, thanks!

ckolivas, if I'm reading source code correctly, only "data" and "target" fields are necessary in getwork request, right? The rest can be calculated directly by the miner.

I also see that you're requesting 128 bytes of "data", although only first 80 bytes is really used for hashing. Can you please modify the miner that 80 bytes (160 chars in hex in getwork stream) will be enough for hashing? I'm working on some pool update and found that both poclbm and phoenix will work with 80 bytes in data already, but I would like to support your miner with this extension as well...

Actually it's not a bad idea. But in the real world, this will be still highly approximate for shorter rounds (don't forget that there are still people with <10Mhash/s, so they'll see "0 Mhash/s" for most of the rounds. And when users are OK with some hashrate delay, why not to use average for last 10 rounds, which is very exact?

Well, people are asking for actual hashrate very often and I feel that I should resolve this somehow. At this moment I'm thinking about new pool core implementing Stratum mining interface and also some extended features which I'm missing. As I see, providing actual hashrate should have some priority on checklist.

I'm affraid that such change will break DaCoinMinster's Greasemonkey script. Parsing comments isn't possible in chrome?

I'm not working personally on that, but friend of mine is. However I don't know actual status of his project...

Yes, signing and relaying (proxying) signed messages is already possible, exactly for transmitting messages like exchange rates.

I agree that such negotiation can turn into pretty complicated thing. However, at this moment, at least me and deepbit is trying to include as much free transactions as possible, for marketing purposes ("Bitcoin is providing free transactions").

Basic idea is to measure the relation between fees in transactions included in few last blocks and fees in pending transactions (assuming that transactions which are pending for some long time and they're not included in the blockchain have lower fees than necessary).

But I agree that some mechanism for negotiating required fees with miners would be interesting, too.

Yes, streaming of mtgox from bitcoincharts is down because of recent huge trading volume on the mtgox. I believe it will work again soon...

There's no need to reconsidering anything. TCP socket is the most elegant and optimized way to communicate over network, so I'm recommending to use TCP socket where it is possible, but I'm implementing HTTP polling, so mobile devices can work with Stratum nicely.

Method blockchain.transaction.guess_fee() is addressing exactly this. At this moment there's 0.0005 constant, but I have an algorithm for calculating recommented fee in my head already...

No, because I really hate such "extra rules" on every site. I would be very upset when I realize that changing of address lead to one day lockup of payout, especially when I'm probably changing bitcoin address for some good reason.


Yes. Pending email confirmation locks payouts until confirmed or cancelled.

[Deepbit]: No user reported me any issue with hacked email so far. Around 90% of hacks were related to MtGox issue, the rest was more about compromised computers.