I will see about getting the escrow fees covered.  May be able to work something out with TaT, at least for larger buys(50+).

Minimum is 10 shares;  Sorry souspeed/nottm28

Bumping this up.  I see no reason to lower the minimum, as the price on Havelock and Bitfunder is currently 1.3 and 1.4

The forum downtime and the issue with credit cards may have masked this... here is the calculation for payment for the 36 august customers who shipped late:
https://bitcointalk.org/index.php?topic=251966.msg3282007#msg3282007

If there are no objections we will proceed with those numbers.

Hi all,

I'm opening up this auction of Asicminer direct shares as I need the cashflow for another venture.

This auction will run for 72 hours, ending Oct 10 5:00:00 servertime:
Timer removed. End time: 2013-10-10+05:00:00UTC

The auction will start at 1.1 BTC/share, and bids must be in increments of 0.01 BTC.

Minimum bid is for 10 shares.

I am also willing to sell shares buy-it-now style for 1.4 BTC per share instantly, as many as are desired; PM me for details.

All transactions can use escrow if desired; I have completed several sales in the past and have a reputation to uphold as well(Working with Buzzdave@ Mega Big Power, can see some of my posts in that thread).

All bids must be in the format of <numshares> @ <price>, and all bids are binding.

Jared

Hi guys.  I believe this is the calculation for the payout to customers.  If there are no issues or errors with my math below, we will begin sending these payments to customers very soon.  I apologize for the delay on this.

I'm counting the start time as of the time that Dave made the post about M-boards:
September 09, 2013, 10:37:25 AM (GMT)

The end time is as of when the shipped post was made:
September 18, 2013, 11:08:32 PM (GMT)

Everything from Sept 9 to 2013-09-14 23:41:37 was done at difficulty 86,933,017.77, and everything after that was done at difficulty 112,628,548.67.

86M difficulty period was: 479,052 seconds.
112M difficulty period was: 343,615 seconds

(Total of 9.52 days)

By my calculations/sources I've checked, a 25GH/s rig should produce 12,570,000 1-difficulty shares per day, or 145.486111111111 1-difficulty shares per second.

Per-rig income for 86M difficulty: (145.4861111 * 479052 sec) / 86933017.77 difficulty = 0.80171394353 BTC

Per-rig income for 112M difficulty: (145.48611111 * 343615 sec) / 112628548.67 difficulty = 0.4438591339387 BTC

Total payout for the 9.52 day period to customers: 1.24557307 BTC per 25GH/s order.

Please feel free to check my math on this and let me know if I have made an error.  Dave has confirmed we'll start sending payments in the next few days once people can review my math.

As I posted above, sorry for the trouble here.  We have some changes coming that will make the reconfiguration and more automatic.  I have the code for it about 80% written, but unfortunately troubles with the 100TH mine project keep pre-empting that work.  We'll have this improved for October orders shipping for sure though.

I'm sorry for the trouble you are experiencing.  The default gateway that you and others are experiencing is an oversight on some changes we made in the last two weeks, but didn't update our testing before we shipped these out to you.  I don't know why you didn't get an SD card with your order.  Can you PM me your order number so I can follow up on that part?

The fastest way for you to fix this issue is going to be the following:
1. Download and burn a copy of Ubuntu(12.04 or 13.04 will work)
2. Put it into your computer and override the boot sequence so it boots from disk
3. Select boot from disk rather than install.  Make sure your sd card is plugged in but not chosen as the boot device.
4. Once it boots up, open a terminal(Click the applications button in the top left and type terminal)
5. Try to see if it automounted the device.  Do "cd /mnt/" and "ls".  There should be a few things in there and my ubuntu tries to give sd cards a very long name.  You can tell if you've found the right one by doing:
"cd <name>" followed by "ls home/pi/*".  It should print out a few things and not "no such file or directory".  If it isn't there try removing and reinserting the SD card.  If that doesn't work you'll need to mount the sd card.
6. Once you've found it, you should be in the root directory("cd /mnt/<devicename>/").  Do these commands:
sudo sed -i 's/10.10.11.249/192.168.1.249/' etc/network/interfaces
sudo sed -i '/s/255.0.0.0/255.255.255.0/' etc/network/interfaces
sudo sed -i '/s/10.1.1.1/192.168.1.1/' etc/network/interfaces

