1.9 is dead, introducing 1.10

Ross Nicoll bio photo By Ross Nicoll

I quickly review the previous post each time I start a new one, and in that context it’s slightly absurd that the last post was titled “On Course” and this one is about a drastic course change.

Before I dive into that - we have a security update coming out soon. Bitcoin’s developers yesterday announced that there will be a security announcement on July 7th. The exact issue won’t be detailed until then, but once it is there will of course be a Dogecoin update to match. I’ve taken a best-guess at which parts of Bitcoin Core 0.10.2 this involves, and have back-ported them to Dogecoin 1.8 (to become 1.8.3 when released), and once the issues are confirmed we’ll do a formal release. I’ll announce an alpha of that version as soon as I can (next few days I hope).

Back to the regular update, if you’ve been following progress in detail, you may have noticed we’ve been working on Dogecoin Core 1.9 for about 6 months now. If you’re playing really close attention, you’d see we’re about halfway done, and attempts to streamline the process have helped but still aren’t reducing the developer time taken in the way we might have hoped.

Meanwhile, Litecoin and Namecoin have released their Bitcoin Core 0.10-derived clients, so what’s taken us so long? Well, we made a decision early on to test each change to Bitcoin Core in turn - very thorough, but also very time consuming. Litecoin and Namecoin on the other hand opted to start with Bitcoin Core 0.10 and apply the changes to make it work for their coins, instead.

With the imminent release of Bitcoin Core 0.11 (RC2 is out now), we’re having to accept that we have poured huge amounts of effort into an approach that isn’t working. Instead we’re forced to regretfully abandon Dogecoin Core 1.9 (the 0.10 based client) and jump directly to Dogecoin Core 1.10, based on Bitcoin Core 0.11, to catch up.

There’s something we need to talk about for Dogecoin Core 1.10 (y’know, I may yet suggest we jump to 1.11 so I don’t lose track of which version is which), which are the fees. Initial Dogecoin fees were set very low, and we expected that with the rising price of Dogecoin they would settle at a sensible level

  • they haven’t. What this means is it’s far too cheap to send a transaction with Doge, compared to the cost of the disk and bandwidth it uses to send it.

As a reminder, Bitcoin’s fee schedule is essentially 0.0001BTC per 1kb of transaction, with some transactions allowed to be free. That works out at $0.025/kb, or 1-2 cents for most transactions. Dogecoin’s feed schedule is 1 DOGE per 1kb, with a 1 DOGE minimum, plus 1 DOGE for each output below 1 DOGE. That’s a lot more complex, and unnecessarily so. It also works out at around $0.0002/kb, which is very very low compared to the cost of running a mining installation.

I’ll do a full post with analysis later, especially as I think cryptocurrency in general needs to reconsider how it calculates fees (as an example the number of outputs compared to inputs makes a difference to memory required to handle future transactions, which is one of the biggest costs, but completed disregarded currently). We absolutely want to ensure Dogecoin remains cheap and accessible, but we also have to ensure that we retain miners.

Lastly, on the subject of infrastructure, I’ve started discussion on how we might streamline the blockchain. SPV clients (which I’ve talked about in earlier posts) will help newbie shibes get started, but miners and large services will still need to run full nodes and the growing blockchain means their costs increase significantly over time. One option being considered is that of adding a new genesis block around the 2 millionth block (so another 18-24 months away), from which clients can start with just the minimum of information (unspent transaction outputs). There’s some major technical hurdles to overcome, and this isn’t a complete solution, but I do think it has the possibility to significantly improve the situation.

Ross