If I leave the paperclip in and use the PSU switch then, nothing happens (after the first time) when I turn the PSU switch off and on. I turn on the switch, LED flashes a few times then power cuts off (and stays off). Only way I have found to 'reset', is re-seating the paperclip. I am wondering if something is shorting out, but have tried 5 blades, 3 PSUs & 2 molex adapters. I verified polarity. Tried 2 wire and 4 wire configurations. Tested fuses. No idea what to do next.

I have now tried 5 different blades and they all do the same thing. Any ideas on this?

I have a couple v2 blades that I can't seem to get working. Have a 750w PSU, wired in as described in OP. As soon as I paper clip the 24port on the PSU to power on, LED1 on the blade flashes 4 times then the PSU powers off and won't start up again until I undo and redo the paperclip. I have seen a couple other posters with similar reports, but no resolution. Same behavior on both blades.

Any ideas?

Also, tried 3 different PSUs, including one that is known good (driving current CPU). All same behavior.

Do you have any estimates on the monthly fee or expected power consumption for 500GH/s?

Are there any plans to increase hashrate per investment over time or is this a fixed $6 per GH/s?

What risk does this level of consolidated mining bring to the block chain and what are your plans to mitigate that risk?

I'm new to Pi and Arch Linux and this distro. I ran into a few issues when starting out with wireless. Thought I would share my results in case they help anyone else.

I have a situation where I wished to be WiFi only (totally non-wired), but ran into a number of problems:
1) WiFi wouldn't seem to connect at reboot
2) time was inaccurate on startup
3) timezone was off.

Note: various commands may require sudoing.

First I set up the wireless network by booting and running 'wicd-curses' to configure the wifi device. Once it started I:
1) Typed 'P' and set Wireless device to wlan0 (after I had already confirmed that was correct with the 'iwconfig' command). I also removed eth0 from Wired Interface. F10 to accept.
2) 'R' to refresh, then found my network and hit right-arrow to configure it. Scroll down and hit space on 'Automatically connect to this network' to set it and then scroll all the way down to set the network password (or Key). Hit F10.
3) 'Q' to quit

Next I stopped dhcpcd from running on eth0 on startup by typing 'systemctl disable dhcpcd@eth0'. Dunno if this was contributing to my connect to wifi startup issues, but it did help get rid of a startup error (since I am not using eth0). Note: you don't need to enable dhcpcd for wlan0 because wicd handles that automatically.

To get ntp working right for me I used wicd scripts to make wicd a prereq for ntpd. I created one script that starts ntpd on connect and another that stops it when about to disconnect:
1) created /etc/wicd/scripts/postconnect/openntpd-start.sh with the following content:
2) 'chmod 755 /etc/wicd/scripts/postconnect/openntpd-start.sh' to make it runnable.
3) create /etc/wicd/scripts/predisconnect/openntpd-stop.sh with the following content:
4) 'chmod 755 /etc/wicd/scripts/predisconnect/openntpd-stop.sh' to make it runnable.
5) 'systemctl disable openntpd' to make it so openntpd doesn't autostart at startup anymore, since wicd now manages it.

To get timezones matching my timezone I created a symlink from /etc/localtime to my zone info:
1) found my timezone in the /use/share/zoneinfo directory structure. Mine was '/usr/share/zoneinfo/America/Detroit'.
2) rm /etc/localtime
3) ln -s /usr/share/zoneinfo/America/Detroit /etc/localtime

The  I rebooted.

All was well (mostly). wicd takes longer to get connect then I would hope (takes a minute or two after boot). Once up though, I can connect remotely without issue and 'date' looks good.

Totally fair sentiment. Though I have a lot of issues with BFL, I do think they will deliver *eventually*. I don't know enough about bitfury to make the judgement though (which is its own concern). I think we will know a lot more about that within the next two weeks. Perhaps that is the time for some to reevaluate this investment.

Did you miss that my whole argument is that 0.15 per 100MH/s when network 1500TH/s is still a good price (~58% annual return)? Totally competitive with anyone in the market (by orders of magnitude). If you did the math assuming ~250TH/s network (poor decision IMO), then the estimated rate of return is like 350% (meaning you earn 3.5BTC per 1 BTC invested). So yes an 83% 'devaluation' from ridiculous to pretty-good-and-totally-competitive.

This security provides a return that is an order of magnitude more than most of its competitors. It is totally competitive in its own market. I think it is fine to question the value of the market (though existing interest seems to be speaking for itself), but don't blame this single security.

I also understand people's concern about wording of the prospectus and what may be missing, not covered, or inappropriate. I also get the argument about the bads of centralized mining corporations and arguments comparing this class of securities to raw physical mining. I think those thoughts need to enter into your valuation of this equity, but decisions based on those issues are pretty personal and tough to quantify.

I am more concerned of there being no clear indicator of when mining will come online (and even more, if it is piecemeal as has recently been discussed, how can you commit to 100MH/s out the gate).

Given that though, thinking about when mining may come online, even with a high estimate of total network hashrate and an underestimate of what Lab_Rat would deliver, it seems like, for a bond/security of this type, this has a decent raw ROI of dividends.

I will make a couple assumptions for this analysis, that you are free to challenge but I consider reasonable or conservative (at least the first 4).
1) This stock will start delivering dividends in the month of October.
2) The total network hash rate will hit 1500 TH/s (1.5PH/s - peta hash) by that time.
3) Lab_Rat will only ever deliver equivalent of 100MH/s per share. (contrary to stated plan)
4) These shares will continue to be worth 0.15 BTCs each with no growth (or reduction).
5) A year later the network hash rate will be around 8PH/s.

