Not 100% sure what the problem was. I restarted the pool backend with different settings for the java virtual machine. May have to tweak that a bit further. Before restarting I saved a heap dump of the running backend - will analyze that today.

Anyway, it's running now with settings I have used before and it seems to be working very smoothly.

Server lagging a bit. I think that's the reason for the stales - sometimes getting slow response. Looking into it.

Not sure what caused those stales. But yes, GPUmax can give high stales, both from buying shares and sometimes also from sending your own shares through GPUmax.

That said, I have higher stales than normal right now too (0.2%). But it's only 15 stales, so it may not be significant.

If you register them yourself with a namecoind it looks like they are 0.03 NMC (0.015 name_new and 0.015 name_firstupdate). That's about 0.00012 BTC per domain. I don't think I'd use the registrar and pay 1.5 BTC if I was going to buy that many.

Nice hacking, Phantom

A couple quick updates today:

Miner 1.1.1 beta was released today as version 1.1.1 final. Most important update is supporting 7970 and other GCN cards. More details in the miner thread.

Small website update. Removed all references to TradeHill (which is shutting down) and added a miner test page at http://bitminter.com/test. Use it to test the miner on a computer without having to register or enter any name or password. Of course without this you don't get paid, so this is meant only for doing quick tests. I got the idea for this from a question on the bitcoin stackexchange.

Not sure what was the cause there. But holding on to some of that data and drawing some graphs might be useful, yeah.

Runs well on 7970 and no reports of any problems. So v1.1.1 final is now out. Changes are as described in the previous post.

Any thoughts?

There are some weaknesses in the way mining is done today, with the "getwork" json-rpc call. I'd like to suggest we create a new standard based on what Luke-jr. is working on for Eloipool. There is some code for this here: https://gitorious.org/bitcoin/eloipool/commit/fc22a5a3dee1843336f74d737b283ec3efe41533. As you can see it is basically a "getmemorypool" interface but instead of parts to create a generate transaction from, you get complete generate transaction from the server as "coinbasetxn".

I think it would be a good idea to add a "target" like "getwork" has, so that the server can control the difficulty for its clients. Also, perhaps the procedure should have a different name, since it is not the same as the "getmemorypool" of bitcoind?

What does this solve, compared to plain getwork?

• Verify which address(es) the coins are going to, so pool op cannot steal without miners knowing it
• Look for merged mining data in the coinbase, so pool op cannot secretly merged mine
• Look for "water marks" (pool name) to see where your hashes are actually going. If you are mining on pool "A" and the name of pool "B" is in the coinbase, you will know what's going on. Yes, pool "A" could pretend to be pool "B" if they wanted. But they cannot remove pool "B"s name if using work from pool "B".
• Perhaps prevent being used in 51% attacks? Bitcoin blocks will soon be required to include the block height in the coinbase, and you already have the hash for the parent block in the block header. Comparing height and parent block with a trusted source, you could see if you are building at a height lower than you should, or an unknown parent block. Only thing is, blocks take some time to become known by everyone, and there are also (non-hostile) forks. As long as the height looks ok, you'd have to cut some slack for unknown parent blocks.
• Display some of this info to the user, like height, generate payment address(es), presence of merged mining and pool names or other printable strings.
• IF server allows: Exclude transactions by whatever criteria the miner wants
• IF server allows: Add more transactions the server doesn't know
• IF server allows: Allow the miner to create its own work, thereby drastically reducing server load (server must allow modifying the coinbase, at least appending an extra nonce to it).
• IF server allows modifying coinbase: allows miner to put its own mark in the coinbase (or is that a bad thing?)

Perhaps the data from the server should also provide info on which modifications of the data will be accepted.

Obviously this is the direction Eligius is already going. I think it would be a great benefit if we can agree on a standard and get as many pool servers, proxies and miners supporting it as possible. As suggested by Luke-jr. already, if you have a proxy supporting this then you don't really need miners to support it directly. But at a minimum you need pool servers and a proxy supporting it.

Downside:

• Largish proofs of work from miners as the server must now accept entire bitcoin blocks - not just headers but a long list of transactions as well.
• Servers: Possibly heavier processing of proofs of work from miners, depending on whether you care to check that all the transactions are OK and whether you allow modifying the coinbase.
• Scammers: More difficult to scam people

Possible fix for the first two points: all the transactions could be replaced by just coinbase and its merkle branch when the data cannot create a block and the miner just needs to prove it is doing work. More efficient but it means supporting 2 ways to deliver work. And it needs an extra "target" value (because of merged mining) to determine the lowest target for which the server can create a block.

One problem I can think of is if the miner gets a transaction from a local bitcoind that is on a different fork than the server's bitcoind. In that case you might get a transaction in a block when it already exists in the parent block. But I think duplicate transactions are simply ignored and do no harm, right?

PS: Maybe this time have 2 separate RPC procedure names? Not "getwork" both for getting work and for delivering work results. Never made sense to me.

I thought the main concern was the things I listed above. But it would of course be possible to include all transactions.

Apparently Luke-jr. is already supporting this through a modified version of the "getmemorypool" json-rpc in his Eloipool server. See https://gitorious.org/bitcoin/eloipool/commit/fc22a5a3dee1843336f74d737b283ec3efe41533 Hope it's OK I promote your stuff a bit. 

The server provides the usual "getmemorypool" info with data for the block header and all the regular transactions. The modification is that the server in this case also includes a generate transaction.

If the server allows it the miner could exclude transactions (maybe you want to demand a minimum fee), or even add transactions the server hasn't seen. The server could also allow the miner to modify the coinbase, although BIP-16/17 style voting may be a bad idea if the server doesn't actually support the things the miner is "voting" for.

