Part 6:  Evaluating ET's potential return

By now you probably have noticed that I think this deal is not very good for miners.  But you should always look at both sides of a deal.  ET must be raking it in on these terms right?

Uh No.  It's a lousy deal for him as well I think.

My calculations suggest he would be doing well to make $30k / year off this plan after the reward halving in December.  And for that he is going to have to maintain his server, fend off the DOS attacks, deal with user complaints, and provide technical support to everyone using the system. Whatever he earns is going to be eaten away by whatever downtime compensation he offers. Not to mention his out of pocket costs for hosting.

All of that work is going to detract from what he does best, and what I'd like to see him focus on.  Building faster bitstreams.

So the pertinent question here is: How can the community fairly compensate him?

I would like to see something that both encourages him and others to continue working on improvements, and also encourages collaboration so that others with an interest can build off of the baseline.

Part 5:  Calculation of the reward split between ET and a user

Now let's calculate how the split works out between ET and the user.

From his FAQ, you can get the commision rate he charges: 12 MH/s / chip. http://www.tricone-mining.com/faq.html.  To calculate the split we only need to find the net gain in hashing from the use of his bitstream.  The gross change is the difference between the bitstream previously running on the board and ET's.  Since we don't have any actual reports in the wild, I'll use his typical number of 270 MH/s.  My Ztex boards on average run 228 MH/s, so subtraction gives us the reward value of 42 MH/s.  This gives us a split of 28.5% to ET.

But that is the gross value.  To get the real reward split it it necessary to account for the user's costs that will increase as a result of the bitstream.  This would be higher power consumption, reduced hardware lifespan, extra labor managing the signature system, additional downtime and possibly additional space.  All of these items are difficult to quantify, and likely to be highly variable across different users, so I'm going to focus only on two items: additional power costs and downtime.  The increased power consumption has been noted by ET already.  Lacking concrete numbers in the field I am estimating the increase to be 20%, and baseline power costs to be 10% of the earnings generated by the board.  So the additional power is the equivalent of 2% of the hash rate.

As I discussed before, the additional downtime from ET's server can be brutal on returns.  If you need to restart your boards locally due to a server interruption and you are out drinking sleeping, that 8 hours of lost time is 5% for the week.  Let that happen twice and ET's share of the net reward will be 125%.  For practicality, I will take an optimistic view and assume 98% uptime.

This results in a net reward of 31.2 MH/s and ET's share is 38.5%.  Not exactly the 5% some folks have been assuming from the headlines!

Have you run the bitstream on any of your boards?  I would be interested in the before / after MH/s and power draw at the wall for my calculations.

It is not the cost of additional power. It is the cost of renting the space to have that power.  Once you max out the power at your panel or in the rack you are done.

20% is a bad deal when you provide all of the capital and take all of the expenses.  It's a great deal when you are mining on government land.

Plus, ET's share of the reward is far more than 20%, it can be more than 100%.  Refer to his FAQ.  5% is what he wants of all your shares.  Including the hashes you would get without using his bitstream.

As for the comments on detecting skimming, look at Bitcoin neighborhood pool watch.  He has spent extensive time statistically analyzing pool payouts and can't for certain prove any of them were stealing.  But the statistical evidence is compelling.

As for folk saying it isn't possible to skim, I would like to see that proven.  I don't think the data is there to be certain if the proposed mechanism is secure against that risk.  I asked ET about this vulnerability and waited a day with no response before putting the question out there.

Part 4: Dealbreaker #3 and #4: Maximum hashing capacity and incomplete implementations

These issues will apply to limited numbers of people, but they do apply for me.

ET's bitstream increases power consumption significantly in order to gain the higher hashrate.  This hurts your return because you are paying for the power, but it has a more subtle effect.  If the size of your mining setup is limited by power available, either related to rackspace, or just circuits in your home that can be used, your maximum hashing capacity is decreased running ET's bitstream.  For example if the MH/J rate is increased by 20%, then your maximum hash rate is reduced by 25%. Twenty percent for the reduced number of cards you can run in your power envelope, and a further 5% for ET's cut.  Your ROI is slightly better, but your cash flow from mining is cut 25%.  You can always rent more racks, but this comes out of your pocket, not ET's and will significantly reduce or eliminate your share of the reward for using his bitstream.

