Update
It has been a while since our last update and we figured, we should make a noise to show we are still alive and kicking.
We are working on a lot of things simultaneously right now, but most of them do not make for good news.
We will give out an update anyway.
We mentioned last time, that our engineer and the math guy had a little dispute about assembler. For those who do not know what it is:
http://en.wikipedia.org/wiki/Assembly_language In principal, it does not get much closer to zeros and ones when it comes to programming. The upside of this is extreme efficiency. Programs wrote in assembler allow for ultimate control of MPU functions. The downside is, put bluntly, that it is a pain in the ass to use assembler. Please excuse this profanity, but there are not that many words to describe how utterly uncomfortable and hard it is to get something complex working with assembler. Even more so, when it requires floating point operations.
Our math guy figured, that an elliptic curve DSA is possible to code with assembler. This is not very surprising, as there is basically nothing you can not do with assembler. There are just many things that you do not want to do with assembler. The bad news about it is, that there does not seem to be any obvious way to get around the use of floating point operations when calculating discrete logarithms.
Now, if we want to have one of our locks in a smartphone, the full size lock described in the whitepaper is not really an option. First, it would cause size problems, which is unfortunate, but not crippling. The bigger problem is an economical one. A lot of the components needed to run the lock are already present within a smartphone. Radio transmitters, batteries, RAM, flash memory. It is all in there. To have a product which will be able to compete in the medium term, the lock needs to be as small as possible. Offering locks with largely redundant components is not really an economical competitive option.
We could generally outsource the lock development to companies who wish to participate, but this would increase the initial investment for those companies and subsequently lower the chances for them to come aboard. To get the whole system going, offering a solution which can be integrated without large entry hurdles is almost mandatory. Also, the amount of money involved in offering a general solution in this regard is very tempting, to say the least.
So we are back at assembler. A competitive chip able to use ECDSA will use code written in assembler. The engineer says he does not want to, he really does not. The math guy says he has to. He also says, that it is going to especially tedious.
But we put too much work in the project by now to go for a suboptimal solution.
News which are slightly embarrassing revolve around the website. Our designer guy is working on that and while there are results in general, he was still not able to solve some minor issues by now. Considering what we are creating here, the failure to create a simple website without problems is not very flattering.
In our defence I have to say, the website and the design skills are just icing on the team cake and involve no core skills. Our designer made some nice concepts for the key devices, but we will keep that to a seperate news report.
Last part is the IPO which is still coming, but modified from the original plan. The original planned amount will be further reduced and the amount of invest-able BTC will be significantly below 100. After some discussion we figured that no amount of money we will be able to raise here can cover the development. Thus, we currently try to figure how much money we need to get to the next step, which is getting a working prototype and attracting venture capital.
We know that this seed investment will be at a considerable premium compared to any later funding round. So, while the risk is of course high, the reward in case of success should reflect that risk.
As soon as there is more news around, we will update this thread again. Hopefully finally with a website next time.
