<p>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. </p>

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

<p>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.)</p>

<p>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.</p>

<p>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.</p>

<p>Maybe there's an approach here that kills two birds with one stone.  </p>

<p>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. </p>

<p>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.</p>

<p>Thus the end result is:</p>

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

<p>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.</p>

<p>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.</p>

CC BY-SA 3.0
2012-04-28T04:14:36.530Z
How about the genesis block contains payments to 2 addresses.  Any payment from the first address to another turns the owner of the recipient address on as a miner, and any payment from the 2nd address turns the recipient off.  This way the owner of the private keys of the addresses funded by the genesis block has the ability to grant and revoke the ability to mine to arbitrary nodes, given an address the node controls.
Chris Moore
CC BY-SA 3.0
2012-04-28T08:51:52.967Z
Sure, that would probably work.  Could even use the amount as a data fields too -- to notify the "last valid block" that the specific miner was authorized to mine.
Stephen Gornick
CC BY-SA 3.0
2012-04-29T00:36:40.190Z
Well, I was hoping the amount could be 1 satoshi, or even 0 satoshi (may need to modify the protocol to allow zero-valued payments from the genesis block addresses).  The block that the miner is enabled or disabled from is the block in which the transaction appears...
Chris Moore
CC BY-SA 3.0
2012-04-27T23:37:41.100Z
2012-04-28T01:02:53.167Z
2012-04-28T01:02:53.167Z
Stephen Gornick
<p>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. </p>

<p>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.</p>

<p>Political issues aside, some enhancements have been made to the main trunk code.</p>

<p>Are there any enhancements to the trunk code that are useful for general purpose implementations, or walled garden approaches?</p>

CC BY-SA 3.0
2012-04-26T18:17:59.880Z
If you don't elaborate what exactly do you plan to do, we can't know what is best for you.

Looks like you are planning to build something that departs in a quite substantial way from Bitcoin, and I'm wondering if relating to it at all does make any sense.
o0'.
CC BY-SA 3.0
2012-04-26T20:12:24.937Z
Merged mining is the standard way to bootstrap the hashrate of alternative currencies, if they're similar enough to Bitcoin.
Meni Rosenfeld
CC BY-SA 3.0
2012-04-27T08:03:10.420Z
@MeniRosenfeld and it also allows to crush them at no cost (as they usually deserve, btw). Not that they couldn't be crushed anyway by a resourceful opponent.
o0'.
CC BY-SA 3.0
2012-04-27T13:30:41.527Z
It's early days so I don't want to go into much detail. It should be enough to say that I would like to use a bitcoin based system as a highly scalable way to keep account of transactions between people, in something that is not a currency.
barrymac
CC BY-SA 3.0
2012-04-27T13:41:10.170Z
I've edited the question so it's hopefully more clear now what I'm trying to find out
barrymac
CC BY-SA 3.0
2012-04-27T20:12:01.143Z
If all you have is a hammer, everything looks like a nail. - Abraham Maslow
Stephen Gornick
<client><bitcoin-core><alternatives><blockchain-fork>
What client to use for an alternative special purpose blockchain?
barrymac
# What client to use for an alternative special purpose blockchain?

(Asked by: username_0 on 2012-04-26)

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?

**Tags:** client, bitcoin-core, alternatives, blockchain-fork

> **Comments:**
> **username_1**: If you don't elaborate what exactly do you plan to do, we can't know what is best for you.  Looks like you are planning to build something that departs in a quite substantial way from Bitcoin, and I'm wondering if relating to it at all does make any sense.  
> **username_2**: Merged mining is the standard way to bootstrap the hashrate of alternative currencies, if they're similar enough to Bitcoin.  
> **username_1**: @username_2 and it also allows to crush them at no cost (as they usually deserve, btw). Not that they couldn't be crushed anyway by a resourceful opponent.  
> **username_0**: It's early days so I don't want to go into much detail. It should be enough to say that I would like to use a bitcoin based system as a highly scalable way to keep account of transactions between people, in something that is not a currency.  
> **username_0**: I've edited the question so it's hopefully more clear now what I'm trying to find out  
> **username_3**: If all you have is a hammer, everything looks like a nail. - Abraham Maslow  

---

## 1 answers

### Answer by username_3 on 2012-04-27. Score: 3 | Accepted answer

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.

> **Comments:**
> **username_4**: How about the genesis block contains payments to 2 addresses.  Any payment from the first address to another turns the owner of the recipient address on as a miner, and any payment from the 2nd address turns the recipient off.  This way the owner of the private keys of the addresses funded by the genesis block has the ability to grant and revoke the ability to mine to arbitrary nodes, given an address the node controls.  
> **username_3**: Sure, that would probably work.  Could even use the amount as a data fields too -- to notify the "last valid block" that the specific miner was authorized to mine.  
> **username_4**: Well, I was hoping the amount could be 1 satoshi, or even 0 satoshi (may need to modify the protocol to allow zero-valued payments from the genesis block addresses).  The block that the miner is enabled or disabled from is the block in which the transaction appears...  

---

