That did it, thanks!

That's great news! Thank you for adding support 

Thanks, Slush. Just in time for my server implementation

Apparently he changed his mind. Look in the Stratum thread. I am implementing server-side Stratum now and I'm going to have difficulty tied to work. I'll send set_difficulty before the work, unless it is the same diff as the previous work, in which case I'll skip sending set_difficulty.


That's not helping either. I'm wondering if it has to do with my formatting being different (from other Stratum pool implementations).


The strange thing is that now it tries to authorize twice, with a 10 second pause in between, then crash.

I thought that was allowed. Anyway it doesn't help changing that:

recv: {"id": 0, "method": "mining.subscribe", "params": []}
send: {"result":[["mining.notify","01"],"01020304",4],"error":null,"id":0}
recv: {"id": 1, "method": "mining.authorize", "params": ["Test_Test", "Test"]}
send: {"result":true,"error":null,"id":1}

Still crash.

Trying to implement Stratum on my pool, but cgminer crashes when I connect to the server.

This is what happens, from the server perspective:

recv: {"id": 0, "method": "mining.subscribe", "params": []}
send: {"result":[["mining.notify","1"],"",4],"error":null,"id":0}
recv: {"id": 1, "method": "mining.authorize", "params": ["Test_Test", "Test"]}
send: {"result":true,"error":null,"id":1}

Then Windows says "cgminer.exe has stopped working"

I have been thinking about making new BitMinter blocks available through the web service with long polling, to get around blocks having to go through the peer-to-peer network to reach other pools. That could also be a good way to get the necessary data to start mining before bitcoind does its checks, like you suggest. Doesn't have to be long polling, btw.

If most pools would get blocks directly from each other without going through bitcoind and if they start mining after only minimal checks like you suggest, then that might get rid of most orphans. No X number of nodes to propagate through, almost no verification = near instant block propagation as far as mining is concerned.

You are right that pools are unlikely to make invalid blocks. And you can check the previous block hash (from the block header), to ensure you don't accidentally help in a 51% attack.

Like you said, start mining after a quick check like that. Start mining a 1-tx block on top of that new block, maybe with a LP signal. Possibly you could include txes if you can be sure which ones would be valid (would take some effort). Meanwhile you can submit the block to your own bitcoind for full verification. If it checks out, start mining on top of it with full transactions. If it doesn't show as the top block in bitcoind then either it was invalid or another block got there first. Either way, start mining on whatever bitcoind says is the top block on the main chain.

Change from v1 to v2 blocks and other little things. But there's no change to how a block solution is handled and pushed out on the network. No delay there.

It may of course be that we were just incredibly unlucky with the orphans lately.

And the stale blocks are not shown by most pool at all, they throw away all stale work.


According to blockchain.info OzCoin had stales since 2012/08/24:
1 x 2012-10-18
1 x 2012-10-16
1 x 2012-10-09
2 x 2012-10-07
1 x 2012-09-15

Those don't appear on the OzCoin website. Maybe there's a bug there?

blockchain.info doesn't show the one on 2012/08/24 though. Some orphans don't propagate far enough for blockchain.info to see them. Therefore it would be hard to make orphan stats without accurate stats from each pool itself.

5 orphans in october is not so good. But zero in november is very good. If OzCoin is running with default settings then I suppose it's just good vs bad luck?

Miners are unhappy losing money. And the pool is in the red. I'm paying for the privilege of running this pool. When I run out of bitcoins, I'll have to shut the pool down.

So Deepbit, Eligius and many p2pool miners already use transaction limits below the bitcoin defaults. Probably more do as well. I think this is a good way to improve the situation until bitcoin scales better.

How do you propose to "fix the pool"? The pool is already well connected on the bitcoin peer-to-peer network. Directly connected to most pools. But if you have suggestions how we can get other pools accepting our blocks faster without reducing the amount of transactions, I'm all ears.


I guess most miners will instead avoid pools with many orphans. But this is why I want to hear opinions. If you mine on this pool and you think processing SatoshiDice transactions faster is worth losing some of your mining income, please speak up.

For comparison, what some p2pool users are using: https://bitcointalk.org/index.php?topic=18313.msg1326067#msg1326067

blockmaxsize=100000
blockminsize=0
blockprioritysize=2000
mintxfee=0.0005


Yes. The slower a block propagates through the bitcoin peer-to-peer network the higher the chance it is orphaned. That's because others will be making blocks that compete with yours because they haven't seen your block yet. And the bigger the block the longer bitcoin nodes take before accepting the block as valid and passing it on to other nodes.

So I would think that reducing the block's transactions by X kilobytes will reduce the chance of the block being orphaned by Y percent. But I can't say what X and Y are.


I haven't looked at what the SatoshiDice transactions usually carry in fees. But yes, slower processing of transactions is the downside to limiting how many transactions we include in each block.

This is unfortunate for Bitcoin. And I think it is too early for a real market-effect when it comes to processing transactions. The new coins you mint are much more valuable than any transaction fee. The incentive for a miner is to just toss all the transactions and maximize the chance of keeping those new coins. If pools did that, though, it would be a disaster for bitcoin.

So why risk our 50 BTC for an extra 0.1 BTC in fees? Because otherwise we destroy bitcoin (and the value of those 50 BTC). But we must keep this risk manageable.


I like the idea of a "market" for transactions and their fees. Giving priority to the transactions that pay us also is the way for us to make the most profit.

