What client to use for an alternative special purpose blockchain? Lets say one wanted to create a blockchain for the purposes of providing a scalable back-end for accounting for the trade of some arbitrary unit between people. It would not be a tradeable currency. 

A possible requirement for the client would be third party authentication to participate in the blockchain. I'm thinking this because a small niche population could render the blockchain vulnerable to 50% attacks, perhaps there are other ways to prevent this.

Political issues aside, some enhancements have been made to the main trunk code.

Are there any enhancements to the trunk code that are useful for general purpose implementations, or walled garden approaches?
This answer presumes that you need to retain the resilience of a P2P network where there is not a single point of failure.  It also presumes that you need an authoritative source that has the ability to maintain control so that the network is not vulnerable to a 51% attack. 

I suppose you could fork the stock bitcoin client without too much effort to create an alt-chain that accomplishes this.

On the fork, add to the block verification a step to also check that each mined block includes a transaction from one of the authorized miners.  The way to tell if the block came from an authorized miner is to have the miner include a spend transaction that comes from a private key assigned to that miner.  (Miners would never broadcast these transactions, so if the transaction appears in a block it would mean only an authorized miner solved that block.)

There are a number of ways the client could learn the list of public addresses for the "authorized miners" list.  This list could be hard-coded into the client even, initially, if needed.

There's the risk of how to handle the situation where an authorized miner ends up compromised or otherwise needs to be removed from the list.

Maybe there's an approach here that kills two birds with one stone.  

Have the master node broadcast a heartbeat transaction periodically.  This could be done by having the master mine a block that inserts a chunk of data, similar to how an altcoin that does merged mining works -- it has an exception as to what it considers as a valid proof of work.  In this case, any block that is from the master node is considered as a valid proof of work.  The method to use as proof that the block truly is from the master node is for the block to include a spend transaction from the public address owned by the master node. 

That heartbeat from the master could also include a checkpoint hash (e.g., "confirmed by the master authority") -- to limit the damage a compromised miner could do.

Thus the end result is:


Normal nodes cannot mine but will exist as P2P nodes that store blocks and relay transactions.
Miners that are authorized do compete, on a proof-of-work basis.
A master node has power of authority and can intervene (i.e, always has 50%+1 majority) if needed.
Frequent checkpoints from the master can limit the risk from compromized miner nodes.


Only miners who are trusted would mine but even if one of them goes bad, the master can clean up by rewriting all the way back to the last checkpoint.

So it doesn't seem to be too much effort to fork the bitcoin trunk to work in this manner.  Centralized systems are always much easier than decentralized.