This would also allow the miner to create its own work, thereby drastically reducing server load. You only need a new set of data once per block change.

And it also makes possible all the checks I described above.

This seems like the more versatile option that fixes a lot of issues with mining. Can we make this a standard and get more miner and pool backend authors supporting it?

Such a list only shows what the pool op wants you to see. You can't know whether he used your hash power to generate some other blocks in secret. Or used pool hopping of prop pools to make a bigger profit. Or is secretly merged mining (ok, you can check that for the blocks he does show you).

The problem is that you can see what the pool op wants you to see. But noone can prove that this is the only mining going on. With what I suggest above the miner could instantly see all the addresses coins are being sent to, for every block it works on.

When you are mining you don't have the generation transaction. You only have the block header. So you don't know that much about what you are working on.


You make a good point.

Here's a proposal to fix it: "gentx" getwork extension.

When the miner announces support for "gentx" and the server supports it, the server will include in the getwork response the generate transaction and a merkle branch that proves this generate transaction is in the block.

Extra getwork response elements:
"gentx", usual string hex encoded format, of the whole generate transaction, usual byte sequence to represent a transaction, same way "getmemorypool" does for regular (non-generate) transactions.
"genmrkl", gentx's merkle branch, usual string hex encoded format

The miner can now:

• Verify that the coins are going to the pool's known address, so pool op cannot steal
• Look for merged mining data in the coinbase, so pool op cannot secretly merged mine
• Look for "water marks" (pool name) to see where your hashes are actually going
• Perhaps prevent being used in 51% attacks? Bitcoin blocks will soon be required to include the block height in the coinbase, and you already have the hash for the parent block in the block header. Comparing height and parent block with a trusted source, you could see if you are building at a height lower than you should, or an unknown parent block. Only thing is, blocks take some time to become known by everyone, and there are also (non-hostile) forks. As long as the height looks ok, you'd have to cut some slack for the parent block.
• Display some of this info to the user, like height, generate payment address(es), presence of merged mining and pool names or other printable strings.

Downside: some extra bytes sent in each getwork response. But hey, if miners support this they probably support "midstate" meaning you can ditch midstate and hash1, saving back some bytes again.

Hm, perhaps it could be the extrapolation. The round stats update on the page every 2 minutes. The changes in between that are extrapolated based on current hash rate.

If someone runs GPUmax and pushes the hash rate up, then later the hash rate drops suddenly when the GPUmax run is over. The extrapolation will keep showing everything moving at the same rate until the next real data comes, which could be 2 minutes later. At that point all the numbers are corrected.

For the same reason you can also sometimes see that you go from X to X+1 rejected proofs of work, then suddenly back to X.

I'm thinking of turning off extrapolation for rejects. They don't come at a steady pace anyway, just at the block changes. I'm also thinking of reducing the updates to every minute.

Hm, not sure if 2 minutes of wrong extrapolation can explain a change as big as the one you mentioned, but it's the only thing I can think of.

You should have both NMC and BTC in your account if you mined the last 5 days. Could you look in "my account" -> "transaction history" and see if it was paid out?


That sounds like things are working - thanks!


Yeah, as you can see at http://bitminter.com/stats/luck the worst so far was indeed, as you say, the 6.6 million block.

We need a much bigger pool to comfortably take this kind of block. I sure hope it ends soon.

CDF only goes down when a block is built. When that happens it should go back to zero.

I believe those first 2 numbers were the NMC CDF. That was the bug I fixed today. When we built a namecoin block this morning the CDF should have gone back to zero. Proofs of work should also have gone to zero. And the round duration should have gone back to zero seconds. But because of the bug the NMC round stats only partially reset. That's why the CDF only dropped a little.

A new version of the backend is running now, and round statistics should be resetting properly again when a new block is generated.

Version 1.1.1 beta of the BitMinter client is ready for testing:

https://bitcointalk.org/index.php?topic=31163.msg758061#msg758061

Could someone with a 7970 see if it runs ok?

P.S. Please end this block!

Version 1.1.1 beta of the BitMinter client is ready for testing:

https://bitcointalk.org/index.php?topic=31163.msg758061#msg758061

Could someone with a 7970 see if it runs ok?

v1.1.1 beta is out.

Changes:

• Improved long polling
• Cache less work, to reduce server load
• Show reason for rejected proofs of work (X-Reject-Reason getwork extension)
• Cache DNS lookups max 15 minutes (so you won't have to restart if we switch server again)
• AMD GCN support: use bitselect() for BFI_INT instead of patching
• Recognize more CPUs/GPUs. Corrected expected hash rates for some devices.

Can someone with a 7970 see how it runs? I don't have one to test it on myself.

PPLNS is similar to proportional. But instead of paying all shares submitted since the previous block was created, it pays the last N shares, regardless of block boundaries. Some shares get paid 1,2,3,4 times, some not at all.

I chose PPLNS because it is fair, safe from pool hopping, and one of the easier to understand income sharing methods.

BitMinter uses weighted and shift-based PPLNS. Weighted because we don't pay proportional to the number of shares, but the sum of their scores. A share's score is 1/difficulty. A share at low difficulty is worth more because it is more likely to create a block. Grouping shares into "shifts" makes it easier and more efficient to generate live statistics.

Now working again. Found a race condition in the resetting of round stats. Low chance of being triggered, but it was now. Working on fixing the code. Shifts and payments are unaffected, but block rounds not resetting properly can cause wrong statistics.

I had to parallelize the backend more when the first test runs with GPUmax uncovered some bottlenecks. The code is now extremely fast and efficient. The downside is that parallel code is very hard to test and debug. The codebase should stabilize now, though, as I believe it can take us well over 1000 GH/s without changes.