Development summary week ending 18th April 2014

Ross Nicoll bio photo By Ross Nicoll

When I got my first full time job, I used to try implementing requests from everyone as they came in, and for a while people really loved that I listened to their requests. Over time, however, things started to go wrong. I'd apply a change someone asked for, and in doing so would break something elsewhere in the code, in some subtle way that was missed in short-term testing. I'd fix that second bug and reveal a third. I'd fix that just in time for a new request to come in, and the process repeat. This led to the term "Bug whack-a-mole", wherein I was spending time mostly fixing bugs introduced to live systems through rushing through earlier bug fixes.

So this week, we've had a lot of people asking about  changes to proof-of-work, especially X11, or even moving to proof of stake, primarily in an attempt to address risk of a 51% attack. A 51% attack is where one actor (person, group, organisation, whatever) gains control of enough resources to be able to create their own blockchain, isolated from the main blockchain, at a rate at least as quickly as the main blockchain is being created. They can then spend Dogecoins on the main blockchain, before releasing their fake blockchain; if their fake blockchain is longer than the existing blockchain, nodes will switch to the new blockchain (as they would when repairing a fork), and essentially the spent Dogecoin on the main blockchain are reversed and can be spent again. This is mostly of consequence to exchanges and payment processors (such as Moolah), who are most likely to end up holding the loss from the double-spend.

The concern about a 51% attack stems from a couple of weeks ago now, when Wafflepool was around 50% of the network hashrate (mining power). It's still high (at the time of wring about 32GH/s out of almost 74GH/s, or about 43%), but it is diminishing as a proportion.

Lets talk about proof of stake first, as this one's simpler. Proof of stake has been suggested as a way of avoiding the risk of Wafflepool having control of too many mining resources by itself, by changing from securing the blockchain through computational resources (work), to using number of Dogecoin held. The theory is that those with most Dogecoins have most to lose, and will act in their own interests. Major examples of proof of stake coins include Peercoin, Mintcoin and more recently Blackcoin.

However, this essentially means we take control from Wafflepool, and hand it to Cryptsy (who are considered most likely to be the holder of some of the huge Dogecoin wallets out there). I by no means expect either organisation to attempt a 51% attack, but hopefully it's clear that simply switching risks isn't actually improving things. I've also had significant concerns raised from the merchant/payment processor community about potential impact of proof of stake, and that it may encourage hoarding (as coins are awarded for holding coins, rather than for mining). The price instability of Mintcoin and Blackcoin (and that Peercoin appears to only avoid this through very high transaction fees to keep the entire network inert) does not encourage confidence, either. For now, proof of stake remains something we're keeping in mind, primarily in case price does not react as anticipated to mining reward decreases over time, but certainly we're not eager to rush into such a change.

Before I get into a discussion on proof of work, let me summarise this quickly; right now, uncertainty about changes is holding back our community from adopting ASICs. It's high risk to spend hundreds, thousands or in some cases significantly more on ASIC hardware which could be left useless if we move. Those who have already purchased ASICs to support the Dogecoin hashrate would most likely have to mine Litecoin to recover sunk costs, if we did move. ASICs are virtually inevitable, and in our assessment we are better off pushing for rapid adoption, rather than expending resources delaying a problem which will re-occur later.

At the time of writing the development team has no plans to change proof of work algorithm outside of the eventuality of a major security break to Scrypt. We are focusing on mitigation approaches in case of a 51% attack, and adoption of the coin as the most sustainable approaches to dealing with this risk.

The X11 algorithm has been proposed as an alternative proof of work algorithm. X11, for those unaware, was introduced with Darkcoin. It's a combination of 11 different SHA-3 candidate algorithms, using multiple rounds of hashing. The main advantage championed for Darkcoin is that  current implementations run cooler on GPU hardware. Beyond that, there's a lot of confusion over what it does and does not do. As I'm neither an algorithms or electronics specialist, I recruited a colleague who previously worked on the CERN computing grid to assist, and the following is primarily his analysis. A full technical report is coming for anyone who really likes detail, this is just a summary:

A lot of people presume X11 is ASIC resistant; it's not. Candidate algorithms for SHA-3 were assessed on a number of criteria, including simplicity to implement in hardware. All 11 algorithms have been implemented in FPGA hardware, and several in ASIC hardware already. The use of multiple algorithms does significantly complicate ASIC development, as it means the resulting chip would likely be extremely large. This has consequences for production, as the area of a chip is the main determining factor for likelihood of an error in the chip.

The short version being that while yes it would take significant resources to make an efficient ASIC for X11, for a long time Scrypt was considered infeasible to adapt to ASICs. As stated earlier, any move would most likely be nothing more than an extremely expensive and risky delaying manoeuvre. ASIC efficiency would also depend heavily on ability to optimise the combination of the algorithms; a naive implementation would run at around the rate of the slowest hashing algorithm, however if any common elements could be found amongst the algorithms, it may be that this could be improved upon significantly

There are also significant areas of concern with regards to X11. The "thermal efficiency" is most likely a result of the algorithm being a poor fit for GPU hardware. This means that GPU mining is closer to CPU mining (the X11 Wiki article suggests a ratio of 3:1 for GPU/CPU mining performance), however it also means that if a way of was found to improve performance there could be significantly faster software miners, leading to an ASIC-like edge without any of the hardware development costs.  The component algorithms are all relatively new, and several were rejected during the SHA-3 competition for security concerns (see http://csrc.nist.gov/groups/ST/hash/sha-3/Round2/ documents/Round2_Report_NISTIR_7764.pdf for full details). Security criteria for SHA-3 algorithms was also focused on ability to generate collisions, rather than on producing hashes with specific criteria (such as number of leading 0s, which is how proof of work is usually assessed).

X11 is a fascinating algorithm for new coins, however I would consider it exceptionally high risk for any existing coin to adopt.

Beyond algorithm analysis, this week has been mostly about testing 1.7. Last weekend Patrick raised the issue that we had been incorrectly running the automated tests, which had led to several automated test failures being missed earlier. This led to other tasks being dropped as we quickly reworked the tests to match Dogecoin parameters instead of Bitcoin. So far, all tests have passed successfully once updated to match Dogecoin, however this work continues. On the bright side, it turns out we have a lot more automated tests than we realised, which is very useful for later development.

The source code repository for Dogecoin now also uses Travis CI, which sanity-checks patches submitted to the project, to help us catch any potential problems earlier, thanks to Tazz for leading the charge on that. This is particularly important as of course we're developing on different platforms (Windows, OS X, Linux) and what works on one, may not work on others. Over time, this should be a significant time saver for the developers. For anyone wanting to help push Dogecoin forward, right now the most productive thing to be doing is testing either Dogecoin, or helping Bitcoin Core test pull requests. Feel free to drop by our Freenode channel for guidance on getting started with either.

Right now, I'm working on the full technical report on X11, and will then be back working on the payment protocol for Dogecoin. I've approached a few virus scanning software companies about offering their products for Dogecoin, with so far no response, but will update you all if I hear more.

Lastly, the next halvening (mining reward halving) is currently expected late on the 27th or early on the 28th, both times GMT. Given that it was initially expected on the 25th, we're obviously seeing some slippage in estimates, and a total off the top of my head guess would be that we'll see it around 0500 GMT on the 28th at this rate. I have taken the 28th off from the day job, and will be around both before and after in case of any problems (love you guys, not getting up at 5am to check on the blockchain, though!)