Author Topic: 1000 PTS - Ripple-Style Consensus Implementation [CLOSED]  (Read 8504 times)

0 Members and 1 Guest are viewing this topic.

Offline bytemaster

Nodes on the UNL are not really trusted, in fact they could be a collection of malevolent actors, the key thing about the UNL is that they are ONLY assumed not to be in collusion, therefore a UNL which consists of CIA, KGB & Chinese Intelligence is actually a valid and very good UNL

See the following for precise definitions, rationale, etc

https://ripple.com/wiki/Consensus#Not_colluding
https://ripple.com/wiki/Unique_Node_List

Also, in the context of Ripple, because each transaction is self-validating using ECDSA AND
transaction ordering is deterministic (lexicographic by tx hash) the only possible mischief by a node is
to withhold a transaction from its consensus proposal.

Cheers ...

Alex, yes I recognize that the nodes need not be trusted aside from being on the UNL to prevent Sybil attacks.   I want to utilize the Ripple algorithm in as straightforward manner as possible.  I would even be happy to use the Ripple code if it can be pulled out and integrated with BitShares. 
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline alexkravets

  • Full Member
  • ***
  • Posts: 81
    • View Profile
Nodes on the UNL are not really trusted, in fact they could be a collection of malevolent actors, the key thing about the UNL is that they are ONLY assumed not to be in collusion, therefore a UNL which consists of CIA, KGB & Chinese Intelligence is actually a valid and very good UNL. Non-collusion is therefore a much much weaker requirement than full trust.

See the following for precise definitions, rationale, etc

https://ripple.com/wiki/Consensus#Not_colluding
https://ripple.com/wiki/Unique_Node_List

Also, in the context of Ripple, because each transaction is self-validating using ECDSA AND
transaction ordering is deterministic (lexicographic by tx hash) the only possible mischief by a node is
to withhold a transaction from its consensus proposal.

Cheers ...

Offline bytemaster

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=pj1QVb1vlC0

https://ripple.com/wiki/Unedited_Notes

The 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!   
« Last Edit: January 30, 2014, 05:51:47 am by bytemaster »
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.