So I know that conventional graphs has us at 7.5 billion difficulty (58000 ph/s) in a year.

However, there is an aspect to consider. It costs real money to increase the network capacity, while the amount of BTC/month that can be earned through the entire network is approximately constant.

So currently, there is: 25 btc x 10 times per hour = 180'000 btc per month up for grab = $54 million (at $300) per month.

So let's see what month-by-month doubling costs. Starting with a basis of 4phs at beginning of November, and let's try and double that each month.

Nov: +4phs = $44m (KNC at $11)
Dec: +8phs = $40m (BitMine / HashFast at $5)
Jan: +16phs = $56m (CoinTerra at $3.50)
Feb: +32phs = $96m (CoinTerra at $3)
Mar: +64phs = $128m (BlackArrow at $2)
...

After this point, there is a very real prohibitive cost to double the network. Getting 50'000 people to buy $100 worth of ASIC Blocks is one thing. Getting 10 million people to spend $100 with no hope of breaking even is something else. The amount of actual money it will take to grow becomes too large for the growth to keep being irrational.

So one of 3 things have to give:

1) Manufacturers will have to start cutting mining hardware prices by 50% per month. So that means a 2TB miner selling a year from now for $25 (1.25c /ghash). I don't see that happening - laws of physics and all that.
2) The price of Bitcoin has to double each month. So $76'800 / BTC 1 year from now. Fun.
3) The network difficulty has to taper off significantly starting after March.

My bet is on #3.

Hopefully the protection would kick in immediately at the end of January instead of actual delivery date + 90 days.   But it's not 100% clear from the email.


Though, come to think of it, the protection at the end of January will still require that you buy 4 rigs in order to host the MPP chips they'll send you. The rigs looks like they'll be around $1000 each, so another $4000 to get you up to 2TB at the end of January (at best).

Or you can buy 400ghs of hashing power today for $4000 (cex.io), or even more GHS with physical hardware that's in-stock, and you'll most likely be better off.

BFL is starting to look good...


PRODUCTION UPDATE — 11/07/2013
We want to update our customers on the progress of our machine production.
 
Producing a rig as powerful as the Baby Jet or Sierra requires coordination with a host of fabricators and designers — like the machines themselves, it's a lot of moving parts, and fluid timelines.
 
This is the situation:
 
Silicon Wafer Fabbed Out Successfully
The silicon wafers have completed fabrication. The silicon is the core of the chip, and the complicated etching process that creates the circuitry on the silicon is finished. Now the process is starting of taking this silicon, with its complete circuits, and packaging it into finished chips. The wafers are en route to San Jose, where they will be cut into individual die. We’ll get photos for you soon.
 
Substrate Update
When we designed our substrates, we knew they'd be one of the most unpredictable segments of the chip's production. Substrate production has a lot of risk — at high power, a substrate can overheat, causing a rig to underperform. While rerunning simulations in Cadence, we saw some concerning currents in some of the vias in the substrate. In order to address that, we've been working closely - every day - with both our substrate designers and our manufacturing house. We’ve made key improvements to the design that can be incorporated even into those substrates that are already in manufacturing. Even so, the latest delivery estimates for the modified, improved substrate design are three weeks from today. This means that we would be shipping our first rigs mid-December.
 
Obviously this is an incredible concern to us, and to you. So for the last several weeks, we've been engaged with an additional team to work on an additional substrate, simultaneous with our existing fabricator. Essentially, we now have two teams racing to produce the best and fastest substrate. As soon as that is done, we'll marry the substrates to the finished wafer and begin assembly of the rigs.
 
