Algorithmically placed FPGA miner: 255MH/s/chip, supports all known boards

[coblee]

TheSeven: You will probably have to agree to make a closed source MPBM build which includes support for this firmware...

I think the idea of the commission is great, but I really wonder how many people it will turn off, because of the need for tweaked software.

I disagree. There's nothing secret about how the miner software would function. Everything is controlled by the signcryption done by the signcryption servers. The miner software would just have to first send the work to the signcryption servers to have it signed before passing it to the miners running the TML bitstream. And when a nonce is found, it would have to send it to the signcryption server to have it decrypted before it can be sent off to the pool. The signcryption server just controls that for every X nonces it decrypts, you need to send it a commission nonce.

[1714503458]

1714503458

[1714503458]

1714503458

[1714503458]

1714503458

[1714503458]

1714503458

[1714503458]

1714503458

[Beaflag VonRathburg]

I'm willing to bet 100 BTC that ASICs will be the first mining hardware to be rendered useless by Bitcoin developers.

This is specualtive, but... Couldn't you say BIP16 killed mystery miner's botnet ring? Botnets are software, but directly use hardware. You can't have one without the other. PS: Address in sig if you're feeling like tossing 100BTC around.

Has anyone had the opportunity to try this on one of Enerpoint's fpga units yet?

I look forward to finding out about this. I think Glasswalker has one in his hands and seems to have have an idea on what he is doing. I'd like to see him test it out.

[Garr255]

TheSeven: You will probably have to agree to make a closed source MPBM build which includes support for this firmware...

I think the idea of the commission is great, but I really wonder how many people it will turn off, because of the need for tweaked software.

I disagree. There's nothing secret about how the miner software would function. Everything is controlled by the signcryption done by the signcryption servers. The miner software would just have to first send the work to the signcryption servers to have it signed before passing it to the miners running the TML bitstream. And when a nonce is found, it would have to send it to the signcryption server to have it decrypted before it can be sent off to the pool. The signcryption server just controls that for every X nonces it decrypts, you need to send it a commission nonce.

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

[bitfury]

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://bitcointalk.org/index.php?topic=84791.0

Thanks.

[Isokivi]

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 ?

[Entropy-uc]

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.

[Entropy-uc]

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.

[Entropy-uc]

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.

[TheSeven]

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.

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.

[Bitinvestor]

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.

[PatrickHarnett]

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.

[MXRider]

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.

[Entropy-uc]

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?

[Entropy-uc]

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.

[mrb]

Another thing is what if bitfury gets the same idea and they release their 300 mh/s bitstream with 5% comission. No point in using a slower bitstream. Or even an improved open source bitstream that goes faster than 260 mh/s.

I will not do that as mine bitstream would not work with any board around there... not enough power for it and future version... So for existing spartan board I am not competitor to his bitstream niche.

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).

[TheSeven]

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.

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.

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?

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.

[Entropy-uc]

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.

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.

[PatrickHarnett]

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.

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. 

[Entropy-uc]

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.

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. 

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.

[Entropy-uc]

Has anyone had the opportunity to try this on one of Enerpoint's fpga units yet?

Enterpoint is still working on getting a basic bitstream working first. Only a few developers have boards at the moment. This will come later

http://www.btcfpga.com/index.php?route=product/product&product_id=50

This miner is available now and will do over 1g/hash with this new TLM bitstream

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.