So you think being polite with other people is a fairy land?

What I am saying is that if we work together rather than against each other, then we will get much further.


I was in this discussion long before you and made contributions before anyone had this in production. With every thing I didn't like I sent in a suggestion for how to improve it. Many, if not all, of my suggestions went in the spec. Now you are telling me to fuck off, because I don't contribute? I think we have different opinions about what a contribution is.

I think your main concern right now is that GBT doesn't provide enough transactions. Correct? Actually that's not an issue with the protocol. If bitcoind or a pool gives you 1 or 1000 transactions is up to bitcoind or the pool, not this interface.

You may have a valid concern that bitcoind is sometimes holding a lot of transactions in the memory pool without wanting to put them in a block with getwork/getmemorypool/getblocktemplate. Maybe we should take that to a different thread?

BitMinter client is a java webstart based miner. That's pretty similar to a java applet. But I'm not sure if it is possible to access OpenCL from an applet. If you really need it to be an applet (and not web start) then perhaps you can use WebCL, but I think that's still alpha grade software.

I wouldn't recommend using the CPU for mining, even from assembly language, and much less with something else like Java or C, or even slower languages.

At this point I'm not sure I would recommend putting a lot of effort into GPU mining either, as ASICs should be out soon.

My post above was not only about one person or even one side of this. There seem to be two camps fighting rather than improving things.

When you come in late after the discussion has been going on for a long time and things have now even been implemented, you say "I'm sorry I'm so late with this. I've been busy with something else and didn't have time to look through this until now. But it seems to me that X could be done better if you do it more like Y." Notice the polite form and also not just saying that something is bad, but making suggestions on how to improve it.

You don't say "your shit sucks. Fuck this and fuck that." It's bad form and completely unnecessary.

It's unfortunate that we now have two competing standards. It's more unfortunate that another useless bitcointalk war is breaking out over it.

As usual many of the arguments are just not true, or misunderstood. "You have to send in all the transactions with every share. Think of all those bytes!" No, you don't.

When Luke-Jr made a public proposal and asked for comments, I read through it and sent in my thoughts on how it could be improved. Why didn't more people do that? Instead waiting until there are implementations in production and then finally spitting out nasty words and technical misunderstandings. That's not the way to go about things.

You have to ask yourself: Do I want to be someone with a positive attitude who finds ways to improve things and push Bitcoin forward? Or do I want to be some useless clockwinder who sabotages Bitcoin with FUD, lies and nonsense?

Trolling and spreading FUD may seem like fun. But remember that a lot of newbies who have just discovered Bitcoin come here and read all your nonsense. Also, some of us are trying to build something.

Good news, a new version of BtcMon is now available in the app store, now with BitMinter support.

BtcMon is an iphone/ipod/ipad app that lets you monitor mining pool workers and exchanges. Click the link above for more info.

bitcoind has always made a decision about which transactions to include in a block. That has nothing to do with GBT which is just a different API for getting this (and other) data out of bitcoind.

By the way, kano, if you have a suggestion for how bitcoin can be improved, you can set up a pull request on github and I'm sure the bitcoin developers will consider it.

Bitcoin now has many outstanding transactions.

You can blame it on BitMinter, or SatoshiDice or GBT or whatever.. it won't make any sense though. People are now starting to actually send a few transactions and it's not going as smoothly as we would like. That's a problem we have to solve (together).

I don't think this is any one person's fault. I am certainly not going to accept the full responsibility for transactions processing more slowly now than last year.

I would also not recommend pools to stop using bitcoind to filter out transactions. If you include one bitcoind doesn't like then your block will be rejected and you'll be losing a lot of coins.


Noone said that, that I know of anyway.

Namecoind locked up against last night. Sorry for slow payments again.

I will set up an automated system to kill and restart it when it stops working, later today.

Some pools are considering removing namecoins. It starts to look tempting the way namecoind crashes every day and the namecoin developers not really doing anything anymore.