Please help me check my math:

with 1500TH/s, aka 1,500,000,000MH/s (~210million difficulty)
at 3600 BTC generated per day across the network (on average)
then 0.000002394253791 BTC will be generated per day per MH/s (3600/1500000000)

@ 100MH/s each share will deliver 0.0002394253791 BTC per day (100 * 0.000002394253791)
@ 365 days in a year each share will deliver 0.0873902633715 BTC per year (365 * 0.0002394253791)
@ .15 per share price the calculated % return of this stock, in dividends, is 58.25% (0.0873902633715/.15)

Though this is incomplete (especially in assuming a one time starting hash rate for an annual return), this seems to be the type of analysis many are doing to identify value of dividends for comparison sake. 58.25% seems particularly high for this class of stock. If you add in the chance for 166 or 200MH/s stocks (likely) and increases in security values (likely) then it gets even better.

Going to the other extreme where I assume the year-later hashrate of 8 Petahash/s the same calculation nets a dividend return of 11%. This seems low for a stock with this risk profile, but high compared to peers and pretty ok given that this assumes no growth in stock and no increase over 100MH/s.

Whether you want to hold up BTC in a stock that won't pay dividends for 3 months is another thing. If we consider our year starting now, then that 58.25% return turns into 3/4 of itself or 43.69%.

Hello,
On my Raspberry Pi I am having the issue described here (describing the same issue in Ubuntu 12.04LTS):

http://bitcoin.stackexchange.com/questions/11829/bitcoin-erupters-not-stable-on-ubuntu-and-cgminer-3-3

Basically in 3.3.1 (or 3.2.1, 3.2.0) with 1 USB AsicMiner Erupter, on a USB2.0 hub all is good hashing around 333MHs stable. If I add a second stick (or more) hashrate jumps all around with all chips eventually getting SICK and restarting. Built following instructions and verifying prereqs.

I'm rebuilding an Ubuntu box to try to reproduce there.

Any tips on something I may be doing wrong or ideas on the problem?

10 @ 1.6

Excellent write up so far.  Clear and concise.  Technical but easy to understand.  I look forward to reading the rest.

This is a really interesting score implementation.  I have a few questions.

I have not had a lot of success getting your proof to render for me.  Can you describe how you came up with the decay factor, r?  Isn't it really a growth factor for any reasonable c?

Is it true that for a very low number of shares ( < 1000 ) at the current difficulty, the total fee gets really large ( > 50% ) when c = 0.001?  My implementation seems to show this.  Does this mean that a really lucky block find would mean bad news for pool members, or is my implementation flawed?

Expanding on this, what impact would having the score start at some high arbitrary number (e.g. r^10000) instead of 1 have?  It seems it could enable setting a max value for what fee would be taken, but I'm not sure how doing this would effect the cheat-proofness of the system and expected fee calculations.

For difficulty 2 and difficulty 3 shares is p simply 2/difficulty and 3/difficulty respectively?

So it turns out I made a stupid mistake.  As part of a test some days ago, I had created a cron job that stopped and restarted bitcoind on an hourly basis.  It appears that I wasn't waiting long enough for the bitcoind stop command to close out bitcoind.  The 'trying to start bitcoind when it was in the midst of still shutting down' seems to have caused the cores.

I'm sorry for wasting your time, but really appreciate what you have taught me about debugging/troubleshooting these issues.

Here is a snip from rpc.cpp:

Line 1897 is: PrintException(&e, "ThreadRPCServer()");



Just to verify that I am doing things right, to create this file I:

then built bitcoind normally.

Hello,

I grabbed bitcoin v0.3.23 and applied bitcoin-4diff.txt and updates.diff.txt.

This is on 64bit CentOS 5.5.

I am now generating bitcoind cores every hour on the hour.  I am fairly new to troubleshooting this type of thing, but a backtrace shows:


my bitcoind command line is:

/usr/local/sbin/bitcoind -conf=/etc/bitcoin.conf -daemon -pollpidfile=/var/run/pushpoold/pushpoold.pid

with bitcoind.conf only containing rpc user and pass.

Does anyone have any suggestions as to what I can do to resolve this issue?

Thanks much,
   btcmonkey

Does pfSense offer stateful connections to pushpoold/bitcoind servers?  If not, what are you using to keep miners connecting to a consistent pushpool daemon?

Also, would you mind sharing the patch for keepalive in pushpool?

Is target difficulty of 1 hardcoded into this client?  I'm experimenting with pools that vary share difficulty and am getting unexpected results.

Change:

to this:



to implement BioMike's suggestion. See the '$DAEMON stop' line. This will tell bitcoin (via rpc) to stop running.


I also ended up changing this:


to:


To get things working better for me.  My install of ubuntu wouldn't support long NAMEs.  Also when I issued a 'start' command the process would keep running in the foreground, so I added the '-daemon' argument to stop that from happening.

I'm here and looking forward to more.  Focused mostly on pools and mining.

Hiya,

I would like to respond to this post:

http://forum.bitcoin.org/index.php?topic=965.msg200374#msg200374



By saying:

Change:

to this:



to implement BioMike's suggestion. See the '$DAEMON stop' line. This will tell bitcoin (via rpc) to stop running.


I also ended up changing this:


to:


To get things working better for me.  My install of ubuntu wouldn't support long NAMEs.  Also when I issued a 'start' command the process would keep running in the foreground, so I added the '-daemon' argument to stop that from happening.





Would you mine giving me access to do this?

  Thanks much.