Miner Protection Program
For those of you covered under the Miner Protection Program™ (https://hashfast.com/miner-protection-program/), this delay will not affect the starting point from which benefits are calculated. For First Batch Baby Jets, the start date of the program will be retroactive to October 30th. We want to make sure a delayed ship date does not reduce the value of the program.
 
A lot of smart, hardworking people are working incredibly long hours to improve our production schedule. If we are able to ship rigs sooner than expected, we'll do so. And, of course, we'll let you know as we receive further information from our production line.

- The HashFast Team

Done.

Ports: 8904,8905,8906
All 4 servers.

I'm about to take down btcguild1, but there is a client connected to it (agozyen_2) for the last few weeks.

If this is your client, can you please move over to one of the newer servers.

Did Eligius just go down? All my clients (in different geographical locations) simultaneously disconnected from Eligius and is unable to reconnect.

Correct. I've just looked at the log for your client, and you've not yet come up with a successful share yet.

I think BTCGuild doesn't accept anything less than difficulty=2 anymore.

I've just restarted that port to make sure, and before you even re-connected the difficulty bumped up to 2. This is controlled by BTCGuild.

I have one slow (16mh/s) client that I use for testing, and that one sometimes goes up to 10 minutes without finding any shares.

How do you figure?

Is it because they wrote:
"AVAILABLE FOR PREPAID PRE-ORDER ONLY"

Or maybe because of the:
"Shipping Starts November 2013"



So is 20 HashFast Sierra's, and costs about the same ($141'600 for HashFast, vs. $148'000 for the VMC with 6 expansion cases).

The original 4 servers (btcguild1, btcguild2, slush1 & slush2) will be decommissioned in 1 week.

Please switch over the 4 new servers:

eastcoastbtc.cloudapp.net
westcoastbtc.cloudapp.net
westeuropebtc.cloudapp.net
northeuropebtc.cloudapp.net

See the first post (updated) for port numbers.

I'm really starting to dislike mining_proxy.exe....

I'm connected to the exact same 2 servers, and have been getting 12gh for 5 days straight. The CPU usage for those servers over the last week have both been below 18%.

Anyway, could you try connect to either of:

slush1.cloudapp.net
slush2.cloudapp.net

Port: 8884, 8885 or 8886

No, they're up. I'm connected to them right now.

Which ones are you trying?

Are you perhaps trying to connect to BTCGuild? Keep in mind there is a DDOS attack against BTCGuild right now.

How is your individual worker name & password set up?

I have a worker that's displayed on the 50BTC site ( dbbitblade1 ). However, if I use it the proxy doesn't connect at all, and individual bfgminer using usb block erupters just states:

[2013-09-26 16:25:46] Probing for an alive pool
[2013-09-26 16:25:54] Pool 0 slow/down or URL or credentials invalid

This is with pool.50btc.com:8332

What is the exact bfgminer command line you're using for your USB erupters?

I would, but I can't ever connect to 50BTC. I've come to believe 50BTC is a myth .

That's what drove me to Eligius in the first place. Also PPS, but with a 0% pool fee.


Seriously though, they just have very bad instructions on their web site in terms of which servers support which ports. If you can let me know the address & port of a 50BTC server that accepts stratum, I'll set up a proxy for you.

Ok, I now have 4 new proxies open (the old ones are still there for now):


eastcoastbtc.cloudapp.net
westcoastbtc.cloudapp.net
westeuropebtc.cloudapp.net
northeuropebtc.cloudapp.net

They're located in Virginia, Washington, France and Spain (I think - I can't really tell for sure, but it's supposed to be East US, West US, West EU, North EU).


Pick the server that are closest to you as primary, and some other one as backup. The servers all support both BTC Guild & Slush. To select which pool you want, specify an appropriate port:

BTC Guild: 8884, 8885, 8886
Slush: 8900, 8901, 8902

Please toss a dice or something otherwise random to see which individual port to pick. Or if you have more than one blade, spread them across ports.


e.g. (for a BTCGuild setup):

Ports: 8884,8884
Server addresses: westeuropebtc.cloudapp.net,northeuropebtc.cloudapp.net
user:pass: myname_worker:x,myname_worker:x


PS: I'm now also using 5 block erupters to keep cycling through all of these ports to make sure they're alive. If one of them goes down I'll get a timeout message from BTC Guild. Finally Block Erupters are useful for something

Right. This took me quite a while to figure out by myself . Baffled me there for a while.

Anyway, since I already typed this whole thing out while you posted - might as well also post...

What happens is that when you connect with a slow machine to one of these faster proxies, it will ignore all share submissions you have that's lower than the current setting on the proxy.

So e.g. in the example below, if the endpoint difficulty (VARDIFF set by the pool) is currently 16, only the 4th submission is accepted (even though BFGMINER think they're all 'Accepted').

Accepted 85a38f7f ICA 0  Diff 1/1
Accepted 6ec85868 ICA 0  Diff 2/1
Accepted c180534c ICA 0  Diff 1/1
Accepted 0f8bc425 ICA 0  Diff 16/1
Accepted c6854677 ICA 0  Diff 1/1

"Foul", you cry!

Well, not quite. What happens is that when your pool is running over difficulty 1, the pool will give you credit for x times as many shares as you are submitting over that difficulty (and ignore the rest). Since presumably 1/16th of the number of shares you'll find is at difficulty 16.

So in the case above, even though 4 of the 5 submissions are ignored, you get 16 shares. Note that the flip-side is also true. If the pool difficulty happens to be 1, and you find a 16/1 share, you'll only get 1 credit for it.

On a slow machine, you'll see that you won't get any shares for quite a while, and then it will suddenly jump by 16. This should in theory overall take the same time as finding 16 shares 1 at a time.

So your submissions can either be counted as:
0,0,0,0,0,0,0,0,0,0,0,16,0,0,0,0 = 16 shares
-or-
1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1  = 16 shares

And it averages out to be the same.

On blades this kind of averaging out happens in seconds, on a smaller device it's very noticeable.

Ok, thanks. I'm generally on BTCGuild. I just tried Slush, and it seems to work fine for me. (It's not just a "well, it works fine for me under controlled circumstances when stars line up" - these servers are over the Internet even for me).

Couple of more questions:
a) What is your internet service speed?
b) What Operating System are you running?

