think would you really want to start a trend of ASIC producing companies using their product and reaping the rewards first; increasing the difficulty while holding funds deposited by awaiting customers on a product that was delayed?
That is not good publicity and would NOT be good for bitcoin
Like I said, if the vendor wanted to they could discount the unit on the basis of any money generated during the burn-in period. There is a total amount of money theoretically possible to earn during a few days, and it is not a huge amount. Just does not seem like a big deal to me.
As for damage to the Bitcoin network generally, what could it possibly do that is not going to be done several days later when customers receive their units anyway...assuming the units work?
Anyway, there is every bit as much reason to burn in the first generation of ASIC chips and PCBs as there is to test a car coming off the assembly line. Again, I would almost demand that the vendor do this as one of the tasks I am paying them for (or would be if I were a customer.)
Hmmmmm.
TL;DR: ASICs and MCU's do not implement the complete block solving protocol - so
burn-in testing of all units with full protocol is not needed AT ALL.
The premise is faulty - so it's a non issue in terms of burn-in testing - but very much an issue in terms of vendor credibility.
The Avalon people were correct when they blasted anyone who suggested that burn-in testing, a complete burn-in cycle, required a full reproduction of the block solving protocol. It isn't required. Main net testing is not required. Testnet-in-a-box is not required. As a proof of concept measure the first samples of chips would of course need to be confirmed by using a full reproduction of the protocol. However, still main net testing is not a requirement. And even then a testing protocol, independent of the full protocol, can be used (must be written) for large scale functionality and burn-in testing of specific purpose for which the ASIC and MCU was designed.
BFL was initially going to use main-net for testing. Josh/Inaba said it himself. That is, full burn-in cycle for all units produced. I and many others blasted them for such a "silly" idea (I quote Avalon).
BFL's argument was that:
1. "The dev's" frowned upon using test-net for such large QA activities. The consequence would be astronomically high difficulty that could interfere with the testing activities of others.
2. It was not possible to perform testing in other non-impactful ways, so main-net was the choice.
Once this information was made public and was met with criticism BFL claimed that all profit resulting from burn-in testing with main-net would be donated to the miner app dev's.
When this claim of donation of profits did not assuage BFL's critics Josh/Inaba did some blasting of his own by making accusations against those critics that:
1. Critics didn't care about the miner dev's.
2. Critics didn't care about the network's security. Bizarrely, Josh/Inaba twisted critics arguments (memory is hazy) in to one where critics held an irresponsible position and jeopardized network security by the fact that if BFL didn't burn-in test with main-net to establish an equilibrium the combined capacity of units where customers had taken delivery threatened a 51% situation.
Of course, point 2 doesn't hold much water since, at the time, BFL's 1/3 shipping plan called for mass assembly, testing, and shipping thereby largely eliminating the risk of 51% in the hands of either one or a relative few customers.
In my mind this is the point where BFL lost some major credibility. Either they were lazy or they were greedy. Take your pick.