Once that is done, pull the SD card out and try to boot your rPI.  You can avoid shutting down the ubuntu prematurely by loading firefox and trying to hit 192.168.1.249  (It takes about 3 minutes for the rPI to fully boot up, so give it a little time before trying this).

Note that you'll need to change the above numbers if any of them don't match your network settings.  You can check this in windows with ipconfig or linux with ifconfig.  The info you need is the default gateway IP address(most likely 192.168.1.1) and the subnet mask(most likely 255.255.255.0).

If this doesn't help we can probably overnight you an SD card to fix the issue, but unfortunately it is Friday now so that is little good for the weekend.  Let me know if the above helps.

Hi guys,

Just want to give you an update from the floor.

1. We have a lot of hashpower deployed now- should keep us above 50TH.  More M-boards arrived, which should enable us to ship out the remainder of August customer orders.
2. A lot of the issues we are encountering now are software based- my domain.  I've ramped up to full time starting Monday of this week, so this should start getting better fast.
3. The bitfury devices are very finicky.  We can lose over 10TH without any devices going offline.  Rest assured that we aren't removing hardware and getting this smoothed over is our absolute highest priority.
4. Per 3, there is a huge amount of room for us to gain in performance without even adding hardware now.  I can't say how fast it will happen because software bugs & issues can be completely random on the resolution time, but it will come with fits and starts.

Thanks,
Jared

Please send an email to customer service about this issue:
https://megabigpower.com/shop/index.php?route=information/contact

Dave won't be able to respond to anything until at least Monday, and probably a few days after that.

While I don't know that MBP can yet offer Amazon-level customer service / replacement policies, I'm certain there's something we can do here.  Unfortunately this happened right when we are in the midst of an M-board shortage, so it may require a little discussion on what we can do for you.

If you don't get a prompt response, or if you don't feel like things were handled fairly/appropriately, send Dave or I a PM and we will follow up.  We do take customer service seriously, despite our overwhelmed schedule.

As a side note, speaking not from a MBP perspective but from a JaredR26 perspective, I recommend you see if you can find someone in your area who also has a starter kit.  If the thing that was fried was the rPI or the SD card, that is the easiest and cheapest component to replace- We can probably overnight you one.  If it was the H-card, but your M-board is functioning, those are somewhat easier to replace than M-boards right now.  If it was the M-board only, that'll be useful information.  If everything was fried, that'll also be useful information.

I do apologize for this situation- While we tried to avoid mistakes like this happening, the simple truth is that an early-design product like this isn't designed to be user-friendly and user-safe.  For that I do apologize, and we hope that we can help with this situation, and improve future designs to prevent this kind of bad experience.

