Topic: Algorithmically placed FPGA miner: 255MH/s/chip, supports all known boards - page 33. (Read 119440 times)

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!

So in your specialised scenario, how many people do think are running fpga's in rented racks?

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.

If you are at you maximum power draw currently, then this is a constraint self imposed, rather than by ET.

If you overall hash rate is going to go down (because you are so close to your limits), then you wouldn't bother.  These posts are good "black hat" thinking, but tending to reflect extreme operating positions.

If I have 100 FGPA units running 800Mh @ 40W each and can take them to 1000Mhash for 60W each, then sure I'm going from 4kW to 6kW, but if I have 6kW of supply, the extra 2kW (in my case $10/day) in exchange for 20Ghash looks like a nice tradeoff. 

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.

At least on some boards it would be possible to actually have a backup bitstream for that case, that will just drop to the lower, "usual" hash rate after like a minute of downtime.


As usual, this is something that the mining software and hardware developers need to do to stay competitive. And I highly doubt ETs software will support any fallback of that kind.

At least Icarus and Enterpoint boards can deliver 12A per FPGA. This should be enough for running your bitstream. (You said your FPGAs consume 12W at 1.25V core, that's only 9.6A).

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

I might be wrong but your scenario is possible only when solo mining? There are only a few who solo mine so I don't see that as a problem. Plus I think that whole system doesn't work in a way that lets EldenTyrell steal shares of his chosen.

Many real-life mining companies pay a royalty to Governments or land owners for the right to exploit a resource.

Also, 20% of the incremental benefit is not huge - as quoted, currently around 5%.  No one is forcing you to use it either.

Trust is good, verification is better. All you have to do is to keep one board with a different bitstream in order to be able to compare the returns.

Actually, the way I understood his plans, it will be technically impossible for him to do anything of that kind secretly.
IIUC the miner will occasionally ask the signcryption server for a piece of signed "profit cut" work, and if it finds a share for that, will upload that share back to the signcryption server. The signcryption server will then allow the user to upload a certain amount of his own work to it, getting it back signcrypted. As far as I can tell there is no reason for the non-profit cut shares to go through the signcryption server. But even if they did, it would be easy to tell if a share "disappears" inside of the signcryption server.
The only way to pull off something like that would be in the bitstream itself, randomly withholding high-difficulty non-profit-cut shares. That, however, would not benefit ET much, as it would only lower the effective total hashrate of the board. I doubt that he will have enough of a market share for this to have a noticable impact on difficulty before his bitstream becomes obsolete.

So while I generally do not quite agree with the approach he is currently taking for other reasons, I don't think this particular issue is valid.

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.

I for one would like to know exacly where and how the 5% of the hashing power is directed, got 12 spartan6:s lined up from enterpoint. Would you care to elaborate ?

Well, I've read about EldenTyrell's protocol... And it seems that everyone re-invent wheels... So I proposed to improve things a bit for mining perspective, looking forward to hear EldenTyrell as he already implemented his stuff based on TCP, and I have strong opinion against TCP for such purposes, and other FPGA guys in topic about Development (that is related to bitcoind and pools):

https://bitcointalksearch.org/topic/proposal-for-lightweight-mining-protocol-over-udp-84791

Thanks.

Ah, that makes more sense. Regardless, I'm excited to load all 18 of Cognitive's x6500s with this!