There’s been a lot of discussion in recent days about the decreasing price of Dogecoin, as well as the risk of a 51% attack from Wafflepool or similar. I wanted to do a wrap-up of the discussions happening amongst the developers of the last few weeks, partly to illustrate that we are looking at options, but mostly to talk about what is happening. Please note that this is all rapidly changing. Dogecoin is actually moving at breakneck speed for a project of its size, especially as we still have a relatively limited core team. This is part of why we don’t write posts very often, as they become out of date so quickly as new arguments and facts are presented.
Lets talk about 51% attacks first. The theory is that if anyone has over 51% of the total hashing power of the network, they can form a blockchain of their own which is considered “more valid” than the blockchain most users are on. This is because cryptocurrency blockchains are secured through proof of work, and therefore more work on a chain makes it, in essence, more valid. This risks an attacker spending coins on one chain, then releasing their own private, longer, blockchain. That latter blockchain replaces the original blockchain, and the coins they spent on the original blockchain are effectively returned to them as if the transactions never happened.
It’s important to understand this because I hear suggestions that Wafflepool shouldn’t accept over 51% of the network hashrate, and unfortunately all this would do is hide the risk. Having one pool own over 51% of the network hashrate is not a problem if it’s actually being used to mine, but instead if it’s used to create a personal blockchain.
The other issue raised is one of price; we’ve been steadily dropping since around early February. The core of my answers here is that you need to consider demand vs supply. What happened back in February was that we saw a surge in demand beyond sustainable levels, likely in a form of tulip mania. As supply continued (mining), and demand dropped-off, our price has dropped. This has been worsened by a succession of bad news affecting Bitcoin (MtGox and other exchanges struggling, uncertainty of China and Russia, etc.), which both directly brings down our price, as well as undermining confidence in the entire cryptocurrency ecosystem. It has been suggested (and I can believe this, but have not done my own analysis) that as multipools continue to dominate Dogecoin mining, and they tend to sell coins directly, that they are further reducing the price. Specifically, given that while there is demand for further coins from miners, as they have already expended resources on mining hardware they cannot then purchase the cheap coins the mining pools are producing.
Lastly, there’s the question of ASICs; these are specialised mining devices which are significantly faster than CPU/GPU mining hardware, and typically cheaper to run due to reduced power and space requirements. Their introduction into mining at the moment leaves vastly disproportionate mining power in the hands of a few (there’s one individual with a hashrate of around 20GH/s, for example), and in time is likely to make mining on commodity hardware infeasible.
We’ve had a lot of suggestions for what to do; change proof of work algorithm, add multiple proof of work algorithms, move to proof of stake, merge-mine with Litecoin, have DigiShield merge-mine with us. We’ve considered everything, and then some; I’m not sure how much discussion has happened in total, but I’ve spent over a dozen hours looking at these issues on IRC. In virtually all cases, the majority of people with the skills to implement these changes have rejected them as too high risk and/or having other significant drawbacks. In summary:
- Changing proof of work introduces a number of risks; potential for a bug in the change to cause serious consequences (see recent issue with CleanWaterCoin for example of what can go wrong), that we don’t manage to get a majority updated before fork and end up effectively 51% attacking our own blockchain (not to mention that at least one exchange frequently misses these updates and causes problems as a result), that the algorithm itself has problems (see the long term issues of multipools managing to exploit “random” block rewards), or we simply lose users/merchants who are fed up constantly updating software.
- As a less technical concern; personally I’m uncomfortable knowingly make changes which intentionally introduce unneeded inefficiencies, which mean consumption of vastly more resources (electricity, and by proxy fossil/nuclear fuels). I imagine I’ll be swamped by shibes running geothermal mining facilities at the end of this post…
- Changing to proof of stake (and this is particularly relevant in context of my previous comment) is interesting, however right now I don’t feel I personally know enough to make a judgement on how to make the jump safely and efficiently. Statistician/economist shibes, I’d love to hear more from you.
- While I don’t like the idea of changing proof of work, I’m also pragmatic about these things; I am trying to find time to read up on Myriadcoin’s multiple-PoW support, and in particular considering whether it could be hooked into the code without necessarily enabling it right now, as a harness for potential future changes.
- Merged mining with Litecoin (and thanks to Charlie Lee for the invitation, of course) would likely help us mitigate 51% attack risks, by merging our mining power together, however it would introduce what have so far been considered undue issues for our mining community. Specifically, merged mining would require significant changes to mining infrastructure, adopting either p2pool or a mining proxy. Many have raised concerns that LTC miners would simply dump DOGE; personally I believe we could have an LTC/DOGE swap doing in the p2pool layer to give each miner whichever coin they prefer, to mitigate this, so this is not a risk I consider a major issue. There are also concerns that we would always be the secondary coin to LTC; personally I’d have considered a pre-defined block at which we de-merge a requirement, but again this isn’t a route we’re taking, I’m just going through the evaluation I’ve done for reference.
- Having smaller coins merge with us is interesting, however given our size in proportion to those coins, and that they are likely to be reluctant to merge with us (as we are reluctant to merge with Litecoin), I’m not expecting to see much progress in this area. We have made the invitation to DigiByte however.
The best suggestion we have so far is to out-do the multipools directly, by working on open source multipool software which is more DOGE-friendly. As I understand it two key approaches are being considered for improving DOGE-friendliness; either by directly exchanging other coins to DOGE, or through improved trading algorithms which result in less sharp shocks to the price. For very large mining farms such as SFire’s, it’s hoped this will cause them to separate from the mining pools (which they pay fees to) and go solo. This reduces fees for the miner, as well as reducing the ability for DDoS attacks to be targeted at them, and for us it reduces risk of a 51% attack, improves confidence in the coin security, and enables us to better mitigate impact of people mining huge quantities to sell.
Meanwhile, the main focus is on making Dogecoin (and cryptocurrencies in general) a viable way of moving value around. The 1.7 client (beta release is imminent, and in fact if you’re comfortable compiling it yourself, the code is available from https://github. com/dogecoin/dogecoin/tree/v1.7.0-Beta-1 ) is a major re-write of Dogecoin Core to base it on the Bitcoin Core 0.9 client (with Scrypt added in, of course). This gives us significant performance improvements, as well as a better underlying architecture. To repeat; this will not be a required update, although it will be strongly encouraged as it’s a huge leap forward technologically. One of the features which is currently not working in 1.7, but will be for release, is the Bitcoin payment protocol, which massively improves the payment request/receiving process for merchants. Fundamentally 1.7 is intended to prove we have the technical skills to maintain a stable, useful coin, and help drive/support adoption.
Once 1.7 is done, my immediate priority is technical documentation; we have a security specialist currently working on a guide to cryptocurrency security (setup, risks, best practices, etc.), to help give merchants and exchanges an in-depth understanding of how to securely use cryptocurrency. I’ll be addressing the need for formal standards in Dogecoin, and preparing RFCs for the “dogecoin:” URI and relay network protocol for submission to the IETF (and IANA for the URI).
Lastly; there was a post recently about the need for multi-signature addresses; I’d like to add my own “hell yes!” to that, although obviously I have to prioritise. If anyone else can look at these, that would be fantastic.
Correction: The cited issue with a rushed update to Blackcoin has no independent verification, and the sole source had significant to gain from attributing blame elsewhere. Have now removed the reference.