Further, you will notice that there are no reports of anyone running this solution.  That is because it is not done.  ET is expecting the community to code solutions to allow him to earn for free.  I admire the balls, but wonder who is going to spend there time freely working on implementation of a solution he intends to keep as private property.

Part 3: Dealbreaker #2: Downtime

Downtime is the bane of an miner.  Your network connection goes down, mining is down, power is out, you are down, software freezes, hardware fails, a restart script doesn't function properly... the list is endless.  And when you are down, your ROI declines and the time to breakeven steadily moves away from you.

Even the best pools are down for significant time.  ET is adding another point of failure in this system.  If his server is down you don't hash.  And there is no backup because this is a bitstream failure, not something that can be addressed with backup pools.  He can offer a guarantee, but to cover your losses he has to be paying you 19:1 for every minute of downtime.  Even with compensation, it might not cover the downtime you experience.  The server could go down for 1 minute but if your software doesn't recover gracefully and you aren't on the spot to correct your rigs, your downtime could be many hours.  Very little additional downtime is required before taking this deal gives you fewer hashes than you were getting before.  In other words, you could end up paying ET more for the priveledge of running his bitstream than you gain.

Lots of things can be done to try to minimize the impact, but all of them require addtional, non-value added coding purely to conform to this system.  Who is going to do that coding for free so that ET can get paid?

Part 2:Dealbreaker #1: Skimming Shares

Experience has taught me that the most trust I should give someone new I meet is equal to the trust they give me.  People tend to use trust models based upon their own behavior.  So if they won't trust you not to do X, it is because they would do X at least some of the time were they in your shoes.

ET's system requires that you get work from his server, return that work to him encrypted where he will then decrypt it, take his share in some fashion and then return the remain work to you for processing.  This process must remain secret, or his entire IP protection scheme unravels.

There is no way for me to be certain he will not arrange the mechanism of taking his share of Hashes such that found blocks will be disproportianately allocated to 'his' share.  Detecting such a theft will require extensive statistical analysis and constant vigilance as the allocation could be changed at any time without any visibility to me.

I would like to trust that ET is an honorable person and would never do such a thing.  But his entire scheme is based upon the premise that I would steal his IP.  So I can't assume that he would not steal from me.

I find this assumption regarding the IP security of bitstreams puzzling.  Is there a history of bitstream pilfering?  Ztex seems to have the most efficient bitstream to date, and his methods are not implemented in other systems to my knowledge.  Unlike other types of digital property, there is a clear disincentive for me to not share bitstream IP.  Any increase in total hashing increases difficulty and reduces my benefit.

Part 1: The ultimatum game and evaluating a fair deal.

ET's proposal is a form of the ultimatum game.  http://en.wikipedia.org/wiki/Ultimatum_game

In this process a reward is available to 2 parties, but can only be collected if both parties agree to a division of the reward.  Party A proposes a split and if party B accepts the reward is divided out.  In theory party B should always accept anything offered as it is always a net gain over the alternative which is nothing for both sides.  In practice, party B only accepts if they consider A's offer to be 'fair'.  The process is a fascinating tool because it allows exploration of what people consider to be fair under various circumstances.
When used between equal peers, B starts rejecting offers around 40% share and nearly every B will decline offers of 20% or below.  When A is in an economically dominant position the level considered fair shifts, often dramatically.

In this case the miner is in the economically dominant role.  The miner:

- Pays all of the capital costs for the equipment
- provides space, power and labor to keep the equipment operational
- takes all of the losses from equipment failures outside of the warranty period
- takes 95% of lost earnings resulting from any source of downtime
- Hashes gifted to ET increase future difficulty for the miner
and from a personal standpoint:
- I'm not particularly interested in having a business partner.  Especially one who is attempting to impose such a transaction on me because he is unwilling to trust me.

In ET's favor he:
 
- owns the IP that makes the reward possible
- shares in Bitcoin risks by not taking payment upfront
- can make this deal with many parties and therefore doesn't need to make his most competitive offer to gain an optimal return.

So what is a fair division of reward in this case?  I would say that 20% is a undesirable, but not outrageous split for ET.  As a user I would consider 10% much more reasonable, and somewhere in between is probably a good division of the reward.  The problem is that the actual division proposed by ET is far higher that 20% for himself, and in some cases will result in him collect in excess of 100% of the reward.  I will discuss show this in detail in Part 5.