FYI, from our experience the boards that deliver 30 GH/s without being overclocked first are a fluke rather than the norm.  The average of the boards performs right at spec, with some performing under spec(We generally don't ship those out).  I do apologize for the delay, though.  For what it is worth, having it hash 2-3 days sooner at a lower difficulty and delaying your shipping time until the difficulty is higher does actually have some significant benefits.

I can't help with the other questions at this time, I'm not yet privy to that side of things; You'll have to follow up with customer service / support.

So I talked to Dave about this.

#1 - I have confirmation again that we are paying the theoretical production from the miners.  Your payout is not tied to to the MBPStarters account.
#2 - So to clarify, the purpose of the MBPStarters account at this point is to explicitly set aside some of the mining output.  This way only small adjustments/money movements are needed to close the gap between what was actually mined and what needs to be sent to customers.  But it is purely for our purposes, not for tracking anything public(anymore).

Does that help clarify the plan?

One way or another, you will not lose earnings from this.  We are not BFL or Avalon.  I will follow up on this when possible.

This was my mistake- They are still hashing, they just got pointed to the wrong place(I was fixing a different issue and it picked up those too).  As mentioned in this post, we'll sort the issue out in all of the delayed customers' orders to your benefit:

https://bitcointalk.org/index.php?topic=251966.msg3125963#msg3125963

I'm not opposed to it, but I don't have experience setting it up.  I do know that other Asics like Asicminer blades originally had trouble working with P2Pool, and I haven't read of people who have made it work for Bitfury's software base(has anyone done so??).  Especially at our scale- We have hundreds of devices online now and multiple stratum proxies to manage the distribution and connection flow.  I worry about the stale rates- Our connection is good but with that volume of devices and extra stratum layer(s), would that cause a stale rate worse than the BTCGuild?

Moreover, it would still be a temporary stopgap- we'd still want to solo mine very soon, so all the changes would have to be redone for solo.

If someone can convince me that the stale rate fear is overblown and the switch process is seamless enough, I might be able to get to it sometime Sunday->Tuesday, but it won't change the prioritization of solo mining(which would eliminate any stale rates and return to the raw statistics/luck we should be running with).

See this post:

https://bitcointalk.org/index.php?topic=140366.msg3131545#msg3131545

The solo plan is a very high priority still, but it is hard for me to justify the time and cost to go solo for a 2-3% gain rather than optimizing rigs for a +45% gain or more.

Quick update for you guys from Dave and the team.

You can see our current hashrate here:
http://www.btcguild.com/index.php?page=rankings&section=teams

Team: MegaBigPower

We have discussed and decided that we will push back our estimate of when we will switch to solo mining.  Solo mining is a big priority, no doubt, but solo mining gains approximately 3% of revenue and represents a substantial risk.  The act of switching to solo mining is not a trivial matter because if a mistake is made or bug occurs, it can be hours or even a day of wasted shares before you know there is something wrong.  This alone would account for more loss than the 3% guild fee, and from discussions/posts from Asicminer's switch to solo mining, we know it is not likely to be a problem-free process.

In addition, switching and setting up the internal pool would take approximately 1-2 days of our limited time schedule, for a net ~0.9 TH overall gain.  We believe in the current state that other improvements and deployments we can make would account for far more than that 0.9 TH gain.

We will pick up and resume the move to solo mining within the next three weeks, likely within the next two; I will provide an update as we get closer to the switch.

I have no information or insight into this.  In fact, I doubt that Dave could answer this either.  Speaking from my experience with other ASIC suppliers though, it is exceedingly difficult to give estimates accurate to even a week with Asic timelines involved- Many different suppliers, individuals and sources must come together all at once for the date to be hit.  We put the same pressure to deliver fast and reliably on our suppliers that we feel from our customers, and they often give us overly-optimistic date estimates.  We add time estimates to compensate for this, but it doesn't mean we will be more accurate than what we were given.  If anything the Bitfury team tends to come closer to their estimates than other suppliers, if that is any consolation.

If we give you an estimate and something outside our control causes us to miss that estimate, it reflects very poorly on us regardless of whether it was preventable.  I can assure you that A. we will be doing everything we can to anticipate blockers and delays to prevent or work around them, and B. we will communicate timelines with you as soon as we are confident that we can hit them.  We won't be "shipping in two weeks" forever like other companies.  Thanks for understanding.

October orders are not affected by any August delays at this point.  If anything they are a learning experience to streamline the process.

Dave is not doing anything like that.  Dave is very busy working on deploying hardware and fulfilling obligations.  I am doing this of my own free will to take some of the load off of him, as I won't be able to help with the deployments until Sunday.

I am sorry that you and I cannot see eye to eye, and also sorry that you felt that my above negotiated offer of the theoretical maximum output was insufficient.  If you would like a larger cut from 100TH mine's output, I suggest you ask Tytus personally and/or pose a vote to the shareholders of 100TH mine, as our position with 100TH is limited to that of the hoster, deployer and operator, not an owner or decision maker.  Anything they agree to we will of course abide by.  As of now we feel that we have made the most fair offer we possibly can to provide for all of our customers.

You are also free to request a refund at any point and we will honor it without delay.  Thank you for expressing your concerns to us.

This is explicitly not true.  Dave does not own the 100TH mine, and is not going to be making anywhere near that kind of profit.  This is a matter of weighing the impacts between two different customers.  All of our customers are important.  But in one case we have a very slight impact that these customers get BTC-earned w/ boards-in-hand delays for a total of 900 GH/s(~$550 a day), and in the other case we have to bring offline nearly 15 TH/s(~$9,100 per day) of equipment owned by the other customer.  There is simply no way to balance that massive discrepancy in opportunity cost such that the right thing to do(for *all* customers) is to ship out individual hardware two weeks sooner.

Please understand we will ship the hardware as soon as it is feasible to do so, and the offers we have made thus far compensate you at the maximum possible earnings from the delay.