1000 PTS - Ripple-Style Consensus Implementation [CLOSED]

[toast]

brb taking out loans to buy AGS
 

[bytemaster]

This bounty is now closed.  I have implemented 50% of it already and will have the rest done this week.

[alexkravets]

Good to see this going in house. This tells me things are getting serious at Invictus.

I only would like to caution against the temptation to de-APIify it and commingle it with BitShares domain.  If it's impossible to build a decentralized DropBox replacement DAC just as easily as it will would be to build BitShares on top of it then it's become an internal BitShares implementation artifact.

[barwizi]

this is a bit complicated and i tried finding info on ripple but it ain't out there. if anyone has coding time do the following create a system with defined security check points, say we have "security nodes" , a transaction can only be created when connected to at least two "security nodes".  Once a transaction is made it is transmitted through the network and only confirmed when all security nodes have consensus.

To avoid Ddos issues, security nodes are not permanent, they could be any machine in the network. this is how it will function:-

1) at any given time there are ten security nodes each is in possession of a token that verifies it's designation. After a certain number of blocks/transactions the tokens are passed to another machine on the network. If a machine with a token goes offline, one of the others will generate and pass on two tokens on the next round to cover for the lost one. further, timers are place on network activity of each node keeping record of how many transactions it has transmitted and how many times it has been in possession of a token This is then used for trust ratings in the event of a fork, such modification can be done in 24hrs to the BTC code.

[bytemaster]

Unless someone can demonstrate meaningful progress on this bounty we are going to take it in-house.   You have 24 hours to commit to delivery and show you have code already underdevelopment.

[toast]

Can you post a repo? I want to see

[naturalog]

I will tend to API-ize the ripperd code

[bytemaster]

Wonderful!  I will need this algorithm by March 1. 

[naturalog]

Beginning to take a deep look on this project

[barwizi]

Ledger system consensus. interesting lol 3k will get immediate attention

[hasher]

there one guy who can help, he have 20 years of digital experience:
_________________________
http://www.linkedin.com/pub/david-schwartz/34/67b/8b7
David Schwartz's
        Chief Cryptographer at Ripple Labs
        Chief Technical Officer at WebMaster Incorporated
        Director of Software Development at WebMaster Incorporated
        Senior Network Engineer at Worldwide Internet Solutions

        Director of Network Services at Internet Gateway Connections
        Partner at Cardiophonics
        Software Developer at RE/MAX
        CEO at David Schwartz Enterprises
________________
he could be easy found and asked about anything  on stackexchange.com (he answered my two questions about Ripple economics without any arrogance before), maybe he could suggest something (or someone)to our community:
http://bitcoin.stackexchange.com/feeds/user/85

[bytemaster]

Is this definitely the consensus protocol that will be used for bitshares? UNLs make me a bit nervous, but I'm still pretty new to ripple's approach.
It would be cool if a node's score could be improved by signing it with a keyhotee ID. If I remember correctly there was a way to improve your ID's rep by destroying money in its name, this way the solution looks more like PoS and relies less on guessing whether nodes are unique or not

Toast, I understand your concern about UNL and I have plans to address it.  This bounty just produces one piece of the puzzle, the selection of the UNL is a separate process. 

It all boils down to the following:
1) Mining is centralized one block at a time... very bad for blockchains that implement markets
2) Mining centralizes in control of specialized hardware that the little guy will never control... so is not an option
3) Long-term security based upon proof-of-stake where everyone ratifies the blockchain
4) Short-term security based upon a set of mostly connected (via trust) UNL nodes.
5) UNL nodes vote to add new nodes to the list.  Once a new node has received votes from at least 51% of existing nodes it is included.
6) Existing nodes have incentive to grow the UNL list because the larger trusted set of the UNL the more secure the network.

As long as the majority of the existing nodes vote in a growing number of diverse nodes people will have faith in the network not to collude. 

The critical thing is that even the nodes on the UNL list cannot collude to rewrite history because of the Proof of Stake, at most they could collude to block transactions but this is no difference than mining pool collusion.   The nodes that end up voting to exclude transactions would be public and people could just fork the main chain and select a new group to trust with the consensus process.

The way you keep the UNL list of nodes 'honest' is to make it incredibly easy for a competitor to take over if they gain popular support.

[toast]

Is this definitely the consensus protocol that will be used for bitshares? UNLs make me a bit nervous, but I'm still pretty new to ripple's approach.
It would be cool if a node's score could be improved by signing it with a keyhotee ID. If I remember correctly there was a way to improve your ID's rep by destroying money in its name, this way the solution looks more like PoS and relies less on guessing whether nodes are unique or not

[bytemaster]

Sorry, I meant my post as a clarification for bounty takers.

C++ is not my forte, but my impression after looking at

https://github.com/ripple/rippled

Is that although the entire code base is pretty large, the core domain-independent consensus part is under a thousand lines and should be extractable, however thankless task that maybe :-)

Cheers ...

Yep, that was my analysis of the code as well.  The goal for this bounty is to turn that code into something with a solid API and reusable in many different contexts.   

So I would like to clarify that this bounty should be heavily focused on making this reusable, well documented, and flexible.  We have at least two different code bases that we would like to use the code in:  BitShares and Bitcoin so a solid design is expected as part of adapting Ripple's code. 

[alexkravets]

Sorry, I meant my post as a clarification for bounty takers.

C++ is not my forte, but my impression after looking at

https://github.com/ripple/rippled

Is that although the entire code base is pretty large, the core domain-independent consensus part is under a thousand lines and should be extractable, however thankless task that maybe :-)

Cheers ...