But blocking SatoshiDice transactions is a valid suggestion, I think. Even if we lose some (insignificant amount of) coins doing so, it means newbies can try out bitcoin and see fast transactions. The fees are so insignificant anyway. What is best for bitcoin - slowing down newbies or SatoshiDice? It may be more important to give new users a good impression of bitcoin than to support the SatoshiDice spam.

Of course the real problem is that bitcoin in its current state does not scale beyond minor usage. That's something the bitcoin devs can hopefully fix in the long run. But in the short run I need to take care of the miners in this pool and keep the pool from going bankrupt paying orphans.

Stratum is almost ready for testing.

And yes, we have had too many orphans lately.

I think it's time to start limiting the number of transactions we include in a block. It would make the blocks smaller, which would make them propagate faster through the bitcoin p2p network, and reduce their chance of being orphaned.

Our latest orphan at height 209437 had 722 transactions. I see EclipseMC also got an orphan today with 695 transactions.

Suggestions for pool transaction rules? Max X transactions per block and max Y minimum-fee transactions per block? Anyone know what other pools are doing?

It's a shame to have to limit transactions, but we can't keep throwing away money so that SatoshiDice can make money faster. Not that they are doing anything wrong by using Bitcoin, but this is how it is from our perspective.

Edit: if you want to comment on this and don't have access to post outside the newbie section, write in the BitMinter newbie thread instead: https://bitcointalk.org/index.php?topic=22432.0

Stop mining on CPU, it makes no sense.

Check out https://en.bitcoin.it/wiki/Mining_hardware_comparison

If it is the GeForce G210 you have, then you should be able to get 3.38-3.79 Mhps, which is at least faster than your CPU. If the GPU doesn't show up in the miner then perhaps it is an older GPU that doesn't support OpenCL. G210 vs 210, I don't know Nvidia models well. Either way, Nvidia GPUs are very very slow for making bitcoins, especially the older models.

But have a look at the ASICs at the URL above. Soon all GPUs will be ridiculously slow for making bitcoins. After the ASICs come out it probably won't make sense to mine on anything else.

I believe cgminer and bfgminer will have bASIC support before the devices ship.

As for BitMinter client, I will try to get remote access to a bASIC as early as possible. If I don't get this from the bASIC guys then I will probably not have a working implementation on day 1. But I probably could within a day or two.

I started a thread to get info on the new protocol that will be used to control the bASICs: https://www.btcfpga.com/forum/index.php?topic=99

If the protocol specs are released early then it means only some (hopefully short) time for debugging is needed with an actual device.

Hang in there, guys. Today 12 blocks and counting.

As long as we are talking about CSV files, they can be opened in practically anything.

Are you seeing accepted shares in cgminer, but not on website under "my account" -> "workers" ?

You are sure you are using the correct credentials in your cgminer config?

If you send me your BitMinter user name I can have a look at things on the server side. You can email me at operator@bitminter.com

Nice way to fix it without breaking current implementations. Thanks

I have read the discussion about separating target/difficulty and work data. I have to say I think this was a mistake as it opens possibilities for abuse. I think something about these issues should go in the docs. Otherwise someone is going to create a naive implementation with some nasty issues.

Issue #1: As Eleuthria mentioned miners can hold back proofs of work. Keep results that are above the target, and submit them later if the difficulty decreases. Keep results that are far below the target. Submit them later if difficulty increases, getting better pay for them. By varying your hashrate between two Stratum pools you can make the two pools raise and lower your difficulty frequently. This enables a kind of Stratum pool hopping.

You can prevent this on the server side by always following the change of difficulty with sending out new work and flushing old work. Effectively negating the separation of diff/target and work data.

Issue #2: As Kano mentioned an evil pool op can steal from you. When the miner sends in a hash that is below target but not too far below it, simply reply with "1. I'm raising the difficulty. 2. your share is rejected due to the new difficulty". This will happen naturally once in a while as there is a race condition inherent in the protocol. But as a pool op you can make it happen on purpose to steal from miners. Then reduce difficulty again, and repeat. Raising difficulty once in a while will also make the miner throw away work it was just about to send in. Lowering the difficulty again could make up for it if the miner has kept old low difficulty shares. But oops, the server is flushing old work to prevent issue #1, so they are no longer valid.

With getwork and getblocktemplate a reject due to the hash being above target means there is a bug in your miner. With Stratum it means "it could be nothing - but maybe the pool op is stealing from you."

While issue #1 is fixable, issue #2 can't be fixed 100% without changing the protocol. The best you can do is to always follow up every difficulty change with quick new work data that flush the old. This should reduce the frequency of the problem. Then just hope the miner won't tell the user too often that you are stealing.

Is it ok to pipeline commands to the client? That is, send the difficulty change and new work (2 RPC calls) in quick succession without waiting for a reply to the first.

That should at least reduce the amount of visible rejects that cause miners to think you are stealing. However it won't fix it 100% and having to flush old work to change the difficulty will also waste some hashpower.

Awesome Let me know if you see anything strange. After a block change (long poll) bfgminer sometimes says the server is issuing old work. It shouldn't, of course, but I may have a bug there.

Also, we are now making version 2 blocks. It will probably be a while before v2 blocks are required though, as 50BTC and DeepBit have not made the switch yet.

You can see the v1 to v2 transition as it happens at http://blockorigin.pfoe.be/top.php

Not the JSONRPC request id but the GBT "workid" value that is sent out with every template. The spec requires that you send it back to the pool with every block submit. Apparently Eligius and Eclipse MC don't use the workid so they don't care if it's missing. But my implementation is dependent on it as of now. I am thinking about having it search through the coinbase to figure out the workid if it is missing, though.