Deciding for yourself what is fair is the first task in evaluating the proposal as it exists today.

I am going to make a series of posts regarding my analysis of this proposal.  I hope people will indulge me.  If you aren't interested in economics or business analysis, please skip the next few posts in the series.

My first impression of the offer was that it was not a good deal.  After some calculations, I concluded it was a bad deal.  And after some further thought I decided it was a bad deal with 4 showstopper problems that make it impossible for me to accept at any price.
My purpose in posting is partly in the hope that someone will point out how my analysis is incorrect.  I want an ecosystem to develop that will allow bitstream developers to fairly profit from delivering improvements to FPGA performance.  I hope that my posts will generate discussion on how to create that ecosystem with fair compensation for both programmers and users.

The posts that are coming are in 6 parts:

Part 1:  The Ultimatum game and evaluating a fair deal
Part 2:  Dealbreaker #1: Skimming shares
Part 3:  Dealbreaker #2: Downtime on signcryption service
Part 4:  Dealbreaker #3 and #4:  Maximum hashing capacity and incomplete implementation.
Part 5:  Calculation of the reward split between ET and a user
Part 6:  Evaluating ET's potential return

If people aren't bombarding me with rotten eggs and tomatoes by that point.  I will prepare a few more parts discussing options to develop a fair reward structure.

Probably a key with the incoming job that is tested and then convoluted to produce the outgoing transform?

It makes me sad thinking of all the time he spent on this code, and the time he will spend keeping the server up that could have been spent on a better bitstream. There needs to be an open mechanism to compensate bitstream work and encourage collaborative improvements.

ET,

Can you clarify what approxiamately 5% means? Imprecise language regarding money makes me nervous.

Also, how will you harvest this 5%?  If this becomes common practice how would I know some future bad actor doesn't take 5% and all valid blocks? Similarly how could you be sure a user doesn't proxy your hashes back to himself?  Or send them to dev/null?. You signature server is going to be a huge denial of service target. Will you compensate miners for downtime?

It is a fascinating idea. Do you follow behavioral economics?

Strike through on items in the FAQ.

Ok here is one for you:

Does PayPal permit transactions for pre-sale items?

    Pre-sale items are advertised for sale before the seller has the items. Often, these items are sold before they are available to the general public. Or, the seller uses the funds from the sale to purchase the item that has already been sold.
    
    PayPal permits pre-sales on a limited basis, only if the seller guarantees delivery within 20 days from the date of purchase and clearly identifies the item as a pre-sale. PayPal may apply additional conditions, such as proof of the seller's ability to successfully deliver the product: supplier information, purchase invoices, postal information or proof of delivery.

https://www.paypal.com/helpcenter/main.jsp;jsessionid=5BF2PGnW8vHvJD7Nn7c6vZyVCZtqSwlyy9sv8QGJg5gXhh504Ly4!1268435979?locale=en_GB&_dyncharset=UTF-8&countrycode=GB&cmd=_help&serverInstance=9014&t=solutionTab&ft=browseTab&ps=solutionPanels&solutionId=163756&isSrch=Yes

100% Violation of Paypal policy, and BFL does take paypal.

I'm sure further searches on pre-sales will turn up relevant laws.  But I am done with the topic.  Stop trying to attack my credibility and I'll stop posting facts you don't want to hear.

It seems like it should be possible to calculate the expected variance in the hash rate estimate on a given window size.  

For example, the 8 hour window estimate is based upon the time required to solve 48 blocks.  You should be able to calculate a 95% confidence window around each 8 hour estimate.  I'm not in a mood to crack a stats textbook tonight, but I am curious about the subject.  A good analysis might lead to better ways to smooth the estimates than simple windowing.

By eyeball there seems to be some statistically significant periodicity to the data sets.  In particular, there seem to be large upswings on the weekends.  Since it makes no sense to not run hardware purpose built for mining mostly 24x7, I suspect this is the result of corporate or university workstations being farmed by admins.  It could also be someone taking advantage of lower priced power and running otherwise unprofitable systems.

ngzhang did the reverse engineering that showed the single has an FPGA.  The thread is the source of my understanding that BFL claimed to be using an ASIC.

