So if there is a solid plan, not a ponzi plan, that's a good start.

However, all investments carry risks...?

Perhaps the safest option is to register with the SEC before doing an IPO, even if you are a foreign entity. If nothing else, you'll look much more professional and trustworthy.

I presume you can't really do much after the event.

Indeed - this is why I think the problem Bitcoin faces is harder than writing avionics software: we have no choice but to start with a buggy and poorly designed piece of software, the original Bitcoin client written by Satoshi, and maintain and improve it. The avionics analogy would be to take a multi-engine WWII-era bomber, fly and maintain it continuously 24/7 via in-flight refueling, and gradually upgrade it to be as good as a brand new Boeing 777 without ever landing once. Needless to say, starting from scratch would be much easier, but we don't have that option.

You say to know a lot about writing quality software, why don't you write a from-scratch alt-coin implementation done correctly with solid software engineering?

Bitcoin Airlines 2012 Annual Report:

1) The founder and CEO had split and we are still unable to locate him. Interim CEO is in charge until then.

2) The original paper plane has been covered in many layers of varnish and we have declared it fit for the regular service.

3) We've sold many passenger tickets for our Airline and the regular scheduled flights have started.

4) Unfortunately the cruise speed of our planes is barely above stall speed. The engines are weak and we cannot upgrade to the professional state-of-the-art engines that other airlines use. None of our mechanics know how to maintain them and we don't have money to hire some help.

5) Moreover the oxygen supply on our planes isn't working right and the passengers are passing out while onboard. Frequently the conscious passengers rob the passed-out passengers. Sometimes even the plane crew takes into temptation and plunders the unconscious passengers.

6) Fortunately the in-flight entertainment systems on our planes are the best. No-one else is even getting close to what we have to offer: neither on the land nor on the sea nor in the air.

7) Unfortunately almost all the fuel and engine thrust goes into powering the in-flight entertainment systems.

 

Given that the disagreements we are talking about are things like "Does Alice have a valid check signed by Bob entitling her to take $1000 of Bob's money?" any type of majority voting protocol is unacceptable - you're proposing a system that would allow a majority of miners to decide that they are going to steal your money with no recourse.

It is difficult to get a man to understand something, when his salary depends upon his not understanding it!

* Quality must be built into the software, at a known level, rather than adding the quality after development.
* You cannot test quality into software

Yeah, nothing wrong with re-implementations if you hide them behind a trusted bitcoind node (IE one you run yourself) and/or use them for small sums of money. Just remember you'll occasionally suffer downtime when your implementation mistakenly thinks a block or transaction is invalid, but your trusted bitcoind node will protect you from false confirmations.

I think software for avionics has a lot to teach us. In particular, modified condition/decision coverage is important.

In this case a coverage analysis of these implementations run against their tests (maybe just the main blockchain) would show the nOut >= txTmp.vout.size() branch never taken.

What avionics software doesn't teach us as much about is handling adaptively hostile input (though if your code is correct for all inputs that hostile is just a subset— but hard to be confident that you're correct for all with cryptographic constructs in the loop), nor does it so much about implementation agreement in consensus systems. I suppose avionics would tell us we need to be testing the whole network as a single system because of the inescapable tight coupling, but sadly thats not realistic.

They could have had a test for it failing in that case... and seen that it rejected the block. The coverage would be good, it would be a sensible self-consistent behavior... but not consistent with the reference implementation.

Right now because the rules logic in the reference software doesn't have any test available which achieves anything close to modified condition/decision coverage (which, in also fairly hard to measure because the code is written in C++ and does a lot of dynamic allocation and boost) it means that even if you test an alternative well you can't compare it to Bitcoind unless you test.

But there are still tests which do test _a lot_ of it, and it seems they weren't used here:

It's worth noting here that Bluematt found this behavior about a year ago. The blocktester should be testing it.  I guess this indicates these alternative implementations have not been tested with the blocktester.  I suppose that in and of itself is a bit more concerning then even the specific failure.  On the other hand, the fact that they haven't been means we actually get an indication of their level of review which we wouldn't have gotten if the blocktester had already been run an exposed all the known-troublesome spots.

Oh, you'll absolutely be able to plug in a different SQL or whatever back-end. For unit tests I have a "back-end" that just stores everything in memory in a dictionary, for example. I just want a decent out-of-box solution.

I have FireBird close to working with binary columns, running into a snag now where it's not accepting nulls. I have to say I'm pretty shocked that FireBird doesn't have proper binary column support.

For development purposes, I want the solution to be ready to run as-is with no installation required.

Hi, are there any other developers out there interested in or working on a bitcoin c# node? I've been working on one for a couple of months and I think I'm starting to see some promising results. I'd love to connect with anyone else interested in this work.

Anyone have any recommendations on a good embedded database I can use from C#? SQLite is turning out to be awful for concurrent writes, and Firebird does not seem to support binary data properly.

Regarding the compatibility with accounting standards, this might be the case today. But it is certainly possible to build more infrastructure around Bitcoin to actually make it compliant. Today already it is possible to build a sufficient accounting system around the Bitcoin client. To make it compliant with accounting standards would be the next step. The great thing is that everybody has access to a payment infrastructure that can have many more services built around it.