Meanwhile, I'll bring up 2 more servers - US East Coast and Western Europe (since slush is in Amsterdam). It will take me a few hours. I'll appreciate if you can try it out after that. Will post here (and PM you) when they're ready.

1) Where are you located? These servers are in the Western U.S. If you are from Europe, this may not be an ideal server for you to use, as all your traffic will have to effectively travel around the world twice.

2) What is your Slush minimum difficulty set to for your blade? For a Blade this should be set to 8. I see there is someone connected currently to slush1:8332 right now that has a difficulty set to 1. That will cause fairly low throughput on a high latency connection.

It is fine when it's me alone. I just run one instance per blade and point each blade at a different proxy.

However, I am also experimenting with some cloud getwork->stratum proxy servers for other people to connect to. See:
https://bitcointalk.org/index.php?topic=292170.msg3127181#msg3127181

However, there isn't a way to automatically split incoming users to different proxies. So what happens is that people all tend to connect to the same port. It's slightly annoying with BTCGuild & Slush since it ends up with 128- or 256- difficulty proxies, but it would be MUCH worse if those proxies run at 1 (since I have to pay for the bandwidth). Hence, currently I can't open those cloud proxies for Eligius.

I guess I could create some sort of registration mechanism and give each user a different port, but that sounds too much like work...

I may also one day rewrite the proxy server to do per-user mapping (or rather do it a Stratum->Stratum redirect proxy once I understand the Stratum protocol better), but again I'm not quite there yet either.

I was just hoping for a quick fix to provide Eligius support in the mean time.

That makes perfect sense. Thanks!

Ok, so I have more news on the 'ADDRESS' vs. 'ADDRESS_worker' issue.

It seems what happens is this:
a) If I funnel 4 blades through 1 stratum/getwork proxy server with 4 different user accounts *, I get the issue where they all stay at difficulty "1".
b) If I funnel 4 blades through 1 stratum/getwork proxy server with the same user account, they'll VARDIFF up to 16.
c) If I use 1 proxy server per blade under 1 user account, everything works fine, and they VARDIFF up to 4 or 8 within a few minutes.

* Actually, I've only tried different workers - don't know yet what will happen with multiple wallet addresses. I'll try that next.

So it seems like somehow the pool doesn't like multiple user accounts coming from a single (IP+Port) endpoint. Other pools also don't really work great with this, e.g. BTCGuild & Slush will ignore the individual user accounts, and just VARDIFF you on the overall endpoint. Eligius is unique though by not adjusting the VARDIFF at all in the single ENDPOINT-multiple users case.

I've worked around it for now, but I am running a free Stratum/Getwork cloud-based proxy currently for BTCGuild + Slush. I'd like to open it up to Eligius, but can't do that if there can't be multiple users per endpoint. Otherwise all my users will get a "1" difficulty.

It's on mining_proxy, not BFGMINER (the actual miner itself is an ASICMINER blade). It's still showed "Diff 0" after almost 3 hours.

I just tried logging in again as 'ADDRESS' instead of 'ADDRESS_worker'.

In that case VARDIFF updates within a couple of minutes. Switching back to 'ADDRESS_worker' and it stays at 0-ish (see-below).


So it seems like the 'ADDRESS_worker' configuration has a larger bug that this - it's not just that it will only calculate individually, it won't update VARDIFF at all, staying at 1.



As far as my difficulty display of "0" is concerned, it is actually 1. For small values of 1...

Setting new difficulty: 0.999984741211
Setting new difficulty: 3.99993896484
Ughm. Doing our floating point math on a Pentium, are we? 

When it gets up to 8 however, it works:
Setting new difficulty: 8

Not sure if this is an Eligius bug or a mining_proxy bug. However, neither Slush nor BTCGuild shows a non-integer difficulty update on the same mining_proxy software.