[PRODUCTION UPDATE — 11/07/2013]

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

Is it being DDOS'd again?

The web site is down, and bets I have placed 30 minutes ago haven't returned yet, even though 3 blocks have been solved since.

I've imported a bitcoin-qt wallet.dat into blockchain.info.

For some reason, blockchain.info ignore the "change" that you get as part of a transaction. So now the balance is way off.

E.g if you look at:
https://blockchain.info/tx/2f2b2b49523fe9c964115efdf7fc2254caa52dba33055f1ab500cccae900ccbd

I spent BTC 0.25 from an address with BTC 1 in it, so I got BTC 0.75 in change. Yeah, BlockChain.info just see it as I spent BTC 1. Uhh... 

So I think somehow blockchain.info missed the "return addresses" (what are these called anyway?) during the import.

How do I fix it?


PS: Why are the return addresses for the change unique addresses, and not just the originating address?

[Task:]

Hi,

This offer is no longer available.


I need a C++ student-level developer to create the following starter app for me. It's basically a transparent proxy for Stratum. It's about a days work - pays 4 BTC.

Task:
* Accept stratum request from a user (port 3333)
* Store JSON data into an internal data structure.
* Read that data structure and repeat the request to another server (port 3333)
* Same in reverse.

So in the end you have a stratum-to-stratum "proxy" that you can run on some machine on the network. It's not a particularly useful app by itself, but it is part of a larger app (of which I won't reveal the details). Don't take shortcuts. I know you can do this particular task a lot simpler, but this is not the eventual task. It's just a way to isolate part of the task in an individual testable unit.


Requirements:
1) Must be a Windows console application.
2) Must be a Visual Studio 2012 project (you can download 'Visual Studio 2012 Express' desktop edition if you need a free C++ compiler on Windows).
3) You can use Win32 API's.
4) You must use the Casablanca framework (C++ REST SDK) at least for interpreting JSON. Google "Casablanca C++".
5) You cannot use boost or any other 3rd party libraries (other than Casablanca). Only C++, standard library, Win32, and Casablanca.
6) You cannot slap a GPL or any other license on it. I'll own the code after.
7) Can't obfuscate your code. Must be reasonably readable.
8. Try using as few as possible global variables. 0 is preferred.

Success (how to test):
Point BFGMINER at the proxy. Have the proxy point at Slush or BTCGuild. You must be able to mine for 3 blocks (check blockchain) across the proxy without it falling over. You don't need to wait for solutions, but it must be able to send 3 new blocks down to the client, and have the client send accepted shares back through all 3.

Non-requirements:
1) You don't need configuration or arguments. You can hardcode everything, including IP addresses for slush etc.
2) You don't need to make it multi-threaded or async.

Post on this thread if you are starting with this project so that there aren't multiple people starting off with the same thing.

[These services have now been shut down due to the cost of running them.]

UPDATE:
These services have now been shut down due to the cost of running them.

Here are instead the steps to create your own Azure gateway.

I'll show by example of how I would create westcoastbtc.cloudapp.net, port 8884 which connects to BTCGuild. My values will be within []'s. Substitute with your values when more appropriate.

1) Go to www.azure.com and create an account. You can get a free trial account
2) Enter the azure portal (on www.azure.com)
3) On the left of the portal, select 'Virtual Machines'
4) Click "+" at the bottom to create a new Virtual Machine
5a) Click through: Compute \ Virtual Machine \ Quick Create
5b) DNS Name = [westcoastbtc]
5c) Image = Windows Server 2012  (you can host on Linux as well if you're familiar with it. I'm not listing the instructions for that below.)
5d) Size = Extra Small (enough for 10 blades. You can upgrade later)
5e) User name = [shrek]
5f) Password = [donkey]
5g) Region = [West US]
6) Click 'Create a Virtual' machine and have a [beer] until it's done.

7) Click on your new server, and go to Endpoints
Click 'Add' to create a new endpoint
9) Add a Stand-Alone endpoint
10a) Name = [BTCGuild]
10b) Protocol = 'Tcp'
10c) Public Port = [8332]
10d) Private Port = same as 10c. [8332]
11) Click the checkmark to add it

12) Go to the DashPort
13) Click 'Connect'. There will be 2 popups, one from Azure, and one from your browser. Click 'Ok' on the azure one, and open your browser one (this is a Remote Desktop Client shortcut).
14) Enter 5e/5f from above for username & password

15) On the Server itself, go into 'Windows Firewall with Advanced Security'
16) Click 'Inbound Rules'
17) New Rule
18a) Port
18b) TCP
18c) Specific local ports = [8332]
19) Click Next
19a) Allow the connection.
20) Click Next
20a) Applies to 'Domain', 'Private', 'Public'
20b) Click Next
21) Name = 'BTCGuild Port'

It should now be set up. Create a batch file with a shortcut, and run the following:

start "BTCGuild Proxy" mining_proxy.exe -o eu-stratum.btcguild.com -p 3333 -gp 8332

(The 'start "BTCGuild Proxy"' part is just because I have dozens of these and I want to customize the title in the taskbar. You can leave it out).



I've set up a few Azure VM's and running mining_proxy.exe on it for Slush & BTCGuild.

The idea behind this is that if you run a ASICMINER blade or similar product that only supports Getwork and not Stratum, that you can connect it directly to this cloud-based mining proxy, instead of running your own proxy server somewhere on your premises. It thus should reduce your electrical usage.

This is a free Beta to test scalability. I reserve the right to cancel this service at any time. Leave me a message below or PM if you want me to PM you 3 days before I stop it/suspend it/take it offline for a significant period. You can also PM an email address to me if you want an email back. You're welcome to connect without letting me know, but I may yank the service out from underneath you and then you'll have a useless miner until you figure it out by yourself.

