Delegated Proof of Stake (DPOS) White Paper

[santaclause102]

From bitcointalk, https://bitcointalk.org/index.php?topic=558316.msg6086884#msg6086884

Sounds great on paper - hoping to see it implemented somewhere soon!

Quick question: what prevents Ripple from utilizing DPOS to generate future unique node lists?

Nothing prevents Ripple from doing this..

The difference is: It wouldn't make much of a difference towards the current state of ripple because they control more than 50% of the money supply anyway... The more distributed BTS are the more decentralized it is!!

Inside Ripple the 90% are divided among many players..... so it may still be of some use to them... especially if they ever want to sell.

Good point. But the potential for collusion is still higher than with BTS shareholders...

[bytemaster]

From bitcointalk, https://bitcointalk.org/index.php?topic=558316.msg6086884#msg6086884

Sounds great on paper - hoping to see it implemented somewhere soon!

Quick question: what prevents Ripple from utilizing DPOS to generate future unique node lists?

Nothing prevents Ripple from doing this..

The difference is: It wouldn't make much of a difference towards the current state of ripple because they control more than 50% of the money supply anyway... The more distributed BTS are the more decentralized it is!!

Inside Ripple the 90% are divided among many players..... so it may still be of some use to them... especially if they ever want to sell.

[santaclause102]

From bitcointalk, https://bitcointalk.org/index.php?topic=558316.msg6086884#msg6086884

Sounds great on paper - hoping to see it implemented somewhere soon!

Quick question: what prevents Ripple from utilizing DPOS to generate future unique node lists?

Nothing prevents Ripple from doing this..

The difference is: It wouldn't make much of a difference towards the current state of ripple because they control more than 50% of the money supply anyway... The more distributed BTS are the more decentralized it is!!

[bytemaster]

From bitcointalk, https://bitcointalk.org/index.php?topic=558316.msg6086884#msg6086884

Sounds great on paper - hoping to see it implemented somewhere soon!

Quick question: what prevents Ripple from utilizing DPOS to generate future unique node lists?

Nothing prevents Ripple from doing this..

[CLains]

From bitcointalk, https://bitcointalk.org/index.php?topic=558316.msg6086884#msg6086884

Sounds great on paper - hoping to see it implemented somewhere soon!

Quick question: what prevents Ripple from utilizing DPOS to generate future unique node lists?

[bytemaster]

4 million potential candidates with annual renewal may already be too many.  I suspect we may want to make candidates pay to be considered to cut down on those not serious about the job. 


Sent from my iPhone using Tapatalk

[muse-umum]

Valid transactions from any source are included


Sent from my iPhone using Tapatalk

Thanks.
This part is very important. It would be better to have it known in whitepaper.

[bytemaster]

nice job.

In a previous thread a requirement was mentioned for each representative having to put up some coin in holding to be eligible for this task?  did you determine that this was no longer necessary?

in section "Keeping Representatives Honest", your explanation states that it would be up to the wallet software to prevent new transactions tagged with an invalid-signing-representative id.   why wouldn't the network itself prevent these new transactions? Or the network could allow these transactions but overwrite with null for a representative id.   if some popular wallet software had a default representative id, and this representative was coerced or somehow turned malicious, the wallet might not prevent new transactions and thus the users could all still vote for the problematic representative.  I think the network itself needs to prevent this case I'm not rely on the wallet software.

After designing it out we realized that an individual has no control on whether their block gets included  even when they produce on time. 

It would allow the person after them to skip them and thus punish them.  This risk seemed worse than just not paying them. 


Sent from my iPhone using Tapatalk

[bytemaster]

Valid transactions from any source are included


Sent from my iPhone using Tapatalk

[vikram]

all valid transactions of the blocks inside the shorter chain are re-added to the pool of queued transactions and will be included in another block.

Yes.

[muse-umum]

Without the barriers to entry caused by proof of work, the honest majority would identify the attack and issue a fork of the code that ignored blocks produced by the attacker. It would be disruptive, but not fatal.

Sorry for my poor English and understanding. If these blocks are really ignored, what will happen to the valid transactions included in them ?

