P.S. If this is not a dedicated miner, you don't have to use bitcoind anymore. You can use Bitcoin-qt (still have to configure it to listen for RPC requests, of course). The bug that was making bitcoin-qt unstable with p2pool has been fixed.
Bitcoind is still a little lighter on resources though, right? Not significantly. In any case, the reason people would probably prefer using bitcoin-qt on a non-dedicated p2pool machine (i.e. the machine is their main machine that they use for other purposes) is that it has a user interface for interacting with your wallet (instead of using the command line which isn't as comfortable for some people). |
|
|
|
Since 0.6.0 came out I tried to get p2pool working, but failed. Once I followed all the noob friendly steps cgminer wouldn't work, I have a feeling I need an sdk, but the further down this installation rabbit hole I go the more problems I find.
Would someone be able to tell me the number of programs required to run p2pool with full functionality? I installed 5 (bitcoin, p2pool, cgminer, python, twist) and I have a feeling I need a few sdks as well, would an estimate of 10 installs be necessary to get p2pool to work? Does it depend on my hardware? Do I need to be proficient in bitcoind as well? (I ask because I run bitcoind and all I get is a black screen, I can't type anything) Thanks for the help and work you guys do.
If this is for a dedicated miner, it might be easier to just grab p2pcoin. To troubleshoot your setup, work in three steps. First, get bitcoind running. Then p2pool. Then the miner. You need to configure bitcoind to become a background daemon, otherwise it will hold the terminal open and never write anything to it, the black screen that you describe. Once you have the black screen, check the debug.log file. If that file is growing, bitcoind is actually running, which would just mean that you need to configure it. P.S. If this is not a dedicated miner, you don't have to use bitcoind anymore. You can use Bitcoin-qt (still have to configure it to listen for RPC requests, of course). The bug that was making bitcoin-qt unstable with p2pool has been fixed. |
|
|
|
I'm getting some odd behavior from one of my icarus boards. The symptom seems to be that every time it finds a share, the miner sees it as two shares that are the same. Of course the second one gets rejected as a duplicate. Here is example from MPBM:
this behavior usually happen when set the FPGA ID to the same value. this variable is set by S2-2 and S3-2 switches. please notice if they set to a same value, or cause by something like switch internal poorconnection. a solution is change the S2-2 and S3-2 value to opposite. Well, I looked at the board and they looked correct. However, just to be sure, I flipped both dip switches and then flipped them back. Now it is working again. So maybe it was just not entirely flipped. |
|
|
|
I'm getting some odd behavior from one of my icarus boards. The symptom seems to be that every time it finds a share, the miner sees it as two shares that are the same. Of course the second one gets rejected as a duplicate. Here is example from MPBM:
Can you compare the dip switch settings of a working board with the misbehaving one? If they are different between boards (especially if both FPGAs on the misbehaving board set to the same value) that could explain this issue. Ah, good idea. I'll check when I get home. Note, this started happening at about the same time that I physically reorganized my rigs and moved these boards to a different location, so maybe I bumped something. |
|
|
|
I'm getting some odd behavior from one of my icarus boards. The symptom seems to be that every time it finds a share, the miner sees it as two shares that are the same. Of course the second one gets rejected as a duplicate. Here is example from MPBM: 2012-03-30 06:30:39.812854 [350]: Icarus 0 found share: BTCProxy:0000000163abd0bd61fa5d7d42cab7eb3be533512f782aa3f2608e3a0000087200000000f8e7cdd443fb0bc6d2d933fddd7dfd8f08e21a12ef6d45751ea616c54dd5327a4f7598b41a0a507e:96729b3a
2012-03-30 06:30:39.813580 [350]: Icarus 0 found share: BTCProxy:0000000163abd0bd61fa5d7d42cab7eb3be533512f782aa3f2608e3a0000087200000000f8e7cdd443fb0bc6d2d933fddd7dfd8f08e21a12ef6d45751ea616c54dd5327a4f7598b41a0a507e:96729b3a
2012-03-30 06:30:39.853994 [400]: Mining BTCProxy:0000000163abd0bd61fa5d7d42cab7eb3be533512f782aa3f2608e3a00000872000000007147b19ecba613c5b68fbddc0777343cfc65f3dae2a4f28fcd058d18fd0c06034f7598b91a0a507e on Icarus 0
2012-03-30 06:30:40.198653 [500]: BTCProxy: Got 1 jobs
2012-03-30 06:30:40.202807 [250]: BTCProxy accepted share 96729b3a (difficulty 1.34014)
2012-03-30 06:30:40.319497 [200]: BTCProxy rejected share 96729b3a (difficulty 1.34014): Unknown reason
2012-03-30 06:30:42.819884 [350]: Icarus 0 found share: BTCProxy:0000000163abd0bd61fa5d7d42cab7eb3be533512f782aa3f2608e3a00000872000000007147b19ecba613c5b68fbddc0777343cfc65f3dae2a4f28fcd058d18fd0c06034f7598b91a0a507e:c08f8021
2012-03-30 06:30:42.820828 [350]: Icarus 0 found share: BTCProxy:0000000163abd0bd61fa5d7d42cab7eb3be533512f782aa3f2608e3a00000872000000007147b19ecba613c5b68fbddc0777343cfc65f3dae2a4f28fcd058d18fd0c06034f7598b91a0a507e:c08f8021
2012-03-30 06:30:42.823446 [400]: Mining BTCProxy:0000000163abd0bd61fa5d7d42cab7eb3be533512f782aa3f2608e3a0000087200000000afe089209862ec0ac0038b7e62fda7528d9c7d44f9aeb8b50502539f06248ddc4f7598c01a0a507e on Icarus 0
2012-03-30 06:30:42.921271 [500]: BTCProxy: Got 1 jobs
2012-03-30 06:30:42.938696 [250]: BTCProxy accepted share c08f8021 (difficulty 1.18879)
2012-03-30 06:30:43.057058 [200]: BTCProxy rejected share c08f8021 (difficulty 1.18879): Unknown reason
I tried this with cgminer also and it doesn't list any errors about duplicates (perhaps because it is quietly detecting the duplicates and ignoring them?). However, that board has a Utility stat of only 2.5 instead of being close to 5.2. So perhaps it is still happening and the extra round trips are reducing the effective hashrate. Note, this does not happen on my other icarus board. The other one is working normally. In fact the board that is currently acting up was working fine for a day or two before this started happening. I thought it might be a heat problem, so I stopped it for an hour to let it cool completely down, but the problem persisted right away after rebooting my host computer and starting mining. Anyone seen anything like this before? |
|
|
|
|
Tested with no problems on OS X 10.7, Ubuntu 11.10, and Debian Unstable. Did in place upgrades and full blockchain redownloads.
|
|
|
|
so i followed the guide for windows and got my local machine to mine and run p2pool, but how would i point my other machine running bamt to it? i tried using the username:password i setup in the rpc conf and pointed it to 127.0.0.1:9332, yes the ports open, but it did nothing. thanks in advance
127.0.0.1 is the wrong IP address if you are trying to point a miner on a different machine to your windows p2pool node. 127.0.0.1 is "localhost" and always refers to the local computer you use it on. You need to use the IP address or hostname of your windows machine: mywindowsmachine:9332 or x.x.x.x:9332 |
|
|
|
After additional investigation, it appears that they are not currently blocking btcguild.com. I am still getting this at work because my internal DNS is, for some reason, still returning 174.129.221.183 as the IP address for the domain. I don't know if that is because its caching is broken or because someone intentionally added a rule to block this domain.I believe that OpenDNS was blocking http://bitcoin.sipa.be/ earlier this week (it has since been cleared up). Maybe they blocked a bunch of bitcoin related domains and then unblocked them when they realized the mistake ( and my company's DNS server is just broken and still caching the IP from when it was blocked). Anyway, sorry for the false alarm. Update: Well, they are still blocking the domain for DNS lookups originating from my company but not for other people. Not sure why... From my company's network: bash$ dig www.btcguild.com @208.67.222.222
; <<>> DiG 9.4.1 <<>> www.btcguild.com @208.67.222.222
; (1 server found)
;; global options: printcmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 232
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;www.btcguild.com. IN A
;; ANSWER SECTION:
www.btcguild.com. 0 IN A 174.129.221.183
;; Query time: 7 msec
;; SERVER: 208.67.222.222#53(208.67.222.222)
;; WHEN: Thu Mar 29 14:47:58 2012
;; MSG SIZE rcvd: 50
From my home network: bash$ dig www.btcguild.com @208.67.222.222
; <<>> DiG 9.7.3-P3 <<>> www.btcguild.com @208.67.222.222
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 59550
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 0
;; QUESTION SECTION:
;www.btcguild.com. IN A
;; ANSWER SECTION:
www.btcguild.com. 192 IN A 50.31.135.13
;; Query time: 28 msec
;; SERVER: 208.67.222.222#53(208.67.222.222)
;; WHEN: Thu Mar 29 14:49:57 2012
;; MSG SIZE rcvd: 50
|
|
|
|
Thank you for posting, will email them to figure out why the hell they're trying to block my domain name without any contact/notification. I can say quite definitively that there is nothing on the site that should have caused them to block this.
UPDATE: Sent an email and called their phone lines to try to get the issue moved forward faster.
I'm now less sure what is going on. The screenshot above from from my work computer (we use OpenDNS for our company to also block things like gaming and streaming sites). But I also use OpenDNS at home, and it is not blocked there nor does it appear in their "check a domain" tool. So maybe this is something else that is specific to my company that is just designed to look like an OpenDNS blocking method? Or maybe OpenDNS offers different blocking rules to enterprises than to home users. Anyway, this may or may not be a false alarm. Sorry if it was. |
|
|
|
OpenDNS seems to be blocking www.btcguild.com for some reason? Has anyone asked they why?  |
|
|
|
Some mining rig photos: I went through with my plans for a mineral oil cooled setup. :-)
What you can't see here: The USB and power cable is rising up to the top, as I placed a nail there above the whole setup to run the cables along that. This is an attempt to prevent oil from trickling through the cables. So far the oil stays where it should, hopefully that will last.
All in all it seems to work fairly well. I would like your input though on what is an acceptable temperature to run the FPGA at. First I tried running without a fan and the oil would slowly start heating up and after about 30 minutes the thermometer showed 46 deg C (you can see in the picture that the thermometer is measuring in the middle of the heat sink). At that point I stopped and added a fan. It's not really helping all that much, but it is keeping the setup at about 43 deg C right now.
On the other hand I have yet to see a single invalid share. The system has been mining for over a day at 200 MHz (per FPGA) with 0 invalids. So would that indicate that I can risk a slightly higher temperature? I would really like to run this completely passive.
I was also thinking that this might be a good excuse to play around with 3d printing a little bit and maybe build something that would increase the surface area for the oil to cool down and maybe even have some kind of circular setup driven by convection. Although if I do that, which seems like a fun project, it would probably be just me guessing how to do that rather than being based on actual physics. =)
You beat me to it, I just received my tech grade mineral oil yesterday and the rest of my parts should arrive by the end of the week. I think I have a pretty good design, building it completely out of acrylic glued like a fish tank. I plan to include the cooling into the lid. One lid will be two heat sinks connected through the lid. The other plan is the nuclear option with a peltier cooler sandwiched between them. The enclosure itself is designed for convention so the cooling in the lid may be completely unneeded.. we will see. These guys did a lot of experimenting across several revisions to a fully submerged aquarium gaming PC. Might be some tips in their articles about how they did cooling, etc: http://www.pugetsystems.com/aquarium-computer.phphttp://www.pugetsystems.com/mineral-oil-pc.phphttp://www.pugetsystems.com/submerged.php |
|
|
|
I just did this and didn't get pywallet to work with an encrypted wallet, so I ended up using the import/export private key function of the official client: - Take the one of your existing wallets that you want to become your main wallet.
- Create a new address from that wallet. I'll refer to this as address 1ABC
- Go to your old wallet. Send the entire balance of this wallet to the 1ABC address. This ensures that any coins attached to invisible "change" addresses make it to your new main wallet.
- Use the JSON-RPC API dumpprivkey (using the bitcoind executable from the command line to talk to your running bitcoin) to export all of the addresses from your old wallet that you think you might still get some payment on in the future
- use the JSON-RPC API importprivkey on your new wallet to import all of the keys from the step above
Your new wallet now has a) all of the publicly disclosed addresses from your old wallet and b) all of the BTC that may have been living in "change" addresses. so this feature is in a public release? that means i could at least now use PHP to do a bulk import in some kind of loop... finally, hooray  in what version did this feature first appear? 0.5.x I think. I don't remember exactly. |
|
|
|
I just did this and didn't get pywallet to work with an encrypted wallet, so I ended up using the import/export private key function of the official client: - Take the one of your existing wallets that you want to become your main wallet.
- Create a new address from that wallet. I'll refer to this as address 1ABC
- Go to your old wallet. Send the entire balance of this wallet to the 1ABC address. This ensures that any coins attached to invisible "change" addresses make it to your new main wallet.
- Use the JSON-RPC API dumpprivkey (using the bitcoind executable from the command line to talk to your running bitcoin) to export all of the addresses from your old wallet that you think you might still get some payment on in the future
- use the JSON-RPC API importprivkey on your new wallet to import all of the keys from the step above
Your new wallet now has a) all of the publicly disclosed addresses from your old wallet and b) all of the BTC that may have been living in "change" addresses. |
|
|
|
The nice thing about p2pool is that DeathAndTaxes and I can disagree on this and we can each do what we want to with out own bitcoind instances. I personally, don't see any need to restrict transactions at this point in bitcoin's evolution.
I think it should be weighed at least. Like if transaction was sent with a 0.01 BTC Tx Fee, push it through TX as fast as you can. Like, preferred. It is already prioritized in the default bitcoin transaction selection algorithm. When there are too many transactions to fit in a block, bitcoin will choose transactions with the highest priority and tx fee is one way a transaction can get a higher priority. |
|
|
|
|
The nice thing about p2pool is that DeathAndTaxes and I can disagree on this and we can each do what we want to with out own bitcoind instances. I personally, don't see any need to restrict transactions at this point in bitcoin's evolution.
|
|
|
|
|
I received another donation for p2pool miners. I'll distribute it sometime in the next day or two.
|
|
|
|
Why my payout drop down so dramatically?
The timeframe is just one day here? With a handful blocks solved by p2pool a day you cant make emaningful conclusions. Sorry, but again it boils down to variance.. ;-) Ente He has 3.5 GH/s and shouldn't really see a lot of share-based variance. His current payout isn't affected by the number of blocks found per day, and it changing that dramatically has to be an indication that something is wrong. The only thing that you haven't shared/shown is share orphan/dead rate. Is that high? What is shown in the p2pool console window for this line: Shares: 203 (6 orphan, 3 dead) Stale rate: ~4.4% (2-9%) |
|
|
|
|
While I was napping, my internal network failed. That essentially killed pretty much everything including the boxes that keep p2pool.info fed with up-to-date data. so the last block didn't appear until I rebooted the machine and there is a small gap in stats. It's running normally again, now.
Sorry.
|
|
|
|
Anyone have a guess at when we might hit our next block?
Right....... NOW |
|
|
|
|
Show Posts
