[GLBSE] BFLS.RIG - BFL Hardware mining & Sales

[Inaba]

1. are all (or at least a large majority of) BFLS shares backed by Singles?
2. are all (or at least a large majority of) BFLS.RIG shares backed by MiniRigs?

A bit of both in a fairly even distribution.

3. can you share some details of your current plan in converting the existing BFLS and RIG hardware to SC ASIC? Specifically (but not limited to):
3a. is it your intention to convert ALL existing FPGA hardware?

Yes, I intend to convert it all into minirigs at some point.

3b. have the upgrade orders been placed with BFL yet?

Yes they have.

3c. are any of these orders likely to be part of the 'first batch' shipment from BFL?

Some of them are, not all of them.  The number that will be in the "first batch" is kind of up in the air at the moment, given the current disposition of our first batch.  Since we have a limited number of available chips for the first batch, I will not, in good conscience, be taking a large swath of them.

3d. what is the (best guess) expected rollout schedule once ASIC shipments start and conversion begins?

I don't currently have one, and will be doing this based on what's available and trying to serve the customers of BFL fairly.

And regarding BFLS and RIG share conversion:

4. will share conversion happen along the lines I've outlined here: https://bitcointalk.org/index.php?topic=89902.msg1455088#msg1455088
4a. will BFLS and RIG shares be combined at this point, or still kept separate? Currently the hashrates of a BFLS and RIG share are essentially identical (1.5% advantage to RIG) but after conversion an 'SC BFLS' will have 10% more hashrate than an 'SC RIG' share. This may be an opportunity to combine the two into one pot using a 1:1.1 ratio as discussed earlier.

The reason I ask is that I've been using the blockchain to track BFLS(.RIG) dividend payments in detail since the end of December. This has been straightforward because the hardware is all FPGAs and both BFLS and RIG shares hash at approximately the same rate.

But that will no longer be case once ASICs start replacing them, so I'd like to get a sense of the hardware breakdown to be able to calculate the expected dividend payments. There will be a transition period until all FPGAs are replaced; I'm not too worried about tracking that. I'm more interested in what the final hardware will be and how it will map to 'SC BFLS' and 'SC RIG' shares. Or if the two share types will be combined going forward.

A lot of questions in here, and not the type to be answered easily or quickly; I apologize for that. But I'll thank you in advance for any clarification you can provide.

Shares will remain exactly as they are now.  Any new shares purchased going forward (if any) will be RIG shares.

[1715433368]

1715433368

[Epoch]

Shares will remain exactly as they are now.  Any new shares purchased going forward (if any) will be RIG shares.

Does this mean that if a person has 200 BFLS shares today, they would have 200 shares of 'BFLSSC' (or whatever it will be called) when the conversion to ASIC is done?

