Yes, poclbm should gracefully handle it. But also eloipool could handle it by serving out 1 in this special case and use pdiff for any higher figures. When sending the value to the client, just ceil(pdiff,1.0) it? Call it a workaround for poclbm or whatever. Or check client name for poclbm and only serve it to them. Sending 1 will cause miners to not submit, and thus not be credited for, some (tiny fraction of) shares. More problematic, poclbm does NOT send its useragent over stratum, so there is no way to identify it. |
|
|
|
especially since it can be easily compressed down to a single byte (by counting the number of zero bits). In other words, pdiff is a hack. On the contrary, bdiff is a hack. Anyhow, the point is that poclbm has this bug that affects any pool that wants to continue using the standard pdiff 1 target. |
|
|
|
https://en.bitcoin.it/wiki/DifficultyPools "often do" pdiff, but it seems bdiff is what bitcoin actually does internally. Wouldn't that make bdiff the defacto standard? Since pdiff ends up slightly higher, there's no harm done. Anything hitting the pdiff target also meets the bdiff target. But isn't bdiff the true standard? There's two different standards, but bdiff only makes sense in the context of Bitcoin because of its floating-point block target. Pdiff makes more sense for pools, miners, and blockchain-independent difficulty measurements, especially since it can be easily compressed down to a single byte (by counting the number of zero bits). I am not fully comprehending the difference you suggest between a Pdiff of some number close to 1 (but technically under it) vs. 1 vs. bdiff What difference does having Pdiff less than one vs. not? There must be some reason you'd want to do it that way, so out with it in layman's terms please.  Pdiff 1 = target 0x00000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF, or 32 zero-bits Pdiff 2 = target 0x000000007FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF, or 33 zero-bits Pdiff 4 = target 0x000000003FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF, or 34 zero-bits etc But Bitcoin stores the target in a floating-point number type with 23 bits of precision, so it truncates them: Bdiff 1 = target 0x00000000FFFF0000000000000000000000000000000000000000000000000000Bdiff 2 = target 0x000000007FFF0000000000000000000000000000000000000000000000000000Bdiff 4 = target 0x000000003FFF0000000000000000000000000000000000000000000000000000etc |
|
|
|
https://en.bitcoin.it/wiki/DifficultyPools "often do" pdiff, but it seems bdiff is what bitcoin actually does internally. Wouldn't that make bdiff the defacto standard? Since pdiff ends up slightly higher, there's no harm done. Anything hitting the pdiff target also meets the bdiff target. But isn't bdiff the true standard? There's two different standards, but bdiff only makes sense in the context of Bitcoin because of its floating-point block target. Pdiff makes more sense for pools, miners, and blockchain-independent difficulty measurements, especially since it can be easily compressed down to a single byte (by counting the number of zero bits). |
|
|
|
standard pdifficulty pdifficulty is not the standard. Not sure where you've been mining all this time, but until very recently, all pools used pdifficulty 1. In any case, Eligius is completely stratum-spec-compliant here. |
|
|
|
We're working on provisioning a new poolserver ASAP - wizkid057 has to be gone for a bit, so I'll probably be finishing it up. On a side note, I created a bugfix for the poclbm (GUIMiner) bug with stratum, but m0mchil refuses to merge the fix. If you prefer poclbm and/or stratum, you can post your complaint/encouragement here... Your pool sends a fractional difficulty below 1 and you have the nerve to say that poclbm is broken? It sends standard pdifficulty 1, as close as stratum allows approximating it. poclbm doesn't send any shares meeting the difficulty set as it should per the stratum protocol, so yes, it is broken. |
|
|
|
We're working on provisioning a new poolserver ASAP - wizkid057 has to be gone for a bit, so I'll probably be finishing it up. On a side note, I created a bugfix for the poclbm (GUIMiner) bug with stratum, but m0mchil refuses to merge the fix. If you prefer poclbm and/or stratum, you can post your complaint/encouragement here... |
|
|
|
i get tons of HW on my 5 ztex boards  New with version 3.0.2? What version did you not have them with? im running 3.0.2 That doesn't answer my question at all. What version did not have the "tons" of hw errors? oh, its first time im testing it out .. so .. Can you elaborate a bit more on what you consider "tons" of hw errors? ZTEX (and most FPGAs) are designed to have some amount of hw errors (usually 1-2%, at difficulty 1) in normal operation. |
|
|
|
• Before April 1st 2013, at least one BFL customer with a bitcointalk.org forum account established prior to the bet's opening date shall post detailed and credible photos of the device on the forum, including photos of it operating, and report its hashrate. This customer cannot be a BFL employee. So my only remaining question at this point is, was LukeJr a customer of BFL ? Yes = outcome FALSE No = outcome TRUE Yes. I won't disclose my total purchase quantity, but I will say I paid in full for more than just my Little Single. |
|
|
|
Can't wait to see pictures of future bitcoin mining rigs when these are out en masse. Hundreds of USB hubs connected to one another. (if that would even work I dont know) No way, big time miners are going to be using the blades and bigger integrated stuff. These USB things are for the small guy  |
|
|
|
The usb sticks are going to be a huge success, but we desperately need something better than bidding in the auction forum here to sell them; the last couple minutes of the last auction were a bit crazy, and many bidders got blocked out with the last second frenzy by the anti-spam settings for the forum.
Problem is, how to set this all up on a solid auction forum? We can at least have some vetting on the bidders to some extent when they take place on this forum, but as the volume of the auctions ramps up, I fear this will become an unmanageable mess.
Aren't there already dedicated bitcoin auction sites? Why not give each of them some quantity to auction off? And for the next rounds, prefer the one(s) that sell at the highest prices... |
|
|
|
I really like Eligius, but concerned that we have received no further word from Luke-Jr or WizKid. Their last post was 24+ hrs ago, and they didn't really have any useful info  Do they care? Unfortunately, I have no updates. I suspect our current server's host is at fault for at least some of these problems. We have been working on setting up a new server - originally just for testing out upgrades, but if Hetzner is going to be failboat, we may just have to move entirely. Edit: Part of the reason I suspect Hetzner is that in the process of trying to move the webserver, I am seeing a bottleneck limiting upload to like 20-30 kB/s to the new server. This is clearly way lower than we should be getting. |
|
|
|
i get tons of HW on my 5 ztex boards New with version 3.0.2? What version did you not have them with? im running 3.0.2 That doesn't answer my question at all. What version did not have the "tons" of hw errors? |
|
|
|
i get tons of HW on my 5 ztex boards New with version 3.0.2? What version did you not have them with? |
|
|
|
|
Still not having any problems myself, but wizkid057 and I are working on doing some upgrades to hopefully handle things better.
|
|
|
|
For the last day I get maaaany "rejected... <unknown-work>" errors. Hashrate down to bottom. What's going on??
same here Upgrade your miner. my miner is cgminer 3.1.0 Which has this known bug... upgrade to 3.0.1 or BFGMiner. |
|
|
|
For the last day I get maaaany "rejected... <unknown-work>" errors. Hashrate down to bottom. What's going on??
same here Upgrade your miner. |
|
|
|
|
Mining been working fine for me all day...
|
|
|
|
Will the quantal version run on raring, or do I need to wait for a release for 13.04? You'll have to build from source for now. |
|
|
|
|
Show Posts