I got a performance increase from doing this. Please give feedback to tell me your experience. (Increase/Same/Decrease).

Some people have noticed a performance drop. I'd like to figure out why this happens - please don't just try and silently give up. Let me know your location so that I can see if I can get a server closer to you.


To connect, use one or more of the following servers.

All servers support both BTCGuild and Slush.

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


They're located in Virginia, Washington (state), France and Spain respectively. Pick the one closest to you.


Ports:

BTC Guild: 8884, 8885, 8886
Slush: 8900, 8901, 8902
GHash.IO: 8904, 8905, 8906

The port choices are there to deal with the vardiff from Slush and BTC. If there are a lot of connections from the same port, due to multiple users, Slush & BTC Guild will increase your difficulty, which means you may have more rejects between blocks.

Unfortunately a bunch of slow miners is still considered fast... So let's say this. If you have one blade, just toss a dice to see which port to use. If you have multiple blades, spread them across servers and ports.


So e.g. in the ASICMINER blade config page, use the following:
Ports: 8884,8884
Server addresses: westeuropebtc.cloudapp.net,northeuropebtc.cloudapp.net
user:pass:  myname_worker:x,myname_worker:x


You can similarly also do a Slush primary/BTC Guild backup by setting it up like this:
Ports: 8900,8884
Server addresses: westcoastbtc.cloudapp.net,westcoastbtc.cloudapp.net
user:pass: slushusername:password,btcusername:password

Alternatively, use your own proxy server as your backup, in case mine goes down. I do have monitoring though, but I may not be able to intervene immediately.


Stuff that I think you should know (which other people call FAQ, but really aren't all that frequently asked...)

Can't you steal my worker username/password by connecting through your proxy?

I probably could if I wanted. Do you really care if someone steals your password and sets up a miner on your behalf? Make sure your password for your miners aren't the same as your account password and you should be safe. The password for all my miners are 'x'.


Can't you intercept a winning block and take it for yourself?

I wish! But no. You can't intercept a winning block if you connect directly to one of the pools either. The block being solved contains the pool's Bitcoin wallet address, so even if you were to intercept and submit it, the 25 BTC will still go to the pool owner.


How do I know you're not siphoning of hashes for yourself?

Monitor your own Slush / BTCGuild accounts. Slush / BTCGuild throughput should correspond to what you saw locally before or more. Compare your worker speed charts before and after. (Nice timing BTCGUILD for resetting our stats today! Grrrr.).  Let me know if you see a discrepancy (it most likely has to do with latency to my servers), and stop using the service immediately.

Do keep in mind though, that if you reconfigure an ASICMINER it takes about an hour to get back to 100% speed.


Is there a performance win/penalty for running the proxy over the internet

That's what I like to find out! At first I suspected there might be a penalty, but the cloud-based proxy gave me better throughput than I was able to get locally myself. I'm sometimes seeing 13.5 gh/s max on my blades now and over 12 gh/s average, which I've never seen with a local proxy. I suspect it's because the Azure machines are connected to the internet via gigabit connections, where I was sharing a lowly 30 mbps between both the Getwork and Stratum parts of the proxy.


Why are you offering this for free?

I tried it for myself as an experiment, and I got saw a surprising performance increase. Because of this, I'm now inviting other people to see if you get a similar throughput increase. If this holds true in general, I can turn this into a more formal service. Haven't really thought about a revenue model.


How long do you plan to run the Beta for?

Around 90 days unless it's starting to cost me 100s of dollars per month, or if I start offering another service. I might also reduce the number of servers if I see the backups aren't needed, or if I scale out using TCP load balancing instead. Do remember to send me a PM if you don't want to be surprised by me taking something offline.



Where is the service located

Now in 4 locations: Western US, Eastern US, Western Europe, Northern Europe.   I can set up East Asia & Southern Asia as well if there is any interest. Let me know. (Maybe for Russia?)


Can you do this for another pool? / Set a server up in another geographic region?

Let's see if these 2 work first, but I'm open to suggestions.

Unfortunately you can't just connect multiple user accounts over a proxy to Eligius - it will hand out difficulty 1 to everybody. But if you're interested I'll set up one-off Eligius ports for your. Let me know which primary & backup location, and how many ports you need.


This doesn't work!

Oops. Sorry. Post on this thread and I'll look into it.


I hate you!

I know. I'm used to it. I also drive a Tesla. Not a day goes by that I don't have to fight off at least a dozen trolls before breakfast. Knock yourself out.

I have an ASICMINER blade erupter that works fine against BtcGuild using a mining_proxy.

I also have a bunch of block erupters (ran on BFGMiner), that I point at Slush's pool, which also works fine.


HOWEVER, when I try to point the blade erupter mining_proxy at Slush's pool, the blade erupter starts functioning erratically. Generally my blade erupter get days and days of uptime, but on Slush it crashes every few minutes. It's overclocked, but ventilation is via a wind tunnel in a cold room, so can't imagine it's that.

Switching the blade back to BtcGuild fixes it. Switching back to Slush, and I have issues again. Tried rebooting it a bunch of times etc.


Any words of wisdom here?

BTCJam asks for quite a bit of personal information in order to join.

They can obviously create havoc with this if either they're malicious, or just have bad security around their site.

Does anybody else have experience with BTCJam? Either from an investor perspective or loaner perspective?

Seems like the BTC equivalent of LendingClub, which is great, if it's legit.

There's been a pretty substantial drop in network speed today.

We're at 591.60 as of this posting. We started the current period at 591.25! (Unfortunately that is still 35% up over average of last period. Oh well).

Not that this is a bad thing, but I wonder what caused this?

My theory would be that a mining supplier (BitFury?) was using new equipment to mine until the last day of the current period, and now that difficulty is about to increase, turned it off to send to customers.