Pushed a "gridseed" branch to the main BFGMiner git based on nwoolls's code. I'm not sure how these are supposed to perform, but I get some inconsistent results in benchmark mode: DMU 0: | 36.8/ 68.2/ 41.7kh/s | A: 28 R:0+0(none) HW:0/none
GSD 0: | 0.73/ 1.27/ 0.17Mh/s | A:112 R:0+0(none) HW:8/none How's it work for others who have been using them in production? |
|
|
|
2013 Feb, after discussion, mining.subscribe was extended to take 2 arguments, so now it's mining.subscribe(String useragent, sessionid) where sessionid is optional, but if provided must match a previous session's mining.notify subscription id. If the server allows resuming a session, it will give you back the same subscription id and extranonce information.
BFGMiner (at least) will also send mining.suggest_target("hex target") upon connection, if the user has a preferred target.
This post should have been on the other side of the split. |
|
|
|
Here we go again :-
Let the undocumented stuff coexist, it's rather unimportant anyway since most pools couldn't care less what the miner wants. +1, suggest splitting side-discussion off to leave the thread to just the documentation posts. |
|
|
|
BFGMiner (at least) will also send mining.suggest_target("hex target") upon connection, if the user has a preferred target.
Why would it do this? There is already mining.suggest_difficulty(difficulty) No, there isn't. Nothing implements this, and it isn't documented anywhere. If you say something that contradicts facts in front of your face, oddly enough, that just makes you look foolish. Try a little sense in your posts. One of the posts above, shows where it was documented, over a year ago: https://bitcointalk.org/index.php?topic=108533.msg1543341#msg1543341Forum posts are not documentation. You've been flipping too many burgers at McDonalds - it's softening your brain and you are forgetting things: https://bitcointalk.org/index.php?topic=108533.msg1543185#msg1543185But I guess that's to be expected. Hard to see how I forget something I never read in the first place. I don't see anything relevant there anyway. Con agreed to implement slush's spec and then never did. How is this relevant? |
|
|
|
BFGMiner (at least) will also send mining.suggest_target("hex target") upon connection, if the user has a preferred target.
Why would it do this? There is already mining.suggest_difficulty(difficulty) No, there isn't. Nothing implements this, and it isn't documented anywhere. If you say something that contradicts facts in front of your face, oddly enough, that just makes you look foolish. Try a little sense in your posts. One of the posts above, shows where it was documented, over a year ago: https://bitcointalk.org/index.php?topic=108533.msg1543341#msg1543341Forum posts are not documentation. |
|
|
|
BFGMiner (at least) will also send mining.suggest_target("hex target") upon connection, if the user has a preferred target.
Why would it do this? There is already mining.suggest_difficulty(difficulty) No, there isn't. Nothing implements this, and it isn't documented anywhere. Using a target fixes the inherent problems with using difficulty as a Number: - There is no agreement over which difficulty measurement is to be used. The official spec says bdiff; BTCGuild uses pdiff; various scrypt pools use Ldiff
- Some common targets (such as pdiff 1) cannot be accurately conveyed without huge data sizes
- Implementing conversion to/from difficulty accurately requires a bignum library, so often (eg, *gminer) it is just approximated.
|
|
|
|
|
2013 Feb, after discussion, mining.subscribe was extended to take 2 arguments, so now it's mining.subscribe(String useragent, sessionid) where sessionid is optional, but if provided must match a previous session's mining.notify subscription id. If the server allows resuming a session, it will give you back the same subscription id and extranonce information.
BFGMiner (at least) will also send mining.suggest_target("hex target") upon connection, if the user has a preferred target.
|
|
|
|
Can mazacoin be merged mined with bitcoins? I believe Luke has gone on record stating that they don't support alternate currencies except those who might be doing something new and/or useful. NMC is the only one he recognizes as such to date. I don't know anything about mazacoin, but you'd have to get that past Luke, first. NMC is not the only one, but until recently was the only one that supported merged mining. I've been encouraging wizkid057 to add HunterCoin and MazaCoin, but he hasn't had time yet. Ah OK, so a complete reversal of what you've said in the past about alt-coins ... I've always made a distinction between scamcoins and legit altcoins. |
|
|
|
Can mazacoin be merged mined with bitcoins? I believe Luke has gone on record stating that they don't support alternate currencies except those who might be doing something new and/or useful. NMC is the only one he recognizes as such to date. I don't know anything about mazacoin, but you'd have to get that past Luke, first. NMC is not the only one, but until recently was the only one that supported merged mining. I've been encouraging wizkid057 to add HunterCoin and MazaCoin, but he hasn't had time yet. |
|
|
|
|
Anyone up for writing a BIP draft? Slush finally had numbers assigned a while ago, but apparently he's been too busy to actually write the specs...
|
|
|
|
|
When it comes to Bitcoin, DDoS means 30+ Gbit/sec :p
|
|
|
|
Hi Luke, Which is the latest Stable release of BFGMiner? In your post https://bitcointalk.org/index.php?topic=168174.0 you announce version 3.10.0 but below the latest stable release is listed as 3.5.7 (should I use this one as latest stable release). Thanks! Use the oldest maintained (listed) version that supports the functionality you need. They both get bug fixes, but the newer version has more features (which are less tested). |
|
|
|
The option you want is probably --scan-time Alternatively, you could setup a pool for failover, and BFGMiner will use it to pick up on new blocks faster. If you prefer to just use bitcoind itself, you can merge the longpolling branch. Finally, many solo miners choose to run their own pool (but this is not for the faint of heart!). As far as bitcoind connections, the p2p networking code is pretty bad, so it's more important to have good peers, than many peers. Eligius's public node is at relay.eligius.st; I don't think other pools publish theirs, but you can try to find and add those too. Use the bitcoind option -addnode=relay.eligius.st to use this. |
|
|
|
|
libcurl 7.18.2 was released in 2008. That's 6 years ago.
I'm not going to support older versions unless someone provides me with a clean patch.
|
|
|
|
Trying to compile on CentOS 5 (yes, I know it is a pretty old linux... but have to use it) Config doesnt pass libblkmaker check. Installed it from the included package, but still see this error: checking for libblkmaker... no
configure: error: Could not find system libblkmaker
I'm configuring with the following options (want to test it with CPU and probably FPU for different currencies) ./configure --disable-avalon --enable-cpumining --enable-opencl --disable-adl --disable-bigpic --disable-littlefury --disable-nanofury --disable-hashbuster --disable-hashbuster2 --disable-bitforce --disable-icarus --disable-klondike --disable-modminer --disable-x6500 --disable-ztex --enable-scrypt --with-system-libblkmaker --without-curses --without-libmicrohttpd --without-libevent --without-libusb --without-libudev Any tips how to configure it? Thanks! If you don't configure --with-system-libblkmaker, BFGMiner will just built and use it itself... If you want to go the system libblkmaker route, you'll have to install libblkmaker correctly. I think RHEL5 has its library paths messed up; try adding /usr/local/lib to /etc/ld.so.conf and/or running ldconfig... |
|
|
|
Thats great to hear but I am worried there might be some imminent abuse coming.
Any way to limit the amount of edits one can do? similar to activity on this forum
I had/have similar fears. Anyone who abuses wiki edit privileges may have their forum account "punished" (yet to be defined by theymos). Also part of the reason this is a one-time thing, is so that banned users can't just recreate a new wiki account and keep abusing it. |
|
|
|
@luke, but this logically results from discouraging the use of OP_RETURN while criticizing developers who use the blockchain for anything that isn't by-the-book, doesn't it? It may be technically beneficial to keep these applications off of Bitcoin's back in a perfect world, and I would agree that in this form Bitcoin stays what it is which could be a good thing. However it has the effect of keeping Bitcoin unchanging, i.e. pure, which has I would argue adverse implications on the number of people interested in the idea of a decentralized economy. I'm just of the opinion that the "solution", whatever it is, has to be using Bitcoin. I don't think other cryptocurrencies can rise to the same level of success, and I also don't think OP_RETURN 80 has a noticeable effect on the long-term network topology.
Unless I misunderstood someone, I believe every Core developer who commented here (jgarzik, maaku, and myself) supports Counterparty using OP_RETURN/80 transactions until better solutions are implemented. |
|
|
|
|
Nobody here wants to "encase Bitcoin in minimal purity".
|
|
|
|
whose owner has destroyed a different coin which is nothing short of criminal, IMO Oh really, which part of stopping scammers from screwing people is a crime? (I knew earlier he had, didn't know he used others hashes to do so). That's because this part is a lie. I did it myself. It wasn't hard. |
|
|
|
|
Show Posts
