I have a problem when building bfgminer 2.8.2 or 2.8.3 with MinGW. I followed all of the instructions but when i type "make" at the shell i get
"configure: error: Could not find jansson library". With 2.7.5 there's no problem. You need libjannson installed. |
|
|
|
Sorry, I disagree solo mining at low hashrates is pointless: Solo mining today is basically the same as entering a perfectly fair lottery. For CPU miners, it makes more sense than pooled mining where you are guaranteed to lose out on electric costs. With solo mining, you write off the electric costs and if you hit the jackpot, you've got a nice bonus  |
|
|
|
|
I've pushed a very basically working "dev_x6500" branch to GitHub.
For now, it is very unpolished and seems to be mining at around 100 Mh/s.
|
|
|
|
What I don't understand is why miner submited to pool 1. Did pool 0 went down temporaly (why there's no message about it?),
so miner temporaly switched to pool 1? I haven't set any specific multipool strategies, e.g. miner uses the default one (failover). Without --failover-only, BFGMiner will use other pools' work (eg, from the longpoll) in some cases. Likely the share you refer to was found before updated work had been retrieved from your local bitcoind yet. |
|
|
|
(or maybe just bitcoind) would be quickly out-competed if that rule was adopted.
That is the point. Development would not stop. Bitcoin would not be stopped. Only a certain (and currently central) sect of it will and it would only apply to protocol changes, not client development. You're contradicting yourself! I will also add that recently a bug was found in Bitcoin-Qt's latest build (Ultraprune) that changed the Bitcoin protocol, inadvertently. Ultraprune did not intend to change the protocol. To avoid bugs like this entirely, all core client development would have to stop. That means at the very least, blockchain download could never be made to scale. I'd suggest helping find and fix these bugs, but you've made it clear you don't even have skills enough to be a competent tester. P.S. Why five years? So new competing releases have time to develop and challenge any dangerous changes that come our way. Furthermore, competing clients are inherently vulnerable to the same kind of potential bugs. To achieve a guaranteed protocol freeze immune to any bugs, you would have to forbid new clients! |
|
|
|
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Greetings Eligius Miners,
After much discussion, Luke-Jr has decided retire from his post as Eligius pool operator and has turned over the keys to Eligius to my care.
There are many reasons behind this decision, but I'll summarize by saying that Luke has many many things on his agenda which, in my opinion, are more important than the day to day maintenance of running a mining pool. And since we obviously don't want to shutdown the pool, it was decided that I would be the best candidate to take on this task.
For those who know me on IRC and otherwise, you already know that this will not be any kind of issue and falls well within my expertise. For those who don't, here's a little background. I'm a mostly self-taught programmer, hardware engineer, network engineer, and any other IT field you can think of. I have close to 20 years of personal experience in the field and over a decade of professional experience. As for the Bitcoin community, I've been involved at various levels from the moment I heard of it's existence somewhere around a year ago. Since then I've contributed as much as possible, most recently with the redesign of the Eligius stats pages to be more server-side friendly. If you have any questions or concerns, feel free to shoot me a message on IRC or other contact method.
Without sounding too much like a politician, for the moment, and in general, my goal is to do my best to make sure the pool continues to run smoothly.
In the short term, this means I plan to implement CPPSRB, a replacement for the current SMPPS reward system, which will get Eligius back on track and get current and new miner's paid more quickly for their work. This has been on the table for some time, but it is a significant undertaking to code, test, and tweak (as can be noted from some discussions about the matter in #eligius recently). I hope to have this particular project under way very soon.
I will also continue development of the "New Stats" to provide more and more information in the best ways possible.
As always, I plan to stick with the ideals behind the pool in general, continuing to be supportive of things like no-signup mining and providing as much openness as is possible regarding the operation.
There is much progress to be made, and soon! I'm glad I'll be along to help keep everyone mining away!
Sincerely,
- -wk
Contact: wizkid057 at gmail.com (Email, Google Talk, etc)
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iQEcBAEBAgAGBQJQhhUfAAoJEIlunYJa75GPS6IH/2IUOMBlTpeilMohMf0ayQc4
9QFTdmPEZHzgF+NDCkOrzM3Y6Q6atEtyd9sbO5ZCff6uHUIgaq0QbWcnBz7XPZKM
i/y51dQZCNhHpzqBmliXNaHnOv4jHV6YbcxrdbJKxSl5bQFLFGAKrFKzDOPkuTva
ChB0TDdf7/5Igm/JrMyFR8hyJHpYaWTJ2hviD8l5fyaMqlX9H96l1XgkMiXODXtl
WINjm/cvIvAYBCc5bzEMI+AN9RGM2Vup9vkW6x7czF5yHsGkIpj0nV/mQPGcMhP/
HI7lt9O/quPSvoQanhepadDUVRAiXie6QWlUb4sANfGSr2FGlsEwPXl8ojn1xl8=
=O2+p
-----END PGP SIGNATURE----- |
|
|
|
BFGMiner can do the same as described in this post or not? In theory, though I haven't tested it lately. If it doesn't work, feel free to open a bug report on github for it. Additionally, you can use BFGMiner with Bitcoin next-test to get native longpolling from bitcoind/Bitcoin-Qt. |
|
|
|
The blockchain would have to be reduced to under a few megabytes Getting off-topic here, but this is already possible. and RAM usage would have to be a few hundred kilobytes This is completely unreasonable. Merely being a C++ program requires more than a few hundred KB. |
|
|
|
Anyone know how to get this to work with a windows utility like restartme or restart on crash? I prefer bfgminer to aoclbf/phoenix, but it crashes leaving my system gobbling power w/o mining. I'd rather figure out what's going on that causes it to crash for you. Can you go into more detail on that? I built a functional .bat, then a .conf file, but neither works with either utility. When the restarters point to bfgminer.exe it re-launches fine, but ignores the config file and just pops up a cmd window.  BFGMiner looks for the config file named bfgminer.conf in the "working directory" it's launched from on Windows. Hopefully those programs let you specify that? |
|
|
|
|
I agree that it would be best to ensure the new list prefer decentralized pools (GBT and p2p) over centralized ones (Stratum).
Eligius should be ASIC-ready as soon as we switch to the new CPPSRB reward system, hopefully before November.
I plan to use a target of 20-30 shares per minute, but might make it miner-configurable.
|
|
|
|
in the US we don't have any smart chips, yet. Citi does, FWIW. |
|
|
|
I've just merged my "ultraprune" branch into mainline (including Mike's LevelDB work).
Does this require downloading and re-processing the blockchain from the beginning? Yes. However, to save downloading, you may provide -loadblock=DATA_DIR/blk0001.dat -loadblock=DATA_DIR/blk0002.dat
to import the old data files into the new bitcoin database backend (ultraprune/leveldb). * "DATA_DIR" should be replaced with the directory where your blockchain was stored in <= 0.7.1. It doesn't do this automatically? It really should before this is officially released. You could even just add them as implied bootstrap.dat files. I'm sure 0.8 will do this (and more!). Seriously, we just released 0.7.1 (from master)... 0.8 is at LEAST a month off (probably longer). Git master isn't supposed to be end-user friendly and go-for-production right now. If you need something stable, use a release! (I'm not necessarily addressing you specifically, just the general "omg it's crazy broken" sentiment I've seen lately) |
|
|
|
I do intend to improve BFGMiner's GBT implementation such that it transparently combines pooled and solo mining, at least. That is planned in release BFGMiner's 3.0? Probably that will have to wait for 3.1... 3.0 is the ASIC release, and that's coming up too soon. I do intend to improve BFGMiner's GBT implementation such that it transparently combines pooled and solo mining, at least. That's cool, but solo mining should not be an option - it should be mandatory. Else the whole project is just another house of cards. Unfortunately, simply making it mandatory isn't practical. The closest we could come is giving strong incentives for doing so. For example, I intend to set up Eligius in such a way that those who are solo mining in combination can profit more by claiming the fees from transactions they accept over the base set Eligius provides. |
|
|
|
|
I do intend to improve BFGMiner's GBT implementation such that it transparently combines pooled and solo mining, at least.
|
|
|
|
Cons:
- rare DoS vulnerability
- rare bugs causing application to hang
- longer initial blockchain download Don't forget the very easy netsplit exploit and who knows how many other unnoted vulnerabilities due to non-maintenance... Using 0.4.1 right now but it sucks, it forces to add tx fee when sending new coins. So don't send new coins? Why use 0.4.1 instead of 0.4.7 or 0.4.8rc4? Tx fee are bad when you are playing satoshi dice. Well, that's your own fault for participating in a DDoS against Bitcoin. |
|
|
|
How about adding an extension to GBT that has some kind of mode that sends a "suggested merkle root" for pooled mining? That's an idea... have to consult with Luke on that. Not really, Con or anyone else is welcome to write a draft BIP to enable centralized mining over GBT, and open the topic to discussion. But I think it's possible to adopt Stratum's benefits without losing the decentralization benefits - though I don't think it is a problem that needs to be addressed immediately, nor do I have time to do it myself right now. BIP 22 and 23 were developed by collaboration of the community, and while I may be the primary organizer, there is no reason someone else couldn't take it forward more on their own initiative. I also wanted to point out that if we (or someone anyway) doesn't build a scalable solution per pooled mining with an integrated node... then nobody will be able to include it in the POS machines that will eventually be developed, and missing the chance for millions of additional nodes seems sad to me. GBT is pretty scalable for now. |
|
|
|
|
Not to imply it isn't a scam, but someone does not need BFL's permission to resell their products. Most countries have a "doctrine of first sale" that basically allows reselling without permission. There is a possibility they've worked out some import tax discount and just aren't good with websites or the English language. But again, it's probably likely this is a scam anyway.
|
|
|
|
Power usage is *everything* when it comes to ASIC. If you think it's not, you have no grasp on the economics of mining.
Please explain your economics of mining. By my calculations power usage at this order of magnitude is pretty much irrelevant compared to price. Take a BFL Single, 60 Ghash/s, 60 W. The miner costs 1299 USD and will use 1.44 kW/day. 14.4 cents a day at 0.10 USD/kWh. You can run this miner 24/7 for almost 25 years before you have spent the same amount for power to run the device that you paid for the device itself! There may even be better miners to buy at a lower price in 2037, making it obsolete before the owner has spent more on power to run it than on the device itself. If the device is still working. (How long is your warranty and what is the expected lifetime of a BFL Single, btw?) Hardly anyone will ever pay more for the power to run the miner through it's lifetime than they did for the miner itself. My simple math shows that power usage is almost irrelevant for an ASIC miner. Price per Ghash produced throughout the miners lifetime will almost certainly always be dominated by the initial investment, not power consumption. Price per Ghash/s is the important factor. Is my math wrong? No, just your assumptions on difficulty. I don't expect any of these 60 GH range ASIC products to make even $1000 in 2013 alone. By design, difficulty will always bring the cost-to-mine very close to power costs. When it catches up, power costs will be all that matters. Until then, delivery dates before it adjusts are the key importance. |
|
|
|
NEW VERSION 2.8.3, OCTOBER 18 20122.8.1 made an old, rare dereference-after-free error a lot more common in some cases (due to locking the output mutex for new debug info) so I finally got a proper chance to track it down. That crash, along with a variety of other bugs (including some scrypt fixes from Jake and Con) have been fixed for 2.8.3. 2.9.0 is still in the works to bring the long-anticipated X6500 support (which is now coming along nicely). Depending on testing and reviews before then, it may also include solo mining and/or Stratum support - so if either of those features are important to you, please test the latest code (in git branches) and let me know! Human readable changelog:- Various bugs fixed, no new features.
Full changelog- Update to libblkmaker 0.1.3
- Use explicit host to BE functions in scrypt code instead of hard coding byteswap everywhere.
- Ease the checking on allocation of padbuffer8 in the hope it works partially anyway on an apparently failed call.
- Round target difficulties down to be in keeping with the rounding of detected share difficulties.
- String alignment to 4 byte boundaries and optimisations for bin<->hex conversions.
- Fix GPU memory allocation size for scrypt
- Fix access violation with scrypt mining
- Bugfix: Only free rpc_req after using it, not before
- Bugfix: Increment work->pool->staged inside of mutex to avoid work being freed (and staged decremented) before we dereference it
- Revert "No need for extra variable in hash_push.": The extra variable is needed to avoid a rare dereference-after-free error.
- In opencl_free_work, make sure to still flush results in dynamic mode.
- Workaround: Debug log only after dec_queued, to make a free/use race more rare
- Bugfix: Remove redundant \n in debug messages
- Bugfix: Free rpc_req in pool_active and longpolls
- README: Explicitly provide Ubuntu package name for libjansson-dev
- Bugfix: Include flash_led bool in cgpu_info for Icarus-but-not-BitForce builds, since Cairnsmore uses it
- Only check work block id against pool's if the pool has a known block id
- Avoid clearing pool->block_id unless we really are changing pools
|
|
|
|
I solved 2 blocks today  I'm a lucky bastard  Just found another! Thats 3 in 4 days. Fuck me sideways... I guess a bit late now, but if you use BFGMiner's --coinbase-sig option, you can embed your nick or something in the coinbase of blocks you find |
|
|
|
|
Show Posts