Not sure why you come here demanding an explanation from me when BitMinter has the biggest block currently on the frontpage of blockchain.info. Height 205802 with 634 transactions. Maybe you are trolling again?

BitMinter is still including all transactions suggested for the block by bitcoind. We don't have any limit on the number of free transactions as I understand some other pools have. Although the pool was losing all donations for a while due to the frequency of orphans, I never put in any limits despite the possibility that it would have sped up block propagation and reduced the orphan rate.

50BTC just had a block with 34 transactions. Why 34 and not 4000-5000? For an explanation of that you can read the bitcoin sourcode.

What's the problem with using getblocktemplate for merged mining? I think that should work.

I agree namecoin seems dead, though. I wish they would at least fix the bugs they have that were fixed in bitcoin long ago.

Thanks, useful info. I'll probably just copy that behavior.

I use the "slightly below 1" difficulty, like most pools. I guess I did that because everyone else did. 

But I'll be using correct difficulty 1 now after adding var diff support.

Last night namecoind locked up again. This caused us to lose a few namecoin blocks and the payment processor got stuck trying to run namecoin payments so it also didn't do bitcoin payments for a while. Bitcoins went out again as soon as I got namecoind restarted. Looks like we had this issue for about 3 hours. Sorry for the delay.


So when using Stratum how often do you request new work to make sure new transactions get included quickly? Or is it the server's responsibility to push out work with a new merkletree when it has new transactions?


Thanks, much appreciated, guys.

So far everything seems to be running smoothly. Difficulty seems to be selected appropriately and mining credited correctly, hashrate reported in completed shifts including both main and test port. Many will have a hashrate between two difficulties and it will jump up and down a bit, but that's not really a problem.

One thought to prevent a huge difficulty for a big mining operation on a single worker account: if the max difficulty the server will give out is the one that is appropriate for a 1.5 TH/s rig then adding multiple such rigs will not affect the difficulty. That should solve it for the 1.5+ TH/s miners at least.

Read what I wrote again, please. This is an idea for how I would implement work generation with GBT and Stratum. It's not something I am already doing. I also said that I won't do it if you can tell me why reusing work with ntime rolled in sync with the clock is harmful.

So grab work every minute and get a 60 times speedup instead of 600. That's still pretty good. Or how often you feel is necessary to not avoid transactions.


Please go back and read what I actually wrote. I don't know how you get from "update ntime in sync with the clock" to "ntime is 1 hour out of sync with the clock".

I tell you how you can save CPU time by producing fewer merkletrees. You reply trying to teach me how merkletrees are calculated. I tell you that you can roll ntime in sync with the clock. You reply that this is bad because ntime will be out of sync with the clock.

You're just trolling, right?

I understand what you guys are saying. Of course I know what an extranonce is. How do you think I managed to write a pool server and miner?

I was telling you there is a fast way and a slow way to do this. And no, of course you don't have to deviate from actual time to roll ntime. How does a clock work? It doesn't stand still. It rolls forward one second per second.

You can generate work for the first second after a block change. For all the other seconds up till the next block change you just roll ntime 1 step forward and reuse all that work data.

Assuming 10 minute block changes you generate work for 1 second and reuse it for 599 seconds. You just saved 99.83% of the CPU power needed for work generation.

Since you are sending in multiple proofs of work with the exact same first sha-256 chunk it also makes midstate optimizations possible on the server side.

All this while delivering a more accurate ntime than ever before.


This information is more interesting. So you'll probably be ok whichever way you do this. I'm sure most mining rigs will also be able to deal, even if they use 600 times the necessary effort to generate work. Maybe not a raspberry pi driving several 1.5 TH/s rigs, but most will be ok.

But all that aside, when I already have rollntime working and doing what I outlined above really doesn't cost me any extra effort to implement, why shouldn't I do so? Everything else being equal, when you can choose between a fast and a slow implementation, do you really choose the slow one?

If you can tell me why this is harmful in some way, then I won't do it. But "just do like me" or "you have to use the extranonce" doesn't cut it, sorry. I also never understood why other pools don't want to roll ntime on the server side. This is why we barely noticed a 1.5 TH/s GPUMAX lease, while that would be a struggle for many pools. A holier-than-thou attitude about ntime doesn't help when your server is burning.