Visa operating rules are linked below.  Your experience is common.  I have on more than one occasion successfully collected a refund from a reluctant merchant by citing their failure to ship as a violation of Visa rules.  Charging the same day you ship is a far different matter, and overlooked by the card companies.
http://usa.visa.com/merchants/operations/op_regulations.html

I'm not interested in researching case law for you.  It varies by state and I have lived in some jurisdictions where the law was as I stated.  If I had a dog in this fight I would hire a consumer rights lawyer in the capital city of BFL's state to investigate and possibly file a complaint.  If you really want to know, google or make some phone calls.

There is a huge difference between a deposit and 100% payment.  When I bid on my house I put 1% of the purchase price into escrow as good faith money.  

Regarding cars, this is an excellent example.  A dealer is charged the full price of a car he ordered the exact moment it rolls of the assembly line.  Not a minute before that.  If you want to purchase a custom configured car, you will need to pay a deposit with the dealer, but certainly not the full price.  I considered buying a Tesla a couple years ago and they were asking for less than 10% as a deposit at that time.

Car dealers are required to post a financial bond to help reimburse any customer deposits in case of insolvency.

Thanks for asking.  I have a few simple points.

About BFL
1.  You are pre-announcing this product before delivering your previously pre-announced product
2.  This is your second claim of delivering a product with ASIC hashing.  Your first was debunked as an FPGA as soon as product shipped.
3.  You seem to be using customer funds for purchases of product for development and general expenses.  If I am wrong about that please post a notarized statement from your escrow agent and I will apologize.

About business in general
1.  Paying in advance for development is an investment.  It is generally compensated with intellectual property, equity or loan interest.
2. Honest, viable businesses become insolvent all the time for lack of cashflow.  It is the reason for the Chapter 11 bankruptcy procedures.
3. Payments in advance for products become unsecured debts in a bankruptcy proceeding.  Unsecured debtors are among the lowest priority for recovery in these procedures and generally get nothing.  Even if the material is sitting in the shipping bay with a label on it, it isn't yours under bankruptcy.
4.  For reason #3 above it is unethical, and a violation of consumer protection laws in many places to sell product in advance of availability.  For the same reason, Visa and Mastercard require shipment before a sale can be charged.
5. Companies at risk of insolvency often make very generous guarantee offers.  A guarantee has no revenue cost in the present, and has no value in bankruptcy either.

I can't see ever being a customer of yours given your business practices.  And your question has given me the opportunity to  nicely summarize why people should use caution.  So I will leave your thread to your fans and investors.

I think an audit of BFL's books would show that you have been a significant source of funding for whatever development work has been done.  Your cash up front for hardware that still hasn't shipped has been BFL's risk mitigation.

As I pointed out earlier, risk mitigation could be accomplished by borrowing in bitcoin to recover existing costs.  If the exchange rate swings, or collapses you pay back in devalued bitcoin.  And the loan is repaid out of your super-fantastic 900% / ROI ASICs.  

Even recovering the initial $1M would only take a few months.  And once a competitor appears you have a fully depreciated technology you can sell below your competitions cost.

BFL cannot have purchased any modern mask set.  They probably intend to collect pre-orders to fund one though.  They is no way I would give a dime to them for ASIC systems without proof of a mask being built.  Keep in mind it takes 3 months to move die through a fab.  Plus test and packaging.

Cablepair, I sympathize with you.  The entire purpose of BFL's announcement is to damage their competitors.  FUD (fear, uncertainty and doubt) has been used by unscrupulous companies against competitors for decades in the tech industry.  See my post #91 for an explanation of their motivations.

Looking at it another way, imagine you have access to tech that is merely 5x more efficient than today's hardware.  Call it $0.14 / MH.  That would be $140k per TH which would capture around 450 blocks a month right now.  Earning $115k / month!  Or 1.2 months to breakeven!  Would you sell this tech to anyone?  Would you tell anyone?  Of course not.  You would put your own money in and yield 100% returns.  You would spread your systems over datacenters worldwide, and hash through a dozen different pools, and no one would realize that you are reaping 80% of the hash rate in a a year.  Then you might start selling.

I suspect BFL is paying rent, lights and salaries with mini-rig orders they still haven't shipped. BFL prove me wrong:  publish a report from a lawyer or CPA showing that they are holding payments for these systems for you in escrow.