I am looking for someone to develop a flexible, reusable, ripple-style consensus implementation. This algorithm should be transaction content neutral. The purpose of the algorithm is to allow a group of trusted nodes (Unique Node List) to reach consensus about the content of a merkel tree and timestamp for the next block and should add new blocks as quickly as possible.
For the purpose of this general purpose algorithm a transaction is just a blob of data and a transaction ID (hash of data) is valid if the node merely has a copy of this blob of data and the TRX ID does not already exist in the block chain.
The UNL is a database of IP addresses and Public Keys and all nodes connect to all other nodes.
Blobs of data are distributed among the nodes in the UNL using bitcoin style INV and GET_INVENTORY and GET_MESSAGE messages.
This code should be built on top of the BitShares repository which already has primitives for the following:
1) Blob broadcast via the bitchat (email) system
2) Secure/encrypted sockets
3) JSON / Binary serialization
4) Elliptic Curve Utilities, etc....
This code should be built to follow coding conventions used in the bitshares code base.
This code should be built with the intention of being an API, a reusable component of a DAC toolkit.
This code must be developed in the open, on github
If a team of people work on it, then all participants must agree to the division of the bounty and github commits will track who did what.
For a video explanation of the algorithm:
http://www.youtube.com/watch?v=pj1QVb1vlC0https://ripple.com/wiki/Unedited_NotesThe code must be complete with documentation and a working network of at least 20 nodes where new transactions are introduced to random nodes at random intervals at up to 1 MB of transaction data every 5 minutes with an average transaction size of 200 bytes.
Like all bounties, I am looking to purchase this as an off-the-shelf solution to the consensus problem with our code. It must build as part of the bitshares code base.
I will provide feedback on the API as it develops and steer this in the direction I want, but suspect that the time / cost to implement should be far less than the bounty!