4

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?

  • 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. – o0'. Apr 26 '12 at 18:17
  • Merged mining is the standard way to bootstrap the hashrate of alternative currencies, if they're similar enough to Bitcoin. – Meni Rosenfeld Apr 26 '12 at 20:12
  • @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'. Apr 27 '12 at 8:03
  • 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 Apr 27 '12 at 13:30
  • I've edited the question so it's hopefully more clear now what I'm trying to find out – barrymac Apr 27 '12 at 13:41
3

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.

  • 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 Apr 28 '12 at 4:14
  • 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 Apr 28 '12 at 8:51
  • 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 Apr 29 '12 at 0:36

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.