NEW VERSION 4.3.0, JUNE 30 2014I plan to move 3.10.x to stable soon, so if you're still using 3.5.x, please upgrade and report any regressions (note them as such). Human readable changelog:- URI parameter #getcbaddr to request coinbase address from bitcoind or compatible servers for solo mining.
- When running on systems with a configured Bitcoin Core server, it is automatically configured as a final failover and used for local block submission (GBT pools only) to reduce the risk of a stale block.
- bitforce: Implement some last-minute Monarch interface changes.
- zeusminer: New driver for these scrypt ASIC devices.
Full changelog:- Bugfix: zeusminer: Include config.h
- openwrt: Disable libusb via --without-libusb
- Avoid waiting for local bitcoind test if we have other pools defined already
- lowl-pci: Silence warning on big endian
- bitfury: Portability fixes, including big endian compatibility
- Bugfix: bifury: strtoll already implies native endian, no need to flip it again
- bitforce: Additional sanity checks, including ensuring our final queued count matches that seen by the device
- bitforce: Go back to ignoring race-triggered sanity check warnings for ZqX
- bitforce: Refactor FLB and queue flush sanity checks
- bitforce: Use binary FLB protocol for Monarch
- bitforce: Add bitforce_read function to deal with binary responses
- bitforce: Support for queue id based jobs
- Make work->device_id unsigned
- bitforce: Support device explicit "Scan Interval" to override hardcoded sleep times
- bitforce: Allow queued_max to exceed BITFORCE_MAX_QUEUED_MAX iff the firmware provides an explicit Queue Depth
- bitforce: Fix bitforce_chips_to_plan_for to work beyond 32 chips
- configure: Clean up zeusminer logic
- icarus: Use estimated hashes for hw errors (more accurate hashrate for devices where hw error values vary significantly from hashes performed)
- zeusminer: Bugfix: calculate work_division based on chips and cores
- Replace swabn with bswap_32mult (matching swap32yes parameters and performance)
- Bugfix: zeusminer: Correctly encode job header regardless of native endian
- zeusminer: support added for ZeusMiner scrypt ASICs
- icarus: refactoring: commenting ICARUS_INFO members
- icarus: Accept any power of two as a valid work_division
- icarus: option added for Icarus-based drivers to ignore the golden nonce during probe
- util: is_power_of_two function
- Bugfix: Display proper statline R and HW error percents for values < 1
- openwrt: Provide scrypt option
- Benchmark: Debuglog headers generated
- Bugfix: cpu: Fix scrypt CPU miner
- Bugfix: scrypt: Fix scrypt hash postprocessing for big endian
- Bugfix: scrypt: Correct endian handling in PBKDF2_SHA256_80_128
- scrypt: Add unit test for scrypt_1024_1_1_256_sp
- scrypt: Add unit tests for PBKDF2_SHA256_80_128 and salsa20_8
- Bugfix: Copy ALL the data with swap32to<native>
- Automatically add pool configured from bitcoin.conf for failover only
- Add failover_only pool flag, to avoid using it regardless of strategy
- Accept --default-config option to search and load default configuration files, even if user is specifying their own
- Use appdata_file_call to find BFGMiner config file(s)
- util: appdata_file_call and appdata_file_find_first functions
- ccan: Update to latest version (which includes floatval option support)
- Bugfix: Adapt quit function to new logging design
- Workaround GCC 4.6 initialisation bugs with BYTES_INIT
- Bugfix: Use int rather than ssize_t to type-match %d expectation
- Minor refactor of text-only mode: avoid wasting bottom line of console, and save status lines as they are replaced by log items
- Bugfix: Wake up wait_lpcurrent if its conditions for returning may have changed
- Defer determining --quit-summary default until it is needed, so hotplugged devices affect it
- Bugfix: In benchmark mode, only remove the new pools after putting them in the array, since the removal will try to remove it from the array
- Bugfix: Initialise struct pool in add_pool rather than halfway through startup
- URI parameter #getcbaddr to request coinbase address from bitcoind or compatible servers
- pool_set_uri function
- util: bytes_eq and bytes_assimilate
- Replace struct _cbscript_t with bytes_t for simplicity
- Bugfix: Parse userpass option with strchr rather than strtok to avoid usernameless passwords getting into the username field and being displayed
- Bugfix: Free old coinbase script before setting a new one
- util: upper_power_of_two_u32 function
- Avoid unnecessarily finding drivers in a loop
- lowl-pci: Never probe via -S *:all
- configure: Succeed even if the libblkmaker submodule is missing (only --with-system-libblkmaker)
- rockminer: Reset task timeout when queuing work
- rockminer: When we detect a task failure, check if we ought to grab a new work rather than resend
- rockminer: Add a time limit before resending work even outside of midtask state
- Bugfix: rockminer: Keep count of requested jobs properly
- make-release: Include ccan LICENSE symlinks as symlinks even in ZIP
- make-release: Ensure ccan licenses get included in source
- Bugfix: make-release: Correctly avoid unused parts of ccan
- make-release: Do builds with the official source release, to test that it works
- Bugfix: DevAPI: Make for_each_logical_proc work correctly
- Avoid double hashing of shares
- Create work_hash function to abstractly produce work->hash from work->data regardless of algorithm used
|
|
|
|
|
Anyone running git should note that when updating, they will need to re-run autogen.sh to pull in the latest ccan from upstream.
|
|
|
|
|
Eligius is working just fine for me FWIW.
Even to the extent that I can cleanly use the stats for testing.
|
|
|
|
Luke, I switched over to CGMiner, but one thing I think is clear, I don't think the frequency option (--set rockminer:clock=290) is working properly with BFGminer (4.2.x). When I configure frequency=290 with CGMiner, I get over 35Gh. With BFG, the best I ever got was in the 32's regardless of the frequency number.
Seems to work fine for me. Try --set rockminer:clock=200 for example, it's clearly slower. Be sure you're comparing the pool-side hashrate, since cgminer lies about it... Just in case, I did another longish comparison: http://eligius.st/~wizkid057/newstats/userstats.php/16kNKa7WUg8QAPFy8dJRv7USSu2fAG2pkW cg @290 - 3hr high: 33 Gh
cg @200 - 3hr high: 24 Gh
bfg@200 - 3hr high: 26 Gh
bfg@290 - 3hr high: 33 Gh
|
|
|
|
Hi - any chance of getting an SSL certificate for eligius.st? I would like to be able to view my balance/status over SSL, if possible. Also, it would be nice to mine over SSL if software supports this. I am happy to fund this SSL cert just let me know via PM. BFGMiner and Eloipool both support TLS (which replaced SSL), but IIRC wizkid057 didn't want to deploy it until he had checked on how much it would increase server load. Very Very strange, every 30 hours seems about right. If it was me i would be blocking all ip from China. And see if that helps mitigate the issue.
China is a big place, and has a lot of miners. |
|
|
|
...
"Burn testing" does not imply "actively mining at extended length" IMO.
It implies a brief period of testing to ensure the device works and doesn't fail within a few hours.
You better hope those legal documents which seem to imply their burn in was well above a few hours are wrong  Whether they are or aren't has no effect on me. |
|
|
|
What I want to know is what happened at BFL between 3/31/13 and 6/30/13. It took over 3 months for BFL to go from "shipping" Luke's Single to shipping my Single, and my Single was one of the first 100 ordered. During that 3 month delay I lost the potential return of my 209BTC outlay. I want to know if BFL was actively mining at extended length with first Singles. Ultimately I was only able to mine a little over 17BTC with something I spent 209BTC. There's not making positive ROI and then there's having a company steal your money outright by using your hardware while blatantly telling lies "oh we can't get it to work".  There have already been court documents to the Attorney General in which BFL openly admit to using customer devices on the EMC pool (which is owned by BFL and purchased from Josh in 2012). So your question of: I want to know if BFL was actively mining at extended length with first Singles. is confirmed as yes, in these documents in which it states: Butterfly Labs earns mining income from their burn testing of machines as well as service fees charged to Eclipse customers in part 4 (page 3) "Burn testing" does not imply "actively mining at extended length" IMO. It implies a brief period of testing to ensure the device works and doesn't fail within a few hours. |
|
|
|
If I remember the bet correctly BFL was supposed to ship their "ASICs" on or before April 1st.
Shipping doesn't consist of walking over to the other side of the building you are in to give Luke-Jr his free ASIC. lol
And that was one unit if I recall.
The context of the bet was that BFL would be shipping "en masse" which is what Josh kept claiming would happen in the never ending Two Weeks (TM) statements he kept giving. No, that's not what the bet said. |
|
|
|
What I want to know is what happened at BFL between 3/31/13 and 6/30/13. It took over 3 months for BFL to go from "shipping" Luke's Single to shipping my Single, and my Single was one of the first 100 ordered. Probably not the whole picture, but note that Little Single was the original design (square case that was later used for the 5Gh unit) and used 8 chips (IIRC) to run the 30 Gh/s. The final 30Gh unit ended up something like 2x the size using only 4 chips (again IIRC), and uses less electrical power. It probably has a longer lifetime too (the original one already died and got RMA'd a long time ago). During that 3 month delay I lost the potential return of my 209BTC outlay. While it probably doesn't help (we all still lost a lot on this downtime), we can't actually know the total loss value. Had BFL actually delivered on time, the difficulty would have skyrocketted even before the Avalons shipped... I want to know if BFL was actively mining at extended length with first Singles. Ultimately I was only able to mine a little over 17BTC with something I spent 209BTC. There's not making positive ROI and then there's having a company steal your money outright by using your hardware while blatantly telling lies "oh we can't get it to work". I don't think they were, but I don't have any evidence either. So you're not interested in the facts, just trolling.
Thanks for clarifying that; I'll stop wasting my time answering you.
I am interested in facts. Facts which you are evading to tell and you put me to search for them. It's either you or me searching; I already know the conclusion, so I don't care to take the hours looking through the thread (stupid bitcointalk won't let me download all the posts in it for some reason). If you say that the bet should have been a Win for BFL then you must know the terms for the bet. Putting me to search for them is a waste of time. If you don't know the terms for the bet then you just talked without nothing to back it up, but I am sure it's not your case. I knew the terms over a year ago when it was an active topic. I recall the conclusion (that it should have been a BFL Win), but not the details. |
|
|
|
and the shutdown randomly ( 4 - 10 hours uptime ) i get a sick ?
That's what I mean by "hang". |
|
|
|
I can't find the original terms of the bet, but please enlighten me why it should have been a Win for BFL. I'm sure it's somewhere in this forum thread. Thank you for being evasive. So you state that the bet should be a Win for BFL, but you don't want to back up the statement with anything. I won't bother searching for it (maybe k9quaint will do it), but anyone can create a shipping label anytime and can use it at a later time (like in your case) so that can't be your reason, as for actually having the unit that is off too since you claimed to have it in BFL's warehouse. So that's it everyone. Luke-Jr thinks that the bet should be a Win for BFL because they created a shipping label and they plugged his unit from their warehouse! This is his definition of having the unit. So you're not interested in the facts, just trolling. Thanks for clarifying that; I'll stop wasting my time answering you. well actually ..that is as close to actually having a unit 'on time' more or less then any I've heard....they say it is your unit and plug it in at BFL ...(take it and run with it) the other 99% did not even get that much! Actually, unfortunately not. Even for that unit, I think I waited longer than the average wait time.  |
|
|
|
i testet the latest version from BFG, i get alot of errors ( with RBOX Miner ) and shut down randomly ( 5 - 10 hours uptime )
u can see now, iam running only 22 minutes, and i get alot off errors
i tested the latest version from cgminer 4.1, no problems uptime 48+ hours
Those errors are "normal" with current R-Boxen. cgminer just doesn't report them. The hangs are fixed in git (to-be 4.3). |
|
|
|
So since the unit wasn't actually delivered to you then it's fair to say that the bet should have ended as a Lose for BFL and the one that made the Draw decision was wrong. By the terms of the bet, it actually should have been a Win for the BFL side. I can't find the original terms of the bet, but please enlighten me why it should have been a Win for BFL. I'm sure it's somewhere in this forum thread. Quote from: Miner99er on April 01, 2013, 08:21:13 AM
For this bet to be won tho, there needs to be a shipping label and/or tracking number.
Luke's reply: There is, but I'd prefer not to give the trolls my personal info. There was no shipping label at the time of the post if the unit was in BFL's warehouse. Lie again. Or there was a shipping label ready sitting right next to the unit in the warehouse. The latter (where the label physically was, I don't know - but I was given a tracking number). No shipping occurred before or on 1st April. I never claimed it did. So you claim that you received a shipping label, but the unit was hashing in BFL's warehouse? When exactly did you received your shipping label and when did your unit stopped hashing so that it could be sent to you? I received the tracking number in the same conversation as (eventually) setting up remote access to my miner. I don't recall when it was finally shipped exactly - months later due to further delays of the minirigs. P.S. If someone who I know I can trust with my privacy wants to waste their time confirming it exists as stated, I wouldn't mind sharing it with them. I just confirmed FedEx still has record of it (including at least origin, date, and destination). |
|
|
|
So since the unit wasn't actually delivered to you then it's fair to say that the bet should have ended as a Lose for BFL and the one that made the Draw decision was wrong. By the terms of the bet, it actually should have been a Win for the BFL side. Um, no. You're trying to be pedantic, but failing. Learn English: http://www.merriam-webster.com/dictionary/haveQuote from: Miner99er on April 01, 2013, 08:21:13 AM
For this bet to be won tho, there needs to be a shipping label and/or tracking number.
Luke's reply: There is, but I'd prefer not to give the trolls my personal info. There was no shipping label at the time of the post if the unit was in BFL's warehouse. Lie again. Or there was a shipping label ready sitting right next to the unit in the warehouse. The latter (where the label physically was, I don't know - but I was given a tracking number). No shipping occurred before or on 1st April. I never claimed it did. |
|
|
|
You claimed you had your ASIC device. You claimed you had a shipping label and tracking number for the device Both of which were true. Of course both are true, but tell us how close were you to the actual miner at the time of the post. Have you actually touched it or it was at BFL warehouse at the time of the post? I may have touched it a few weeks earlier when I was there in person, but it was being hosted by BFL until the rest of my order was ready. Where they had it physically located (their warehouse, office, or whatever) I don't know/care. BFL stood to gain 1000 BTC (now worth roughly $600,000) if they could claim the device had shipped by April 1st. I don't know anything about that. But to use present-day valuation for something that occurred in the past is ridiculous. You didn't know anything about the bet, but you posted right before the deadline? Please allow me to NOT believe that. I don't know anything about BFL having a stake in the bet, even to date (it's long enough ago that it's possible someone told me and I forgot). I don't think I'd seen the bet until after my post, either. I posted when BFL turned over my miner. Furthermore, nobody won the bet. It was called a draw. So even if BFL had made bets on their own delivery, they lost what their winnings would have been, they didn't gain. And 1000BTC is 1000BTC no matter the exchange rate. Yes, but 1000 BTC is not $600,000 no matter the exchange rate. Pretending it had today's value is what is ridiculous. |
|
|
|
You claimed you had your ASIC device. You claimed you had a shipping label and tracking number for the device Both of which were true. but declined to show either of them. I showed the device. I didn't show the tracking number for reasons I stated. Somehow you manage to reconcile those two statements with BFL not shipping the device (thus no tracking number or label) and you not having the device (because it was still at BFL). Don't forget the context of the tracking number/label bit. I was responding to pedantry with pedantry. BFL was paying you at the time to develop the mining software. Are you claiming I said that too, or are you just stating random rumours from people who wouldn't know as if they are truth? BFL stood to gain 1000 BTC (now worth roughly $600,000) if they could claim the device had shipped by April 1st. I don't know anything about that. But to use present-day valuation for something that occurred in the past is ridiculous. That is why you have no credibility on the subject of BFL. It has already been demonstrated that you are willing to deceive if the stakes are high enough. What stakes? I gained absolutely nothing from your so-called "deception" (where I stated only the truth). Edit: Also, I'm curious what stakes you think there are in this thread? I don't see any stakes for anyone... |
|
|
|
Great, at least this time you quoted what I actually said. You will note that at no point did I say BFL had actually shipped it (at the time). |
|
|
|
Sorry Luke.You burned your credibility when you claimed BFL shipped you product oh so long ago, when in fact it was sitting at BFL labs the whole time. Don't put words in my mouth, thanks. |
|
|
|
I didn't know Luke was on this forum. I do remember what the crew used to refer to him as and pretty sure Bruce can confirm. When he wasn't around they called him Chupacabra. I can't help it! Those goats just look so delicious! Mmm! I'm not trying to be mean all just stating facts of what I know from working at the plant. Nah, sounds much more likely that your goal is neither. You're not trying to be mean. But you're also not stating facts. What you're really trying to do is stir up fights. I'm not falling for it. |
|
|
|
|
Show Posts