Would you implement something like how Bitcoin handles orphan blocks? (I can't find this part in PTS /Bitshares /keyhotee codes in Github)

https://en.bitcoin.it/wiki/Block_chain

Blocks in shorter chains (or invalid chains) are not used for anything. When the bitcoin client switches to another, longer chain, all valid transactions of the blocks inside the shorter chain are re-added to the pool of queued transactions and will be included in another block. The reward for the blocks on the shorter chain will not be present in the longest chain, so they will be practically lost, which is why a network-enforced 100-block maturation time for generations exists.

These blocks on the shorter chains are often called "orphan" blocks. This is because the generation transactions do not have a parent block in the longest chain, so these generation transactions show up as orphan in the listtransactions RPC call. Several pools have misinterpreted these messages and started calling their blocks "orphans". In reality, these blocks have a parent block, and might even have children.

[patrickb323]

nice job.

In a previous thread a requirement was mentioned for each representative having to put up some coin in holding to be eligible for this task?  did you determine that this was no longer necessary?

in section "Keeping Representatives Honest", your explanation states that it would be up to the wallet software to prevent new transactions tagged with an invalid-signing-representative id.   why wouldn't the network itself prevent these new transactions? Or the network could allow these transactions but overwrite with null for a representative id.   if some popular wallet software had a default representative id, and this representative was coerced or somehow turned malicious, the wallet might not prevent new transactions and thus the users could all still vote for the problematic representative.  I think the network itself needs to prevent this case I'm not rely on the wallet software.

[vikram]

Comments from: http://www.reddit.com/r/CryptoCurrency/comments/227be4/delegated_proof_of_stake_dpos_white_paper/cgk4j2a?context=3

This is very exciting; a really promising advancement. I have some concerns about their implementation, however:

    2.1 Becoming a Representative

    To become a representative you must register your public key with the network and be assigned a 32 bit unique identifier. This identifier can then be referenced in the header of every transaction.

32 bits only provides about 4 Billion possible IDs. Assuming that many will be lost, forgotten, etc., I think that this is not nearly enough. This is exactly the problem that currently plagues IPv4 and is the main reason why a transition to IPv6 is currently underway. There is no reason not to use 64 bits (or even just 48) as a rep's ID, and it provides the overhead that will assure that there will be enough unique IDs for the next hundred or even thousand years. 32 bits is emphatically not enough.

I understand that only 100 reps are working at a time (but why only 100?), but since being a rep is well-compensated, I foresee that most users of a currency that adopted this system would also "throw in their hat" to be potentially voted to be a "working" rep (among the 100) - and they will all need IDs.

    It may be possible for a single individual or organization to control multiple representatives in the chain, but this process would involve deceiving a large percentage of the shareholders into supporting sock-puppets.

This seems to just brush off the issue. I see no actual methods, incentives or reasons that would prevent sockpuppet representatives - after all, on the internet, nobody knows you're a dog (or a sockpuppet). The author assumes that "deceiving a large percentage of the shareholders" is somehow inherently more challenging than getting them to vote for a legitimate representative, but it certainly isn't as I can see it. Shareholders are still not going to be meeting most of these representatives in real life.

The only possible solution I can see to this would be a strong Web of Trust that can trace any sockpuppets to a common source - but since most trust signing is going to happen between pseudonyms on the internet, anyway, even this would probably just become "some silly formality" that users engage in without really understanding what they're doing, and a new sockpuppet would have no problem finding itself well validated in the web in a short time.

All in all, it's a very promising idea, and I don't think that these challenges I've described are impassible. I would look forward to a response (and perhaps even an updated proposal) from the author(s) on these concerns.

[luckybit]

http://107.170.30.182/security/delegated-proof-of-stake.php

Excellent. 

[toast]

Lastly, proof of work creates a barrier to entry that prevents incumbents from being easily displaced. Compared to Bitcoin, DPOS is at least 10x more decentralized in block production and perhaps infinitely more decentralized relative to market competition.

The process behind DPOS when combined with TaPOS produces a network that has more provable consensus behind it than Bitcoin, Peercoin, and Nxt by a factor of 3 or more.

Those are awfully specific assertions...