So first some background. We\u2019ve already covered a little about what to expect from Frontier in the Ethereum Launch Process<\/a> blog post\u00a0and Gav has given us a comprehensive overview of the state of the development effort<\/a>. You can also read about some of the ongoing security work, including the bug bounty system<\/a>.\u00a0The bug bounty program has found\u00a0my favorite bug so far: Jonas Nick<\/a>‘s discovery that you could send a negative payment to somebody which moves value from their account to yours!<\/a><\/p>\n As bug bounty finds go, an absolute gem. Well done!<\/p>\n Gav has a new blog post describing a little more about what the thorny end of the development process looks like: creating a precise specification for Ethereum by keeping three different implementations in sync<\/a>, rather than having a canonical implementation which implicitly defines the protocol spec and which other versions then become bug-for-bug compatible with. This is a pretty tough-minded and thorough approach to putting together a system, and it\u2019s worth reading to get a flavor of how the engineering work is going.<\/p>\n By now you should have a pretty good sense of what the development process looks like, and the disparate threads of work which are being woven together into the release. So let\u2019s talk about what actually has to get done between now and Frontier.<\/p>\n There are four specific challenges<\/b> for us to meet on Frontier.<\/p>\n Two of those, Mining and Exchange are partnership efforts: people have to take our software and run it, in concert with their own tooling in some cases, to provide services as part of the ecosystem. Remember, we\u2019re launching an ecosystem, not just a product: everything is part of that ecology. Each one of these aspects of the release process has to work, both on its own, and with the others for the ecosystem to actually get a proper test under load.<\/p>\n In addition:<\/p>\n Reasonably good progress is being made on all fronts. Rather than giving you a release date, and then risking that under pressure to meet that date, something will slip through the gaps that another day of work would have caught, we are going to tick off items in the release process as we go. This will let you get have a sense of how far out from the launch we are on any given day, without us basically making a guess at how long it will all take, publishing our guess, and then hoping we can make reality to the calendar: as we said before, this is a security-driven not a schedule-driven process. We can make that process fairly transparent to you, and provide summary information so you don\u2019t have to watch the repositories – but we would rather bring you into the process so you understand what is happening and how the work is going than give you an aggregate date and keep you guessing as to the actual state of the work. We feel this approach is more transparent, better suited to a crowdfunded development process, and overall simply more realistic.<\/p>\n If you would like to see the current state of play, Jeffrey Wilcke (lead on the Go client<\/a> This issue list<\/a> is the best reference for the Frontier release: right now, 10 issues closed, 26 open. New issues will get raised, and of course issue count is only a very loose proxy for \u201cship time\u201d but the work done is the best indicator, so look there if you would like to prognosticate.<\/p>\n\n
\n
![\"Jeffrey\"](\"https:\/\/blog.ethereum.org\/images\/posts\/2015\/03\/Jeffrey.jpg\")
<\/a>and the Amsterdam hub) has a Go client issue tracker for Frontier<\/a>.<\/strong><\/p>\n![\"screen](\"https:\/\/blog.ethereum.org\/images\/posts\/2015\/03\/screen-shot-for-downloads.png\")
<\/a><\/p>\n