(For reference I'm using this: https://bitcointalk.org/index.php?topic=89902.msg1455088#msg1455088)

i.e. a 200-share FPGA Single is converted to a 433-share SC Single (200/433 is the $600/$1300 price ratio). That is, the conversion would distribute 200 shares to the current shareholders and 233 shares to Inaba.

[Inaba]

That's the current plan, yes.

[Epoch]

Sounds good, thanks.

[Epoch]

FYI: BFLS payout seems to be stuck.

[Inaba]

Crap, you're right.  I'll get that fixed tonight.  I forgot that when i moved the EMC server, I had bitcoind that the payout script talks to talking only to the EMC bitcoind.  I will rectify that tonight and get it started again and point it at more than one Bitcoind this time.

[Epoch]

That's the current plan, yes.

I noticed on the butterflylabs.com forums that you mentioned you had 4 minirigs and 40+ Singles on order. Assuming those are 'upgrade' orders for BFLS, they represent roughly 4x6058 + 40x200 (= 32000) existing BFLS and RIG shares. And since you confirmed that all BFLS upgrade orders have been placed, I also assume that this represents *at least* all of the outstanding BFLS shares (I'd like to be corrected if my assumptions are wrong).

Now, I don't know the total # of existing BFLS and RIG shares, but based on Sunday's payout of 158.8 BTC at a dividend of 0.0016 BTC/share, that works out to roughly 97500 shares being paid ... which is much more than the 32000. So payout is going to non-BFLS shareholders from this common pool as well, which is fine. A common pool for BFLS and non-BFLS is reasonable as long as all hardware is the same (i.e. FPGA minirigs and singles. Or ASIC minirigs and singles).

But ... I'd like to point out that once BFLS ASIC upgrades begin, you may want to remove the 'non-BFLS shareholders' from the common payout pool. My thinking is that if they do not upgrade (at the same time as you) and remain in the payout pool, they will a) get a higher payout due to ASIC hardware they do not own; and b) BFLS shareholders' dividends will be correspondingly (and unfairly) diminished.

(The above is based on the assumption that new shares would be issued based on https://bitcointalk.org/index.php?topic=89902.msg1455088#msg1455088).

Of course, once the non-BFLS shareholders upgrade their own gear to ASIC, they can be brought in to the common BFLS pool once again.

[Epoch]

Since the end of December (when regular payments resumed after the GLBSE fiasco) I've been tracking the performance of BFLS.RIG. That is, actual dividends/share vs. expected dividends/share. For those interested in the details, I've put together a basic spreadsheet:

https://docs.google.com/spreadsheet/ccc?key=0ApYaV5Jgx7Z1dFNONFZXdVQ2dEhVWHJub0FXRjVxNkE&usp=sharing

To summarize, over the past 4 months it appears that BFLS.RIG is underperforming by about 9%. This is a long period, so random pool variance should be a non-issue. The discrepancy can be caused by a number of things: either my assumptions are incorrect, or there are more shares in existence than there should be. Here's a summary chart:



Assumptions:

nominal hashrate of minirig: 24320 Ghps (specced as 25600, but I'm assuming 5% 'overhead')
shares/minirig: 6058

Payouts can be tracked on the public blockchain by filtering for the BFLS.RIG payout address: 1FZkF2T8JmSYFPv9oUJYfqZnaJEtSoJ3Z6

Several of the outputs are obviously minirigs:

1qH6zqtR4pKuZSQHeAFsyhXm5F9KWDemw
1MichaiLHNbRqWbUueLAybqU4yJ74wqyaV
1NoN4hfM5ib7h84iqULf19XcYngxpigZay (2 minirigs here)
1LubzcqSPEcYbVBDghjpuVWuv38XtWUhVc (another 2)
19ReAQrjmRUbg7o2y37ApcXJ56ccooHK2X
113zpYnErj3TocLbt8edH8eMCSwTZ7rc4y

From any one of the above addresses we can directly calculate the actual dividends/share paid by BFLS.RIG and compare them with the expected payout (based on assumed minirig hashrate and network difficulty) during the period of time since the previous payout.

The results are that we are converging to being 9% 'under' expectations. I'm not sure what the reason for this is, or if there is cause for concern; if a minirig averaged only 22000 Ghps then we'd be dead-on ... could that be a more reasonable assumption (I don't have one to compare)? If anyone has experience with a minirig I'd like to hear what kind of average hashrate can be expected.

[Inaba]

Lots of the rigs have cards go inactive fairly often.  I reset them when I notice them, but it's fairly difficult to manage so many damned cards.  9% seems a little high, I will have to take a look at the most problem units and see how often and how many cards go down.  Normally I would pull the unit and replace it, but I kept thinking "We are replacing it with ASICs next week, it would be silly to pull it down and have it not mining for a day or two."

We all know how that worked out so far... /sigh 

The good news is, the ASICs are rock @#$@ solid so far and very heat tolerant, so once the units are replaced with ASICs that problem should go away.  I will look further into it to be sure something else isn't amiss though. 

If anyone wants to cash in shares for a physical unit, please do!

Overall, I would say the average for a Minirig is closer to 23 - 23.5 GH/s not 25, on average.  Some overperform, but most are underperforming on average due to cards going flakey.

[Epoch]

The payout script may need a kick ... 

[Inaba]

Kicked... payments should go out normally.

[RHA]

Something changes? The last payment was initiated earlier than usually.
The first SC device has come or is coming?

[Inaba]

Yeah, I split payment to 50 BTC instead of 100 BTC to increase frequency.  Meant to make a post on that but forgot.

As a side note, I'd appreciate everyone who's involved with this clicking on my Trust link and providing feedback with your experience.

My trust link is just under my picture on the left here.

[Inaba]

Ok folks... we are at a critical juncture here and I'm looking for input on how to move forward.

I am not able to host all the singles, given the new power requirements.  I would have to split it into separate DC's and even if I were to keep them in the current locations, the increased power cost far exceeds the 10% held back on the units. In short, I simply can't operate this number of singles even at break even on my part.

Obviously, this is an untenable situation for me.  I'm considering invoking the original clause:

Should mining become unprofitable or other circumstances cause the operator to be unable or unwilling to perform his duties, sale of all hardware and equal distribution of funds will commence according to the number of shares held by each individual.

I am obviously not willing to operate at a continual loss.  If anyone has suggestions on moving forward, I'm open to them.

[Vbs]

Please do not invoke that clause after sooooooo many months of waiting!

The only solution I'm seeing at the moment is you withholding more % to account for the increased power costs? I'm ok with that, as you can't operate at a loss.

[Inaba]

I'm not sure how that is possible, except to forcibly remove shares from people.  I'd imagine that won't go over so well.

[kakobrekla]

Ok folks... we are at a critical juncture here and I'm looking for input on how to move forward.

I am not able to host all the singles, given the new power requirements.  I would have to split it into separate DC's and even if I were to keep them in the current locations, the increased power cost far exceeds the 10% held back on the units. In short, I simply can't operate this number of singles even at break even on my part.

Obviously, this is an untenable situation for me.  I'm considering invoking the original clause:

Should mining become unprofitable or other circumstances cause the operator to be unable or unwilling to perform his duties, sale of all hardware and equal distribution of funds will commence according to the number of shares held by each individual.

I am obviously not willing to operate at a continual loss.  If anyone has suggestions on moving forward, I'm open to them.

Contracts. Made to be breached.

[Epoch]

Ok folks... we are at a critical juncture here and I'm looking for input on how to move forward.

I am not able to host all the singles, given the new power requirements.  I would have to split it into separate DC's and even if I were to keep them in the current locations, the increased power cost far exceeds the 10% held back on the units. In short, I simply can't operate this number of singles even at break even on my part.

Obviously, this is an untenable situation for me.  I'm considering invoking the original clause:

Should mining become unprofitable or other circumstances cause the operator to be unable or unwilling to perform his duties, sale of all hardware and equal distribution of funds will commence according to the number of shares held by each individual.

I am obviously not willing to operate at a continual loss.  If anyone has suggestions on moving forward, I'm open to them.

I have an alternative suggestion to liquidation. As you say, you cannot afford to host a 1:1 upgrade to the SC hardware.

Let's say you are currently hosting 25kW worth of FPGA equipment. You could swap it out for 25kW worth of SC equipment. That way your power costs stay as they are now, but hashrate goes up. Similar to what I proposed earlier in this thread, shares could be converted like this:

Taking BFLS (Singles) as an example:
- currently 1 FPGA Single represents 200 shares and is worth $600 ($3/share).
- a Single SC upgrade cost $700 for a 60Ghps unit (I believe 60Ghps units have been ordered, not 50Ghps, and for the original upgrade cost of $700 not $1900 as it became after the recent price jump).
- 1 FPGA Single uses 80W.
- 1 SC Single uses 300W (a guess for now)
- thus for the same 80W you can host 0.267 SC Singles (or 0.267 x 60ghps, or 16Ghps)
- the cost of 0.267 SC Single Upgrade is 0.267 x $700 or $187. Or 62 BFLS shares (a BFLS share represents $600/200 or $3).
- thus upgrading 1 FPGA Single (80W) to 80W worth of SC equipment would be $187 and gives you 0.267 SC Singles.
- this means Inaba would create/assign 62 new shares to himself for every 200 BFLS shares currently in existence; current BFLS owners would keep whatever amounts they now have.
- tl;dr: after this conversion, 262 shares will represent 1 FPGA Single converted to 0.267 SC Singles (16Ghps, 80W). This is a hashrate of 61Mhps per share.

If we go this route, power requirements stay exactly as they are now but we all gain a hashrate increase from ~3.75Mhps (now) to 61Mhps per share. Hosting costs (i.e. power) remain the same as they are now. With less physical units (1 SC replaces 5 FPGAs), maintaining them should be less work as well.

So, at least for the time being, I would like to think that most of us would prefer to go this route (i.e. convert 80W worth of FPGA to 80W worth of SC) instead of liquidating what we have now. It gives shareholders a 16x hashrate increase, represents no additional cost for datacenter hosting, and less maintenance for the operator. Later, depending on circumstances, we can consider liquidating the SC hardware.

Thoughts?

[Inaba]

Hmm, that idea could certainly work.  Let me give that some thought, but off the cuff I like it.

[Vbs]

I also agree to what Epoch suggested. This seems like a good solution, indexing share #'s to power consumption (system input), as miners are really just W to H/s converters.

It also allows you the possibility to later trade the singles for more power-efficient hardware, while staying within the same total power envelope (more hardware in this case).