With Stratum and GBT rolling ntime is up to you. I'll do it in my miner, because it's smart to do.

While rollntime is of course a hack it does have some nice properties. You can generate more work using the same merkletree and the server can verify more proofs of work using the same midstate. So even for a miner generating its own work (using GBT or Stratum), if it uses rollntime it can improve the performance of both client and server.

By the way, for those testing on port 9000, an easy way to see that everything works despite not all the hashrate displays on the website including the test port: look at the "shifts" display in the lower right of the livestats. If you move some hashpower from port 8332 to port 9000 and the shifts still show the same hashrate (and probably score unless the pool hashrate changes much), then everything is OK.

Only smallish miners on 9000 right now (getting diff 1 and 2). We'll need some bigger ones to test too, please.

So if this 1.5 TH/s rig is mining on a pool with merged mining that has block changes on average every 5 minutes, it would need 10 requests per block change to get work with getwork, but only 1 request with GBT or Stratum. But since GBT transfers more data, the 10 getwork requests may be less bandwidth than the 1 GBT request.

But with 15 TH/s the 100 getwork requests are probably less efficient than 1 GBT request.


I'm not sure this will reduce stales. I also think some miners with crappy home routers will have problems with this. Some of those routers do NAT but silently stop forwarding packets if the connection was idle for 5 minutes or in some cases even less. Maybe Stratum has a ping type of command to keep things moving, though?

Of course getwork has its problems, but I'm not sure if HTTP is one of them.


Yeah, GBT uses more bandwidth than Stratum. It also has more possibilities than Stratum, but I guess it is a moot point so far since no miners take advantage of them.

Stratum and GBT will be better at getting work than getwork with rollntime. Rollntime was already a big improvement, Stratum and GBT will improve this a little further. But that is all.

The server already spends most of its time verifying proofs of work from miners. Unfortunately Stratum and GBT will have zero impact on this.

So we will need variable difficulty whether it is over getwork, getblocktemplate (GBT) or Stratum.

For big ASIC miners you need two things:

• More efficient work generation: rollntime (OK), GBT or Stratum (better)
• More effiicient proofs of work: higher difficulty

Next up after var diff now is GBT and Stratum. I'll probably add GBT first. I know a lot of you are using cgminer which only supports Stratum. But GBT is so much easier to add when you already have a well-tuned engine for getwork with JSON-RPC over HTTP. It makes sense to grab the low hanging fruit first.

The problem with X-Mining-Hashrate is that you can make your computer(s) send whatever value you wish.

There's a conflict of interest here. Lower difficulty means less daily variance for the miner, which most miners prefer. But lower difficulty also means higher load on the server. If all miners could choose their own difficulty then most would choose diff 1 and the pool would need many more servers, which would be rather expensive. We are doing fine on 1 server right now with difficulty 1 for everyone. But that will no longer work once ASICs are out.

I think the HHTT pool is on to something. At that pool the lower difficulty you choose the more you must pay to the pool. That said, they do look a bit expensive and it makes no sense for small miners (choose between huge fees or huge variance).

I am considering adding a perk that gives you half the difficulty you would otherwise have. It could be a very cheap one. I also thought about a perk that would allow you to choose the difficulty freely, but then a single big miner could perhaps take down a server by choosing diff 1.

Organofcorti has some nice numbers on work difficulty and the accompanying variance: http://organofcorti.blogspot.com/2012/10/71-variable-pool-difficulty.html

I guess it comes down to; how much load can the server handle and how much variance is acceptable for the miners? Any opinions on the variance part?

And yes, you can reduce difficulty by using multiple worker accounts. And if I make change it to be per user account rather than worker account, then you can just create many user accounts. I would prefer to avoid this. So I would want the "normal usage" to give a variance that is good enough. I would also prefer for small miners to be able to mine without choosing between huge fees or huge variance.