|
Just a note that updating Eloipool within the next week or so is critical to surviving the subsidy halving.
Previous code had 50 BTC hard-coded in the "blank" coinbase.
|
|
|
|
You're right "--fix-protocol" fixes cgminer too.  Funny thing, cause 2.9.3 was working fine the last 3 days. I use p2pool, but apparently Bitminter and Eligius (which both use GBT) in my backup pools can trigger the bug since this morning even if they aren't used. Posted a backtrace to #cgminer, hopefully it will help debug the problem. If you mine in p2pool use another p2pool node as backup. There is few public nodes open for everyone. None of those (AFAIK) support decentralized mining, though. Nor is it really practical as GBT's bandwidth use is absurd with p2pool's 10 second blocks. There's no reason to prefer p2pool over Eligius or Bitminter anyway, so long as you're decentralized mining. |
|
|
|
Coupons represent money. Money is real.
Bitcoins represent bitcoins... Bitcoins may be worth money but they represent nothing. Um, bitcoins are money. Bitcoins also represent nothing; Just like the US dollar, Euro, Canadian dollar, Australian dollar, etc... |
|
|
|
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. These sound like excellent points to bring up when slush publishes the first draft of the stratum BIP. I've been making a list of possible improvements in stratum myself. |
|
|
|
I do not see any virus warning with previous versions. Last warning that I remember was long time ago and it was about the pdcurses.dll. Can you check again? If 2.8.5 really doesn't trigger this and 2.8.6 does, I imagine it should be easy to workaround. Sorry I think I was just lucky and as you said ... I do not use much the windows version but today I was trying to check something (the stats issue with --scrypt) and I jumped from 2.6.6 to 2.9.3 / 2.8.6 and I notice the warnings. As you suggested I retested all versions from 2.8.0 to 2.8.6 and 2.9.0 to 2.9.3. See table below for the results ... | Version | Test result | | 2.6.6 | No Warnings | | 2.8.0 | Same warning as 2.9.3 | | 2.8.1 | Same warning as 2.9.3 | | 2.8.2 | Same warning as 2.9.3 | | 2.8.3 | New warning: "This is a known Trojan/Backdoor. It is recommended that you quarantine this threat." | | 2.8.4 | Same warning as 2.9.3 | | 2.8.5 | Same warning as 2.9.3 | | 2.8.6 | Warning with full description | | 2.9.0 | Same warning as 2.9.3 | | 2.9.1 | Same warning as 2.9.3 | | 2.9.2 | Same warning as 2.9.3 | | 2.9.3 | Same warning as 2.9.3 |
Can you elaborate on the 3(?) different warnings more? Maybe also figure out which was the last/first version to raise the warnings? |
|
|
|
It's not saying BFGMiner is a virus, merely that users should be aware it's installed. Since some viruses tend to bundle miner programs, this seems quite reasonable. What exactly you and ckolivas are using which causes AV software to trigger alarms? Miners can't work without those components, or it's just .exe and .dll packing method? AV software looks for miners specifically. |
|
|
|
Using latest win32 builds for bfgminer I start seeing virus warnings: Here is the warning for 2.8.6 build:  Please read the warning; I agree with it: "This is a potentially unwanted application. These are programs that computer users wish to be made aware of." It's not saying BFGMiner is a virus, merely that users should be aware it's installed. Since some viruses tend to bundle miner programs, this seems quite reasonable. I do not see any virus warning with previous versions. Last warning that I remember was long time ago and it was about the pdcurses.dll. Can you check again? If 2.8.5 really doesn't trigger this and 2.8.6 does, I imagine it should be easy to workaround. |
|
|
|
To answer the question you pose in the OP: Yes, stealing Bitcoins is illegal, and would be prosecuted everywhere there's a functioning legal system. Really? What a big assertion. EVERYWHERE there's a functioning legal system you say? Hmm... I'll go one step further: Stealing Bitcoins is illegal everywhere there has ever been a functioning legal system. How am I so sure? Because any legal system where stealing is not illegal is by definition not functioning. I presume the most common argument is going to be that there's some technicality a thief could get off on; but a system where the laws are interpreted in such a strict sense is just another kind of non-functioning brokenness. In a functioning legal system, the court doesn't care what was stolen or how it is done: just that it was stolen. |
|
|
|
|
I wonder if this crash affects BFGMiner...? (If not, then it's a simple matter of finding out which bugfix Con hasn't merged)
|
|
|
|
I'm thinking that the dynamic clocking of 2.9.2 and 2.9.3 (using the older bitstream doesn't help, still getting SICK and DEAD later on) is probably more aggressive compared to 2.9.0 and 2.9.1. I don't think SICK/DEAD can be caused by the bitstream or dynclock code. This is something around the FT232R chip; unfortunately, the only change in this that I recall between 2.9.1 and 2.9.2 was a memory corruption bug. There were no changes to the dynamic clocking besides the default frequency. |
|
|
|
Stats with --scrypt param still wrong for me in 2.9.3. Is there an issue for this open on GitHub? |
|
|
|
After 3 days of testing, I get better stability with the overclocker bitstream and 2.9.1 on my x6500s. Any chance we could bisect the SICK problem on IRC sometime?  |
|
|
|
NEW VERSION 2.9.3, NOVEMBER 16 2012I've also bumped the stable release to 2.8.6 including the two fixes relevant to the 2.8.x versions. Human readable changelog:- Many stratum bugfixes, including support for fractional difficulties.
- Fix GBT to work properly with very short expiration times.
Full changelog- Bugfix: Properly process new stratum jobs through test_work_current, even if old shares are still accepted, and copy submit_old flag correctly
- Ensure pdiff 1 is always caught regardless of bdiff precision, and ceil all other cases to ensure we never lose valid shares
- Check against a double for current pool diff.
- Support for fractional diffs and the classic just-below-1 share all FFs diff target.
- Check share target diff for best_share to be calculated when solo mining.
- Store the full stratum url information in rpc_url for correct configuration file saving.
- Put in a hack to prevent dud work from sneaking into test_work_current being seen as a new block.
- Reset the work->longpoll flag where it will affect stratum work items as well.
- Bugfix: Stratum does not guarantee notify messages every minute, so extend timeout to 2 full minutes
- Bugfix: Always honour libblkmaker time limits
- Always (debug)log when stratum template is updated by the pool
- Bugfix: When a stratum connection is interrupted, ensure all work/shares for it are considered stale
- Bugfix: clear_sock should return on socket errors
- Bugfix: Force calculation of work_difficulty since set_work_target fails to consider the pdiff<bdiff difference
- Bugfix: Minimal support for handling real difficulties from stratum server
- Bugfix: Never consider shares to be accepted if the submission response is an error
- Bugfix: Always fail scrypt detection if Stratum is chosen
|
|
|
|
Saw this on #bitcoin-dev IRC chat today: 07:59 phantomcircuit jgarzik, i actually have code to ddos the entire network
07:59 phantomcircuit it works
07:59 phantomcircuit but i run out of local port numbers before i get past about 100 peers
If I found a DoS vulnerability I wouldn't brag about it in public-- I'd tell the developers privately. And isn't testing a DoS on a production network immoral/illegal ? You cut off the end: [Thursday, November 15, 2012] [7:59:29 AM] <phantomcircuit> jgarzik, i actually have code to ddos the entire network [Thursday, November 15, 2012] [7:59:31 AM] <phantomcircuit> it works [Thursday, November 15, 2012] [7:59:44 AM] <phantomcircuit> but i run out of local port numbers before i get past about 100 peers [Thursday, November 15, 2012] [7:59:44 AM] <Luke-Jr> um [Thursday, November 15, 2012] [7:59:45 AM] <phantomcircuit> :( [Thursday, November 15, 2012] [7:59:55 AM] <Luke-Jr> you can't know it works without having DDoS'd the network -.- [Thursday, November 15, 2012] [8:00:44 AM] <phantomcircuit> Luke-Jr, well it worked against the roughly dozen bitcoin nodes i run [Thursday, November 15, 2012] [8:00:52 AM] <phantomcircuit> scale to all connectable peers In other words, he tested this on his own nodes. I presume if there was anything we could do to fix it, he'd have mentioned that in private. |
|
|
|
Also I note Luke actually makes less then 1Diff shares only send >=1Diff shares so those could have losses. It's not possible to send less than 1diff shares (except for CPU/GPU). Luke used the laziest way to fix it. A Compliant answer "Should" actually only send what the difficulty is. Perhaps it is a bit lazy, but it works. Unfortunately, since stratum is representing the target as bdiff, it is impossible for the miner to know exactly what the target is. (Admittedly, it would be possible to get a closer guess of course.) My second suggestion posted shortly after the one I am quoting lower and before Luke quoted me wondered why a client couldn't ask for or submit a higher difficulty work unit. Say the pool asked for 1.09 and your miner only uses ints why not send diff 2 shares but before you do negotiate with the server for pay based on diff 2. Still runs ints but pays more per unit and requires less network traffic. Just one of the many things GBT supports but stratum doesn't (yet?). |
|
|
|
I suppose the second addendum to the numbers was glossed over slightly. It says this:
[2] Fractional parts may be problematic, since many decimal fractions cannot be represented exactly as binary fractions.
That would seem to indicate that it is better to use Integers then decimals or other real numbers. At least since they may not get the same value that the server sends. I agree that using real numbers here is not the best idea. Unfortunately, stratum's protocol defines this as a Number represending a multiple of bdiff 1 (difficulty 1 subject to bitcoin rounding rules), which cannot reasonably represent traditional pdiff targets (which are easier to check). Additionally, EclipseMC has been using fully variable targets anyway. I expect during stratum's BIP discussions, consensus will probably determine using a target as getwork and GBT do (without these problems) is the proper solution. Actually I have an idea on how to suggest handling it I may see what Con thinks. BFGMiner handles it by truncating the difficulty (with a special case of pdiff 1 for difficulties under bdiff 1) and letting the server reject shares that it doesn't think meet its target. This results in some degree of rejected "high-hash" shares, but it guarantees no valid ones are lost. |
|
|
|
Since eclipse uses fractional difficulties and it seems they are less reliable on JSON could you accept whatever eclipse says to work on then if it has a decimal truncate it to an int and add 1? Eclipse is fully stratum/JSON/JSON-RPC compliant. Truncating it works, but you'll lose shares if you add a 1. In any case, GBT is still the preferred protocol. |
|
|
|
Cgminer doesn't seem to like that. coming up as dead. cgminer's stratum implementation is broken. I've got some fixes in BFGMiner git, but I hear Con's making excuses. Wow, I'm calling BS! Stratum works fine on Ozcoin. I'd say Stratum implementation on Eclipse is broken.. Some HTML 4 webpages work fine in MSIE 5. But that doesn't mean HTML 4 in general works fine in MSIE 5. I found Con's implementation of stratum had 3 problems with regard to working on Eclipse: - It assumes all difficulties set are integers. JSON treats all Numbers as the same type, and stratum doesn't restrict the range to integer values. Every stratum client implementation except Con's correctly handles real number difficulties. EclipseMC has an unrestricted vardiff range, and more often than not uses a real number.
- It assumes the server will send a notify (or at least some message) every 90 seconds. Stratum makes no such guarantees.
- It gives up on authorizations if a response is not received basically instantly.
Cgminer doesn't seem to like that. coming up as dead. cgminer's stratum implementation is broken. I've got some fixes in BFGMiner git, but I hear Con's making excuses. According to the wikki on Ver 2.0 id: An identifier established by the Client that MUST contain a String, Number, or NULL value if included. If it is not included it is assumed to be a notification. The value SHOULD normally not be Null [1] and Numbers SHOULD NOT contain fractional parts [2] It seems like luke-jr misunderstands what a client is. The client is CGminer. Also in no example I have found in the documentation was id anything but an integer. This doesn't mean it has to be but if every example has it being so then it seems like a precedent. It seems like id is used instead of method. Shouldn't it be like this? {"jsonrpc": "2.0", "method": "auth", "id": (whatever the client sent)} According to the Stratum Documentation. Response Every response contains following parts ◦message ID - same ID as in request, for pairing request-response together ◦result - any json-encoded result object (number, string, list, array, …) ◦error - null or list (error code, error message) While true it says that any string, number or NULL value is required, it also stated it is selected by the client. I am not 100% positive on the rest I didn't write the specs or anything. I just read them. I really don't see why a person wouldn't want authorized before they get a difficulty. As I see it and maybe I am totally wrong but I want to try stratum on EMC. Since authorize can come at any time why can't it come before subscribing? The whole "id isn't an integer" thing is presumably about how BFGMiner (the client) implements stratum authorization in git (in part to fix the problems at hand). I found every stratum server, including EclipseMC, to properly respond with the same id sent by the client. And they all send responses to commands in the order those commands were received; Con's implementation (as well as the stratum examples) requests the subscription (work and difficulty) before it authorizes - it also works fine with them coming back in the same order, as long as it's instantaneous and recognized as valid (which non-integer difficulties aren't). So, how to I use stratum on EMC?
help? I'll plan to release a BFGMiner with the fixes sometime soon... but it should be noted that GBT is still better. Obviously the stratum proxy and/or poclbm should work fine too. |
|
|
|
No, stratum isn't http. stratum+tcp://us2.eclipsemc.comCgminer doesn't seem to like that. coming up as dead. cgminer's stratum implementation is broken. I've got some fixes in BFGMiner git, but I hear Con's making excuses. |
|
|
|
There no 3 step in Florida it is merely "securely encased" meaning holstered, or inside of something with a lid you have to lift. Section 790.001(17) defines the term "securely encased" to mean "in a glove compartment, whether or not locked; snapped in a holster; in a gun case, whether or not locked; in a zippered gun case; or in a closed box or container which requires a lid or cover to be opened for access." I don't recall where in the law, but IIRC there was a problem with having it mere snapped in a holster on your body (in a vehicle) without a CCW license. |
|
|
|
|
Show Posts