If you have ever seen a GPU die, then you know the shaders constitute the bulk of the chip.  > 80% of it.

Similar logic exists with ASICs, and based upon die shots of Avalon, BFL, and Bitfury processors, I would put the non-SHA256 components at 5% or so in total area.


How do you think different product tiers in GPUs exist?  7830 / 7850 / 7870 etc.  The are ALL the same die, just the lower-end products have various shaders turned off in post-processing because there are defects in there.  Even with this post-processing, the simple laws of IC manufacturing apply - bigger dies = BAD for yields.

I cannot believe no one else has picked up on this as well.  KNCMiner's die size is 2.5 INCHES squared.  That's . . . . Titanic sized.

I hate do to be debbie downer here, but that means that on a standard 300mm wafer they will not get many chips, and that's assuming a 100% chip yield from the wafer.  Wafer's always have defects which cause some chips to go down.  The yield decreases exponentially as a the die size goes up (i.e. it only takes a tiny imperfection in the wafer to make the entire chip a paperweight).

Even if they get chips, the yield is going to be absurdly low, I would bet less than 25%.  They can probably recoup some investment by selling chips that are spec'd lower and have some "cores" disabled in them, but this is hit or miss depending on where in the chip the defect occurs.

That's why I compared it to GPUs.  Which, like ASICs, are dumb repetitive.

The bigger the dies, the lower the yield, the more you have to charge to cover your costs on the wasted dies from a wafer.

This is the best piece of info in this entire discussion.  Unfortunately Fabs almost never release their defect density and yields, unless you are a customer under a Non-Disclosure Agreement.  In almost two decades following CPU/IC production I have never willingly seen a fab release this info.  Very rarely you can get it leaked from a former employee, but then it is always tainted and uncertain if that person has an axe to grind with his former employer or not.  Alternatively, sometimes, you will get vague impressions from the executives during financial disclosures, but never the detailed info you want.

Now, the only thing apparently known about KNC is that the package size is about 3000 mm2.  Let's assume I am wrong, would not be the first time, and that they have a relatively small chip for the package size.  Say 15-20%.  That would be a die size of 450-600 mm2.  That would still be BELOW the lowest curve on the above diagram.  That's really scary for yields, but not impossible to obtain working product by history.  But any customer with a die size that large would have to expect very low yields, and they probably had to sign a waiver from the foundry about guaranteed yield due to "design constraints".

Here are some historical data points for 3rd party fab yield problems with some of the larger GPU dies, for bigger customers:
http://www.geek.com/games/ati-and-nvidia-have-troubling-40nm-yields-from-tsmc-815501/  which were "fixed" a year later:
http://www.dailytech.com/TSMC+Says+40nm+Problems+Resolved+Preparing+28nm+Fab+Production+/article17355.htm
http://www.eetimes.com/document.asp?doc_id=1261006  which were "fixed" about 10 months later:
http://www.pcmag.com/article2/0,2817,2411985,00.asp

Now, a TSMC/UMC is going to work with an AMD/NVidia to improve yields because they are producing 10-100s of millions of chips.  For a smaller companies, they will not go to great lengths to help them revise designs and processes to improve yields.  You get what you get.

Traditionally GPU dies have been some of the largest dies, with the high-end (low yield) parts topping out around mid-500 mm2 in size.  And the parallel structure of a GPU is what most closely resembles the SHA256 ASICs being designed and produced by companies today (Avalon, BFL, KNC, BitFury, etc.).  So from a manufacturing standpoint, we can probably infer a lot from large ASIC production issues by looking at issues that GPU manufacturers have had in the past.

The bigger the dies, the lower the yield, the more you have to charge to cover your costs on the wasted dies from a wafer.  Therefore it is always good to make your dies as small as possible.  Just 10 mm2 per die, when factored over an entire wafer, can mean tens of thousands of dollars in improve yield per wafer.

For comparison, here is a good illustration from the 45 nm days, with Intel - who historically have much higher yields than the rest of the industry (the invest more in their process and refinement).



Again, I hope KNC brings to market a good product, and in a timely fashion.  The more competition, the better we all do in terms of up-front pricing for our miners.  I just am concerned that we haven't see any substantial data about the processor (number of SHA256 cores, clock frequency, die size, heat production, etc.).

Considering the 10+ million dollars of orders they have had, you would hope they would publish this info to keep their investors/customers happy.

I'm not a networking wiz, and only know IPX as the old Novel Netware that DOS based computers used to run before they switched to Windows and TCP/IP. Could you explain why that comparison was "stupid pseudo-technical drivel" please?

Litecoin is IPX/SPX to Bitcoin's TCP/IP.

I guess this would have to be applied to all dependency builds, too? oh boy.

You instructions are duly noted and kindly don't refer to me as "dear" in the future (I am not now nor ever will be "your dear" ).

If everyone did this then the blockchain would end up 1000s of times bigger than it is - and how is it totally normal to send your BTC to one address and back to the original address every single block?

He is not paying fees - otherwise the topic would not even be here.

...

Unfortunately it does not work as MinGW GCC is somewhat nondeterministic.

  -frandom-seed=<string>      Make compile reproducible using <string>