Author [EN] [ZH] [ES] [PT] [IT] [DE] [FR] [NL] [TR] [SR] [AR] [RU] [EN] [ZH] [ES] [PT] [IT] [DE] [FR] [NL] [TR] [SR] [AR] [RU] [EN] [ZH] [ES] [PT] [IT] [DE] [FR] [NL] [TR] [SR] [AR] [RU] Topic: Delegated Proof of Stake (DPOS) White Paper  (Read 12966 times)

0 Members and 1 Guest are viewing this topic.

Offline 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.

Offline santaclause102

  • Hero Member
  • *****
  • Posts: 2487
    • View Profile
Re: Delegated Proof of Stake (DPOS) White Paper
« Reply #1 on: April 04, 2014, 08:34:43 AM »
http://107.170.30.182/security/delegated-proof-of-stake.php

Why not publish / announce it on BTT so that people can give feedback and criticize it? This might uncover overseen flaws / inefficiencies before it is put into practice. This might also draw quality people / developers to the Bitshares community if they find the approach innovative (easy way of quality recruiting) and see an opportunity within the bitshares ecosystem and community to expand on their intellectual unrest. There also was a lot of good feedback for the BTS X attack vectors...

Here are some other approaches that might be of inspiration:
Peter Todd: http://sourceforge.net/p/bitcoin/mailman/message/31655380/   https://github.com/petertodd/decentralized-consensus-systems
Obelisk: http://libbitcoin.dyne.org/obelisk/
Nothing new probably: https://bitcointalk.org/index.php?topic=386460.0

Edit: Or some other circle (developer mailing list?) where you have a higher concentration of people that understand crypto currency protocols than on BTT...
« Last Edit: April 04, 2014, 08:40:49 AM by delulo »


sumantso

  • Guest
Re: Delegated Proof of Stake (DPOS) White Paper
« Reply #3 on: April 04, 2014, 12:36:02 PM »
Why not publish / announce it on BTT so that people can give feedback and criticize it? This might uncover overseen flaws / inefficiencies before it is put into practice. This might also draw quality people / developers to the Bitshares community if they find the approach innovative (easy way of quality recruiting) and see an opportunity within the bitshares ecosystem and community to expand on their intellectual unrest. There also was a lot of good feedback for the BTS X attack vectors...

+1

I am neutral regarding BTCtalk presence; but having more eyes to look at it can help a lot.

Offline toast

Re: Delegated Proof of Stake (DPOS) White Paper
« Reply #4 on: April 04, 2014, 02:09:36 PM »
Quote
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.

Quote
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...
Do not use this post as information for making any important decisions. The only agreements I ever make are informal and non-binding. Take the same precautions as when dealing with a compromised account, scammer, sockpuppet, etc.

Offline luckybit

https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline vikram

Re: Delegated Proof of Stake (DPOS) White Paper
« Reply #6 on: April 04, 2014, 07:22:09 PM »
Comments from: http://www.reddit.com/r/CryptoCurrency/comments/227be4/delegated_proof_of_stake_dpos_white_paper/cgk4j2a?context=3
Quote
This is very exciting; a really promising advancement. I have some concerns about their implementation, however:

Quote
    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.

Quote
    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.

Offline patrickb323

  • Jr. Member
  • **
  • Posts: 40
    • View Profile
Re: Delegated Proof of Stake (DPOS) White Paper
« Reply #7 on: April 04, 2014, 08:09:40 PM »
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.

Offline muse-umum

  • Hero Member
  • *****
  • Posts: 717
  • BitShares everything
    • View Profile
Re: Delegated Proof of Stake (DPOS) White Paper
« Reply #8 on: April 04, 2014, 08:14:08 PM »
Quote
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.

Offline vikram

Re: Delegated Proof of Stake (DPOS) White Paper
« Reply #9 on: April 04, 2014, 08:20:04 PM »
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.
« Last Edit: April 04, 2014, 08:22:19 PM by unlimited_power »

Offline bytemaster

Delegated Proof of Stake (DPOS) White Paper
« Reply #10 on: April 04, 2014, 08:20:41 PM »
Valid transactions from any source are included


Sent from my iPhone using Tapatalk
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 bytemaster

Re: Delegated Proof of Stake (DPOS) White Paper
« Reply #11 on: April 04, 2014, 08:27:07 PM »

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
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 muse-umum

  • Hero Member
  • *****
  • Posts: 717
  • BitShares everything
    • View Profile
Re: Delegated Proof of Stake (DPOS) White Paper
« Reply #12 on: April 04, 2014, 08:30:25 PM »
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.

Offline bytemaster

Re: Delegated Proof of Stake (DPOS) White Paper
« Reply #13 on: April 04, 2014, 08:32:56 PM »
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
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 CLains

  • Hero Member
  • *****
  • Posts: 2610
    • View Profile
  • BTS: clains
Re: Delegated Proof of Stake (DPOS) White Paper
« Reply #14 on: April 05, 2014, 07:07:34 PM »
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?

Vote for BTS-2 witness: spectral (1.6.30)

Follow https://steemit.com/@clains

 

Google+