The 7970 crowd sourcing went pretty well, and that was for a $500+ component. A 3.5 Gh/s BFL Jalapeno is only $187 including international shipping...
You could set up an address, and when it gets to 30 BTC, order a unit.
It did indeed and I was most impressed by the community's generosity at the time. I had issues with FPGA and never wanted to invest or even develop for them because they really did not look like they'd ever pay themselves off - and indeed if ASIC really does come in any time in the next year, pretty much not one single FPGA will have made a profit before they're defunct technology and just doorstops. On the other hand I can still sell my GPUs if they become defunct technology and they've never made a loss. ASIC is a different beast entirely. They polarise the issue into one of being 100% you MUST bet on bitcoin being successful, like FPGAs, but they are very different in that they will also be the ONLY way to make a profit mining should they eventuate. Personally I don't like sending money into a black hole and hoping the universe will spit out a device in response. I'm disappointed, but not remotely surprised, by BFL's silence in response to my emails and polite posts on the forum. To be able to code a meaningful set of device drivers for their devices I would need access to each of the devices on offer. I'm not expecting anyone to donate a $30k device, but the lower spec devices would be very reasonable sponsorship for the work, and at least giving me temporary remote access to develop for the $30k device would be beneficial for all in my opinion. On the other hand, if the community doesn't care one bit about what software they're mining with, and a software solution arises that is a "turn on and it just mines", I'm just wasting my time here. That is definitely a huge factor in my thought process. BFL devices are already supported. It seems there is a general misunderstanding on this topic here: while Con has always done a great job maintaining CGMiner as a GPU miner, including the core code dealing with pool requests and ncurses TUI... his involvement with CGMiner support for FPGAs has always been minimal; FPGA and multi-device support in CGMiner is my work, and I plan to continue maintaining it (including maintaining the pool/ncurses code if Con leaves) as well as extend it to work with ASICs. In other words, even if Con does receive FPGAs/ASICs and begins contributing code for them, that is a change from the status quo. Perhaps it was a mistake to label BFGMiner as a fork of CGMiner - while true from a "who has the repository" perspective, the opposite is true in a more practical sense of maintainership: in that respect, CGMiner-of-today is a fork of BFGMiner. So while I appreciate Con's contributions, and would welcome his joining in on the FPGA/ASIC driver side, it isn't fair to say "the community doesn't care one bit about what software they're mining with" just because they don't see a need to buy hardware for a new developer for what is already working fine and maintained. That being said, don't let this stop anyone from buying Con some FPGAs or ASICs - his contributions to CGMiner are more than worth what they cost. In short: - FPGA support in CGMiner has always been my work, and plan to keep maintaining it in any case
- Con's contributions to general CGMiner code (and GPUs!) is appreciated and great quality code; I'd love to have him contribute to FPGA/ASIC drivers in the future
- Please do donate to Con, including FPGAs/ASICs, for his past and possibly future contributions - but don't get the wrong impression that FPGA/ASIC support will change or degrade if you choose not to
|
|
|
|
A quick test with -D -T option enabled worked fine for a while, no crash.
-D option crashes instantly
Normal operation crashes after a few mins.
Seems to be a display issue, it doesnt like the ncurses formating perhaps.
kind regards
Nothing ncurses-related has changed between CGMiner and BFGMiner. Please try with -D -T longer... |
|
|
|
Reposting Kano's lies is not necessary. Yea I read through kano's comments before, I though I would just give things a try, guess this is another confirmation that BFG+icarus is not working in win32. Can you try running in a normal command prompt with -D -T added, and let me know what it prints before crashing? |
|
|
|
Luke, the default CGMiner errors on systems without the AMD sdk, I have no idea (or interest) how to re-compile without opencl.
From my understanding your BFGMiner doesnt require the sdk or opencl.dll to operate, is that correct? Correct... Lastly, I use 4 icarus, is your version a better platform for them? Yes, there are numerous improvements in BFGMiner for Icarus: - On some systems, Icarus will stop communicating until it is reopened. BFGMiner has a simple workaround by reopening it while it's busy hashing away. (CGMiner will just silently stop mining on it)
- BFGMiner uses out-of-order hash searching for Icarus - this minimizes the time period during which Icarus might lose hashes
- BFGMiner uses epoll (on Linux) for longpolling, which provides better reaction time and thus fewer stales
|
|
|
|
I've got a good mind to restart my miners and mine for a couple of days, just to reach the ~0.67 level and clear my remaining balance now. Damn the temps here!  Mining until you were owed ~.67 wouldn't get you paid much faster (if at all), you still have to wait for enough blocks to be found to catch up everyone with older balances than yours. It seems his balance is pretty old (he's not mining for weeks), so it would be paid very soon. Sorry for bringing up an old topic, but my balance is still there. Although it's a small sum, but it gives me that nagging feeling of having some spare change scattered around - and I must've checked it over a thousand times during this couple of months.  My balance has stopped increasing for almost a week now (4-5 days?) and the current block estimate shows: Current block estimate : 0.00000000 BTC I'm confused about the reward though, it seems that for some blocks my balance would increase by a single satoshi, and sometimes not. When on earth would I receive the balance? I understand that I'll need to wait approximately 10-20 blocks from your last count (55 blocks EC) though. about 14 hours ago 1h 22m 46s 0 365,662 0.00013673 BTC 0.00000000 BTC 35 left …6AF21C8D6B0C3B4AD5E1196A8
about 15 hours ago 17h 19m 19s 0 4,367,530 0.00001144 BTC 0.00000000 BTC 29 left …2596C6678636176EA5093ABDB
about 1 day ago 17m 23s 0 78,829 0.00063428 BTC 0.00000001 BTC Confirmed …FCC2E4E48411EF2846BCB50B7
about 1 day ago 40m 34s 0 187,389 0.00026682 BTC 0.00000001 BTC Confirmed …50AA4571D90367F7D825DD5B7
about 1 day ago 7h 28m 50s 0 2,157,236 0.00002317 BTC 0.00000000 BTC Confirmed …C0212B15F5CDE9766CC05A925
about 1 day ago 2h 41m 18s 0 773,464 0.00006464 BTC 0.00000000 BTC Confirmed …BE338AD3EDA399CD12A2C9463
about 1 day ago 1h 35m 9s 0 484,251 0.00010325 BTC 0.00000000 BTC Confirmed …729F6C3345BB0ADC2236963C8
about 1 day ago 23m 19s 0 117,616 0.00042511 BTC 0.00000000 BTC Confirmed …DCEC513FFB76554BA6D280993
about 1 day ago 48m 45s 0 246,752 0.00020263 BTC 0.00000000 BTC Confirmed …68ECFA13A0FC456CD7D6C9A0A
about 1 day ago 45m 50s 0 224,034 0.00022318 BTC 0.00000000 BTC Confirmed …58CEB8DC70F6FAD171F92C92E
I'm in no hurry, just had to sate that itch. Looks like those 1-satoshi rewards were from very short blocks. |
|
|
|
So those "criticisms" could have been made when bitcoin was only 8 months old eh? What's the difference? Bitcoin was vulnerable then and who knows what may happen in the future to change the status quo of digital currencies. No, Bitcoin did not have a preexisting currency with all the same features to compete with. Nor does Bitcoin have the growth-paralyzing proof-of-work known as scrypt. So then when bitcoin say goes to $100 or even $1000 and then the price drops to say $20 then if someone got in at $1000....as the quote says "and continually be beneficial to adopters no matter when they begin using it." What basis is there to expect that will happen? (I already presented my case for why Litecoin is almost guaranteed to fail) |
|
|
|
I'm really hoping you don't stop developing, as I would rather use your software over a fork. You've done a great job so far, and I'm hoping that I can use CGMiner when ASICs start coming out.
CGMiner was originally a fork of CPUMiner for the CPU->GPU migration. BFGMiner is basically the same thing from GPU->FPGA/ASIC, except that I opted to try keeping CGMiner in sync instead of just flat out forking from the start. |
|
|
|
semi-hostile fork I don't really consider it hostile or even semi-hostile. I forked to accomplish two goals, both of which IMO have been successful to some degree: - working miner for Icarus FPGAs (since you let kano remove important bugfixes from cgminer, so I had no choice if I wanted to keep Icarus working)
- minimize everyone's time wasted arguing over changes (now if there's a disagreement, I can just merge it to BFGMiner and not worry about whether CGMiner takes it or not)
I'll be disappointed if you decide to stop contributing, but I can understand your point of view. |
|
|
|
This increase in difficulty seems interesting to me. I have a line of thought that may lead to a solutions that vastly reduces the network and processing requirements of the pool servers. I'll try to lay out my line of thought. I'm sure that I have holes and/or inaccuracies in this, so please try not to dismiss it because of a trivial problem.
As I understand it, the standard way that pooled mining works is this: the pool server looks at the present block chain, pending transactions, and a generation transaction that sends 50 coins tothat the server, and puts together the input to the bitcoin hash function. Then, miners request ranges of nonces to check. The miners compute those hashes, and respond with the ones that have a hash below a certain value (much larger than whatever it takes to mine a block). The server then looks at the shares claimed and easily computes the few hashes for the claimed shares to give credit for working. The pool knows the miner is working honestly because the shares check out ok.
What I propose is that the pool gives each miner an address to send the 50 coins to. Then, each miner makes the input to the hash function be the block chain, existing transactions, a generation block sending 50 to the MINER, and a transaction sending 50 to the pool. The pool can still check that the block is valid, and only gives credit to the miner if it is playing by those rules. With this setup, each miner has a different generation transaction, so there is no reason to partition off nonces through a centralized server. It may cause larger network demands since the full block must be communicated, not just the nonce, but I feel like it could also reduce stale shares. It also requires that the miner hassince access to the full block chain, which not all do.
Let me know what you all think. Sorry if it's a bit wordy.
BIP 0022 |
|
|
|
Is that even required? If the pool detects a high hashrate itself, wouldn't that suffice? With load balancing miners, the pool might detect a much slower hashrate than work is being requested for. Also, not all pools (if any) have a means for the high-level statistics like hashrate to be communicated back to the core poolserver. |
|
|
|
I uploaded the Firmware – 864 mh/s ran a diag on it had no throttling on a light diag and it was running at a steady 864mh/s using easyminer. I went ahead loaded up cgminer and it fluxes between 700-819mh/s does anyone know why its doing this or a possible solution?
Most likely your environment can't handle that speed. Try cooling it to about 70 F ambient |
|
|
|
I've hidden the 4 private keys making up P2SH (3-of-4) address 3EktnHQD7RiAE6uzMj2ZifT9YgRrkSgzQX on various Bitcoin-related websites over the past month. To win, you (or your team of cooperating players) need to: - Find at least 3 of the 4 private keys
- Figure out what order they go in
- Figure out how to redeem the P2SH multisig
- Send the prize coins to an address you control
Addresses: - 1Bvvy2EqCLtf1yz8WXHwEnBDbqQ8QS7NFC
- 19ie41obBNDPqTE67tqoy1aKUXX1cdbcR9
- 1KZxJQNGfoof3RpdZdNkz6Ukzkz2cL7u6M
- 1APEu1fpTgUrwJrB123Gf2zT14PufLCWSs
Currently the reward is 2.25 BTC; I encourage others to add to this - just send to 3EktnHQD7RiAE6uzMj2ZifT9YgRrkSgzQXLooks like someone won. wd. |
|
|
|
TECHNICAL ISSUES:
Several people have reported that only 3 out of 4 of the cards are working, Luke-JR has done some testing and discovered there is a problem with the MCU that may be fixed with a firmware update. Just to clarify, I cannot rule out a hardware issue with the backplane yet - hence cablepair's offer of replacement backplanes in case a MCU update can't solve it. |
|
|
|
Does this version fix another DOS vulnerability or the same as 0.6.2?
No: 0.6.2 fixed CVE-2012-2459, and 0.6.3 fixes CVE-2012-3789. |
|
|
|
why isnt this posted on bitcoin.org?
It is, but GitHub (which hosts the website) sucks at updating when things change apparently :/ |
|
|
|
http://fs07n5.sendspace.com/dl/56045c81d8dc87863633a93d98caa90a/4fe0dd5d18e34a41/0ixpqy/MMQ.zipReset button is on the left ISP button is on the right To do the update: Hold BOTH the Reset and ISP buttons Release the Reset button while still holding the ISP button Release the ISP button Unplug USB and plug it back in, the board will now show up as a mass storage device Open the MSD and you should see one file named firmware.bin Delete firmware.bin and copy the new firmware file to the device If running linux make sure you sync/unmount the drive first Unplug USB, hit the Reset button, and plug USB back in The firmware is now updated. For Linux, it isn't quite that simple. Apparently the MCU has a buggy implementation of USB Mass Storage and/or VFAT, and goes crazy with Linux's vfat driver. But it's still possible to do, using GNU Mtools (package "mtools" under Debian,Ubuntu,Gentoo): mdel -i /dev/disk/by-id/usb-NXP_LPC134X_IFLASH_ISP000000000-0:0 ::/firmware.bin
mcopy -i /dev/disk/by-id/usb-NXP_LPC134X_IFLASH_ISP000000000-0:0 MCU.bin ::/ |
|
|
|
Okay, so what has changed since 0.6.3rc1. Or is it the same?
Same. |
|
|
|
|
Show Posts
