Working thanks
EDIT: maybe I spoke too early.
Now I have:
SGW 0: Initializing...
and nothing happens
Blades have finiky (read: broken) network stacks. Maybe try messing with the computer's MTU? :/ |
|
|
|
You might need to build from source until unit3 gets around to updating the PPA  OK I have no idea what did you told me... Linux is totally new to me. All I would like is to install 3.2.0 with blade support. sudo apt-get install build-essential autoconf automake libtool pkg-config libcurl4-gnutls-dev libjansson-dev uthash-dev libncursesw5-dev libudev-dev libusb-1.0-0-dev libmicrohttpd-dev curl
curl http://luke.dashjr.org/programs/bitcoin/files/bfgminer/3.2.0/bfgminer-3.2.0.tbz2 | tar xjvp
cd bfgminer-3.2.0 && ./configure && make Then when you want to run BFGMiner, go back to this directory and run: ./bfgminer your-options-here |
|
|
|
You might need to build from source until unit3 gets around to updating the PPA |
|
|
|
The pool estimates your hash rate based on the number of shares submitted. There is no other way to know your hash rate pool-side. X-Mining-Hashrate header <.< |
|
|
|
1, the address they're sending money to for the Electronic Frontier Foundation donation is a paper wallet generated offline.
2, I don't think they're technically my customers... contestants maybe? Ok, fair point. Hopefully the EFF will use a proper paper wallet at some point instead of address reuse  3, blockchain.info does support sweeping private keys, but I think the sweeping of private keys was in referecnce to the destination address, which I already said was a paper wallet that was generated offline. But I have been drinking so I could be wrong. I meant in reference to redeeming the coins themselves. 5, I love you damn developers and all your coding hobnobery! cant wait for 0.9.
... and about 0.9... I went through a lot of freaking effort incorporating pgp signed addresses in my site. Is 0.9 pretty much going to nuke that effort?
Well, sending to addresses will still work of course. Unfortunately, the only user-accessible solution is to rely on CA-based SSL instead though. |
|
|
|
|
Also, please note that importing private keys is generally dangerous.
If your wallet doesn't support the "sweep private key" feature (Bitcoin-Qt does not!), I suggest using a throwaway wallet and sending the full balance to your real one when done.
|
|
|
|
|
The only way to know who sent a transaction is to create a unique address for it.
If you use blockchain.info messages, you are trusting a centralised entity to tell you, and forcing your customers to use a centralised wallet.
The "sign message" feature only supports signing with addresses (ie, proving you can receive), there is no current way to sign as a sender of a transaction.
Bitcoin-Qt 0.9 will be adding support for the payment protocol to make this kind of thing simpler.
|
|
|
|
This address is part of a shared offline wallet, so not all the funds are necessarily Eligius's. When wizkid057 does manual payouts, it often comes from my hot wallet, leaving the actual block subsidy in the offline wallet. wizkid057, what do you think about exposing the "Never send me non-generated coins, even if it means I need to wait longer" option to the My Eligius config? |
|
|
|
when to expect stratum proxy enabled for OpenWRT?
After I decide to write stratum proxy support (or someone else contributes it), at least  |
|
|
|
Just add a few lines to your ~/.bitcoin/bitcoin.conf file (create it if it doesn't exist): rpcuser=bitcoinrpc
rpcpassword=somethingsecure
server=1 Then run Bitcoin-Qt, and it will behave like bitcoind as well. |
|
|
|
My only issue at this point is for some reason 3 out of my 25 sticks show up as BES instead of ICA and are giving me sick/dead restart problems. Before I changed to this version, I have been stable since I set it up. Impressive to say the least. I definitely want my blade connected through BFGminer... So I have isolated the 3 erupters that show up differently and pulled them, now BFG is running like a champ. Not a big deal since my windows machine is always running with my node and so I can just put the 3 "BES"sticks on there. Just thought I would add that information in case someone else is having a similar issue. This is pretty odd. They really should all show up as BES (Block Erupter Sapphire), but I'm curious as to why that is creating problems for you. What options are you using? Can you try with just -S erupter:all and not any --icarus-* options, in the same instance? Temporary workaround in any case: -S erupter:noauto will disable the autodetection of autodetect-capable Erupters (likely the 3 that show up as BES for you). I have tried -S erupter:all and --scan-serial erupter:* * is not a special character with --scan-serial, and will be ignored. |
|
|
|
Thanks for the advice, I'll try that later. I should have realised about screen - I used that when setting up p2pool.
I've got my TP-Link 703N up and running with OpenWRT, and a 4GB USB stick as / - plenty of space. Got bfgminer installed. When I run it, I get the "All Devices Disabled, Cannot Mine!" error. I assume I'm missing the VCP drivers? Any pointers on how to get Erupters mining on this thing?
opkg install kmod-usb-serial-cp210x |
|
|
|
Personally, I would use GNU screen. If you really want to background it the classical way: bfgminer <your options> -T &>some.log &
disown |
|
|
|
I get this error, both in cgminer and BFGminer for my 30gh/s Little SC:
BitForceSC detected (5:1) invalid s-link count: '--DEVICES IN CHAIN: 00x00' This error is completely impossible with BFGMiner. I would suspect it is due to cgminer's attempt to reinvent their own non-standard drivers. If it doesn't work with BFGMiner, using the official FTDI drivers (ie, NOT winusb/zadig), please post the error you get. Your video is inverted in both dimensions btw O.o |
|
|
|
Luke-Jr, have you heard anything about the BitFury USB miners? Someone says they need to be plugged in to a RPi, which sounds like bollocks to me. USB is USB is USB...and the Pi has a shitty USB implementation if we're being fair to it.
Surely it's just a case of drivers? No mining chips support USB themselves. USB devices require an additional controller chip. RPi-based Bitfury devices (Metabank and c-scape) are using SPI and GPIO to communicate directly to the chip(s). There is also the LittleFury, which has a MCU that does (among other things) USB interfacing - this should work on any USB system. Note that the code for handling BitFury is still immature, and I plan to rewrite a lot of it before merging it into mainline for BFGMiner 3.3. |
|
|
|
I'm running BFGMiner 3.2.0 against the Eligius pool. I have just reached enough hashing power where I think I could benefit from raising the difficulty of work units handed out by the pool. I have gone and told Eligius to hand out a minimum difficulty of 2.0 work units. I have run for a while and the work units continue to be difficulty of 1.0. So I decided to try the '--request-diff 2.0' argument. However, the pool is still handing out difficulty 1.0 work units.
Since BFGMiner is the recommended for Eligius I'm surprised that neither methods are working.
Is this a bug in BFGMiner?
No, Eligius doesn't honour --request-diff except as a default for new GBT clients. (although I am working on an upgrade for the Eloipool software to improve this) |
|
|
|
I would be very keen to use this if you did. I'm planning on using the TL-WR703N, which I think has 4MB flash and 32MB RAM.
4 MB flash is too small for even the normal BFGMiner packages (or really any packages). The only way I expect you'll be able to make this work is to build a custom firmware with BFGMiner included in the main image. Whether libmicrohttpd could be squeezed into this or not, I'm not sure of. nah, its much easier: "opkg -d ram"  Did you get this to work? I tried for Avalon's TP-Link, and found this feature is pretty broken. |
|
|
|
More info from IRC... He claims that punin defined "unit" as not being the full 400 Gh/s in this post. I disagree; punin admits the single board did not meet expectations, but he never says the ordered unit won't. On the contrary, he says an additional board will be provided to make sure the delivered specs are met. It seems to me two boards comprise the full unit of this "first batch". Not the advertised design, but it does meet the advertised specs the bet mentioned. Furthermore, he also admits that he made this bet after he though the conclusion was certain (ie, reading that post), and that he was not prepared to lose. Betting when one is certain of the outcome is morally wrong unless the other party agrees knowing you are certain.This can clearly not be the case for everyone who bet before the forum post in question. So, I'm not at all sympathetic, as he basically tried to steal from the other betters. While I still wouldn't recommend trusting mircea_popescu (who runs bitbet), he clearly made the right decision in this case. |
|
|
|
If Windows is reporting ERROR_ACCESS_DENIED maybe Windows is reporting that error because of a problem that is different than the one you anticipated. It's not a matter of anticipation. ERROR_ACCESS_DENIED is defined as a permissions issue. If Windows is returning it for a non-permissions problem, Windows (or a driver instructing Windows to do it) is at fault. |
|
|
|
Do the 365 Gh + extra units still run with only 400W power?
no, from this post https://bitcointalk.org/index.php?topic=250249.msg3050985#msg3050985 it seems they use 270W. I believe thats how Bitbet was able to confirm the bet, based on the Ghash/Watt. However the bet wasn't about the Ghash/Watt or $ or BTC/Watt, it was about the performance statement. Had they overperformed based on their claims, for example 415Ghash instead of 400 Ghash, and a proportional power increase, I'd say that is fair, but with the info provided, I'd agree the answer to the bet was obviously No. Yeah, 270 W is definitely better than specs... |
|
|
|
|
Show Posts
