Shaving Satoshi's Yak

Ross Nicoll bio photo By Ross Nicoll

In software programming, "Shaving a Yak" refers to ending up doing a task vastly unrelated to the one you started with, in order to fix a sequence of interconnected problems. There's a really good explanation of the origins at http://sethgodin.typepad.com/seths_blog/2005/03/dont_shave_that.html. Yak shaving is generally seen as a bad thing, because sometimes you just have to get on and just get something built, not bother with making it perfect.

That sort of "just get it going" approach is fine when you're in a startup, or trying go get the first version of a cryptocurrency out of the door and just have something that works at all. That's not where we are any more, though. We're a new coin, sure, but one based on old foundations. It's time to go shave that Yak.

So, we want the price to support our mining. To do that, it has to be higher than it currently is, as the halvenings progress. The best way of doing that is to push forward with adoption of the coin. To do that it needs to be easier to spend and easier to accept.

To make it easier to spend, we need a better client software user interface. Trying to modify the current client without working with Bitcoin, would mean duplicating effort, as they're working in parallel, and would also make it much harder to merge in their other work. So first we need to work with Bitcoin on their re-architecture of the client (you can see their lead developer's priorities at http://www.coindesk.com/wladimir-van-der-laans-top-four-priorities-bitcoin/ ) to separate the UI from the core.

For the merchant side, 1.7 brings a lot of stability to the core client. I've mentioned earlier we're working on payment protocol support; that's not going to make it into 1.7 in the end, as we need more time to hammer out the standards and make sure we build foundations that will stand for decades.

Payment protocol seeks to solve a number of problems, primarily the tedious cutting & pasting of addresses when making payments, and generally streamlines the payment process from the user point of view. An example workflow for a customer might be:

  1. User goes to checkout.
  2. User confirms their order, and is taken to payment page.
  3. User follows a link on the payment page, which opens Dogecoin client.
  4. Dogecoin client asks user to confirm payment.
  5. User confirms payment.
  6. Dogecoin client displays confirmation that payment was sent.
  7. Merchant's website shows confirmation that payment was received.

While the existing standards are fine if you only take into account the needs of Bitcoin, we want to bring in a standard which can be used by any coin. That means extensions to the standard, as well as working with the relevant standards bodies (IETF, IANA) to ensure those standards are officially recognised. The main changes we're looking at are changing how the network to be used for payment is specified (from pre-defined short names for each network, to the genesis block hash for the network to be used), and adding clear specifications of how to handle error states (for example what happens if there's a network failure while sending a payment).

As a more general round up of what's been going on; tinyminer found a major issue with mining in 1.7 beta 1 (it would try spending immature coins, and therefore transactions were being rejected), and we've fixed that in 1.7 beta 2. What we need most from the community right now is as many eyes as we can get on 1.7 beta 2, so if you've thought about testing but aren't doing it yet, please grab 1.7 beta 2 from http://www.reddit.com/r/dogecoin/comments/23p9xw/doegcoin_core_17_beta_2_update_if_youre_on_beta_1/

We've started working on Dogecoin standards derived from Bitcoin standards, and you can see those taking shape at https://github.com/dogecoin/dips - longer term we'll hopefully have our own standards too, but right now we're just tweaking things Bitcoin does. You can see me slowly assembling an example merchant app at https://github.com/rnicoll/payment_protocol_example.

Lastly, I'd like to give credit one of the developers who doesn't get much attention; Leofidus runs key parts of the testnet infrastructure which we depend on to test the clients, and spent a lot of time this week working on test cases to ensure the quality of our code.

Have a great week everyone!

General admin stuff:

Moolah has set up a developer fund (DFundmtrigzA6E25Swr2pRe4Eb79bGP8G1) for anyone who wants to tip the developers. We're still working out exactly how that will be split, but it looks like at each client release we'll allocate funds for covering costs (server hosting, etc.), and then split remaining tips between developers involved in that release.

For everyone who asked about a good way to know about new client releases (exchanges & merchants, this particularly means you), there is now an official Dogecoin release mailing list hosted by Sourceforge: https://lists.sourceforge.net/lists/listinfo/dogecoin-releases

The halvening is Monday-ish. Having said it would be 5am-ish, it's now estimated at 11am-ish ( http://www.somegeekintn.com/doge/half.html) and honestly I expect that to slide further. I have the day off and will be here and on IRC helping settle nerves (I will not be doing technical work, because we have quintuple-cross-checked the whole thing, and it will not require any intervention).

We continue to monitor Wafflepool. One thing that becomes apparent is that the reported network hashrate is calculated as an average, which means Wafflepool jumping onto and out of the coin basically reduces the accuracy of that data. So, the difficulty drops, they jump in and mine, which causes actual network hash rate to briefly jump, but they jump back out as difficulty increases, so the effect on reported network hash rate is minor. That means as a rule, we're under-reporting network hash rate, from what I can tell.