One of the recurring themes we see discussed is that of developer power, and I wanted to talk about what the developers can do, what they can’t do, and what can be done can be done if you don’t agree. I lost a bet, recently, and it triggered a chain of events which is both pleasingly silly, and makes an excellent worked example of the processes put in place. I bet Sporklin that she couldn’t get BillyM2K to sign-off on making the reference client pink, and that I’d write the code for the change if he did; something that might generally be considered a fairly safe bet. I was wrong. This change was submitted as pull request #547, and if the conspiracy theories were correct, you would now have a pink reference client coming soon. However, there are rules to these things:
- All code must be reviewed by at least one senior developer.
- Developers may not review their own code.
As a senior developer submitted the code, Leofidus or Langerhans had to review and accept the change. As of the time of writing, they’ve neither rejected nor accepted the change, leaving it in a weird midway state. So what next for the pink QT, or any other change compared to the reference client? Well, now when 1.7.2 comes out, I’ll personally build 1.7.2-pink for those who are into that sort of thing. It will be a combination of all of the core of 1.7.2, with the minor tweaks to make it pink. Lets say, however, that I want to sneak the pink version in, so I modify the 1.7.2 source and try to give have the pink binaries linked on the website. Well, each client version is built independently by the three core developers, the results cryptographically signed and compared. Those have to match, or we go back and work out why they don’t match. No luck there either, sorry Sporklin. This is essentially the same process we ask others to follow; request changes via Github issues, or submit them as code via pull requests. We’ll review the change and act on it if appropriate. If you disagree with us, you’re welcome to fork (copy) the source code and build your own version instead. Naturally we’d expect the community to carefully consider source of any alternative wallet, though.
Administrivia for the week: Most of the developers are busy merging in the 150-ish changes from Bitcoin 0.9 to Bitcoin 0.9.2, to make the 1.7.2 client. I’ve been busy applying for new jobs, and sometimes poking at payment protocol. Please send feature requests/suggestions in via Github ( https://github.com /dogecoin/dogecoin/issues?state=open ), as it has the structures in place to support discussion, as well as helping users search for existing requests. There’s another major OpenSSL security issue that’s been discovered. A 1.7.1 client is being prepared, however unless you use RPC over SSL (a very unusual combination) you’re fine to stick to the existing clients. For those asking about changes, we’re still definitely not planning on any change to the proof of work scheme before block 600k, barring a security issue. There is also no planned change at the 600k block, I’m just using it as an estimate of where we might consider PoS adoption if we have to. p2pool adoption is still a good idea (and I’m aware I have a few username mentions about p2pool which I need to get back to). Things should be more back to normal next weekend, at least for a bit!