Author Topic: DPOS vs POS vs POW - white paper?  (Read 6836 times)

0 Members and 1 Guest are viewing this topic.

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
This is nearly the same... I think the amortization constant has been reduced to 2 from 101 in this scheme, because the current block producer is still the only one to have authority over the current block in production?

Yeah, to be fair we should assume up to 20% of the witnesses could be absent. So let's assume there are 101 witnesses and 20 of them do not participate in the round. Let's also assume that all 20 happen to be ordered consecutively in that round (which would be very rare). In that case you would have to wait for 21 block intervals to get the "ledger close" with the method I describe while it would still only take Ripple 1 block interval. But the probability of this scenario is incredibly rare, so in practice it wouldn't really make a difference.

Offline monsterer

DPOS could achieve the same thing if all witnesses sent their signature for the previous block to the next witness that is supposed to produce a block. That witness would collect all the signatures and include it in the block. If a large enough quorum (e.g. 80% to be consistent with Ripple) of active witnesses signed off on a particular block, then that is essentially the same thing as a ledger close in Ripple. This means in practice a block could usually be considered valid by a super majority of the active delegates in 2 seconds (two blocks with 1 second intervals).

This is nearly the same... I think the amortization constant has been reduced to 2 from 101 in this scheme, because the current block producer is still the only one to have authority over the current block in production?
My opinions do not represent those of metaexchange unless explicitly stated.
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline arhag

  • Hero Member
  • *****
  • Posts: 1214
    • View Profile
    • My posts on Steem
  • BitShares: arhag
  • GitHub: arhag
Bitccoin and nearly every other derivative (btishares included) uses an amortized consensus; the network of block producers gradually comes to an consensus on the transactions in a given block - they do this by building other blocks on top of the previous one, thereby adding a confirmation. This is why you need to wait for multiple confirmations before processing a transaction, because otherwise you only rely on the opinion of one entity, instead of the majority of the network.

Ripple, however, uses a non amortized (there is probably a better word) consensus, in that all the block signers actually work simultaneously on the current block in production. This means you get an entire network's worth of consensus on new transactions as soon as the block is produced.

DPOS could achieve the same thing if all witnesses sent their signature for the previous block to the next witness that is supposed to produce a block. That witness would collect all the signatures and include it in the block. If a large enough quorum (e.g. 80% to be consistent with Ripple) of active witnesses signed off on a particular block, then that is essentially the same thing as a ledger close in Ripple. This means in practice a block could usually be considered valid by a super majority of the active delegates in 2 seconds (two blocks with 1 second intervals).

If you want to avoid bloating each block with extra signatures from 80% of active witnesses you can use threshold signatures instead (as I have proposed here). You can increase the delay from 1 block to some other small number of blocks to give the witnesses enough time to coordinate the threshold signature generation. For example, instead of this threshold signature signing the previous block it could sign for the block that is 3 blocks in the past. In that case a block could be considered valid by a super majority of the active delegates in 5 seconds. However, for the threshold signature generation to be simple and fast, ECDSA and secp256k1 aren't going to cut it. We would need to use EdDSA which is a variant of Schnorr signature based on Twisted Edwards curve. The NaCl library seems to be a good implementation of this digital signature scheme for regular signatures, but it would need to be modified (see this paper for the cryptography necessary) to support threshold signature generation. Of course if that code was created and integrated into BitShares, many other users (particularly businesses who want to hide their authentication organizational structure from the public) could also take advantage of threshold signatures. Plus there are lots of other benefits to using EdDSA as well.
« Last Edit: July 03, 2015, 10:06:44 am by arhag »

Offline monsterer

On a separate note since you mentioned Ripple and closed consensus groups, DPOS seems to be a protocol that can be used to decentralize the UNL's that Ripple uses for its consensus algorithm.  Ripple seems to be more well-suited for permissioned networks such as for current financial networks so they might not care as much about being centralized, but a combination of DPOS and the Ripple protocol is an intriguing combination.  I still like the Ripple ideas of credit/trustlines/LETs/pathfinding etc... would be nice to possibly incorporate those down the road.

I'd personally like to see a trustless ripple - their consensus mechanism is interesting in that its the first non-amortized, closed group consensus.

Bitccoin and nearly every other derivative (btishares included) uses an amortized consensus; the network of block producers gradually comes to an consensus on the transactions in a given block - they do this by building other blocks on top of the previous one, thereby adding a confirmation. This is why you need to wait for multiple confirmations before processing a transaction, because otherwise you only rely on the opinion of one entity, instead of the majority of the network.

Ripple, however, uses a non amortized (there is probably a better word) consensus, in that all the block signers actually work simultaneously on the current block in production. This means you get an entire network's worth of consensus on new transactions as soon as the block is produced.

However, in practice, ripple is flawed because their 'entire network' is in fact 5 trusted UNL nodes owned by ripple labs, which is hardly decentralised, or trustless.
My opinions do not represent those of metaexchange unless explicitly stated.
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline merivercap

  • Hero Member
  • *****
  • Posts: 661
    • View Profile
    • BitCash
Which has an advantage though: a synchronous blockchain .. i.e. blocks are generated every x seconds ..
if you could come up with a scheme that requires a pow which is guaranteed to be solved within x seconds you may not be able to tweak that parameter anymore (easily).

Cost of block production is orthogonal to close group consensus. For example, you could imagine a consensus in which block production was deterministic, yet costly: each signer works simultaneously to reach consensus on a given block (like ripple's consensus), competing for transaction fees by bidding non-refundable currency for the block in production. The highest bidder wins the transaction fees along with bids from the other signers.

Makes sense..

On a separate note since you mentioned Ripple and closed consensus groups, DPOS seems to be a protocol that can be used to decentralize the UNL's that Ripple uses for its consensus algorithm.  Ripple seems to be more well-suited for permissioned networks such as for current financial networks so they might not care as much about being centralized, but a combination of DPOS and the Ripple protocol is an intriguing combination.  I still like the Ripple ideas of credit/trustlines/LETs/pathfinding etc... would be nice to possibly incorporate those down the road.
BitCash - http://www.bitcash.org 
Beta: bitCash Wallet / p2p Gateway: (https://m.bitcash.org)
Beta: bitCash Trade (https://trade.bitcash.org)

Offline merivercap

  • Hero Member
  • *****
  • Posts: 661
    • View Profile
    • BitCash
With tapos in dpos 2 most long range attacks are not viable.   Regardless of how much time or money you have it requires the vast majority (99%) of witnesses to collude to produce an alternative history.   

Dpos is not subject to most pos attacks


Sent from my iPhone using Tapatalk

Thanks.  Can you explain tapos and the idea that 99% of witnesses need to collude in a bit more detail?
BitCash - http://www.bitcash.org 
Beta: bitCash Wallet / p2p Gateway: (https://m.bitcash.org)
Beta: bitCash Trade (https://trade.bitcash.org)

Offline merivercap

  • Hero Member
  • *****
  • Posts: 661
    • View Profile
    • BitCash
DPOS is different from DPOS in Bitshares 2.0...

Keeping this in mind here is a wiki links about DPOS (1.0):
http://wiki.bitshares.org/index.php/DPOS

This describes DPOS 2.0
https://bitshares.org/technology/delegated-proof-of-stake-consensus/

I once started a discussion (tried to be as neutral as possible) on the nxt forum https://nxtforum.org/general-discussion/nxt-pos-vs-bitshares-dpos/?PHPSESSID=c1grk3bhdfn1u49f8qarouhvh3

Thanks Delulo.  Yeah I think your links are good and covers a lot of the high level concepts.  I read the second DPOS 2.0 link before and it actually does seem to generally address the 'double spend'...and the 'block reorganization' section seems to address history revision, pre-programmed long range attacks and grinding... It would be great to elaborate more on this on a technical level.  This old video is good too: https://youtu.be/5m0_jnX5Sy0?list=UU6f8o_H_OgfSLJ2w-bOvyew

There is no whitepaper currently but I think we definitely need one for BitShares to ever be taken seriously.

Yes it seems pretty standard these days to formalize ideas in a white paper for the cryptocommunity.  It would be great to have a white paper eventually.  Satoshi's Bitcoin whitepaper is only 8 pages and has the title Bitcoin: A Peer-to-Peer Electronic Cash System.  That's a fantastic model to use.  I still remember how excited I got when I first read it.  It's really succinct.  What about something like: Bitshares: A Decentralized Autonomous Financial Platform

Also the Bitcoin white paper has the following sections:
1. Introduction
2.Transactions
3.Timestamp Server
4. Proof-of-Work
5. Network
6. Incentive
7. Reclaiming Disk Space
8. Simple Payment Verification
9. Combining & Splitting Value
10. Privacy
11. Calculations
12. Conclusion

Maybe have something similar to this as an outline? 
 
BitCash - http://www.bitcash.org 
Beta: bitCash Wallet / p2p Gateway: (https://m.bitcash.org)
Beta: bitCash Trade (https://trade.bitcash.org)

Offline Method-X

  • Hero Member
  • *****
  • Posts: 1131
  • VIRAL
    • View Profile
    • Learn to code
  • BitShares: methodx
There is no whitepaper currently but I think we definitely need one for BitShares to ever be taken seriously.

 +5% +5% +5%

Offline vikram

There is no whitepaper currently but I think we definitely need one for BitShares to ever be taken seriously.

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
Dpos is not subject to most pos attacks
It would be nice to have a whitepaper that "proof" this claim .. will we see one eventually?

Offline sittingduck

  • Sr. Member
  • ****
  • Posts: 246
    • View Profile
With tapos in dpos 2 most long range attacks are not viable.   Regardless of how much time or money you have it requires the vast majority (99%) of witnesses to collude to produce an alternative history.   

Dpos is not subject to most pos attacks


Sent from my iPhone using Tapatalk

Offline monsterer

Which has an advantage though: a synchronous blockchain .. i.e. blocks are generated every x seconds ..
if you could come up with a scheme that requires a pow which is guaranteed to be solved within x seconds you may not be able to tweak that parameter anymore (easily).

Cost of block production is orthogonal to close group consensus. For example, you could imagine a consensus in which block production was deterministic, yet costly: each signer works simultaneously to reach consensus on a given block (like ripple's consensus), competing for transaction fees by bidding non-refundable currency for the block in production. The highest bidder wins the transaction fees along with bids from the other signers.
My opinions do not represent those of metaexchange unless explicitly stated.
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
... all these attacks come from: there is no ongoing cost to producing a block.
Which has an advantage though: a synchronous blockchain .. i.e. blocks are generated every x seconds ..
if you could come up with a scheme that requires a pow which is guaranteed to be solved within x seconds you may not be able to tweak that parameter anymore (easily).

For me BitShares trades trust-less-ness against performance/speed. But keep in mind that even though POW (as implemented in bitcoin ...) started as a fair decentralized and trust-less system, we are nowadays far from that goal .. thanks to pooled mining ..

Offline santaclause102

  • Hero Member
  • *****
  • Posts: 2486
    • View Profile
DPOS is different from DPOS in Bitshares 2.0...

Keeping this in mind here is a wiki links about DPOS (1.0):
http://wiki.bitshares.org/index.php/DPOS

This describes DPOS 2.0
https://bitshares.org/technology/delegated-proof-of-stake-consensus/

I once started a discussion (tried to be as neutral as possible) on the nxt forum https://nxtforum.org/general-discussion/nxt-pos-vs-bitshares-dpos/?PHPSESSID=c1grk3bhdfn1u49f8qarouhvh3

Offline monsterer

I think all the common attacks against POS apply to DPOS in the same way, the only major difference is that DPOS uses an elected close group consensus.

All POS systems suffer from the same fundamental problem, which is where all these attacks come from: there is no ongoing cost to producing a block.

This is a good discussion to have, though - I'd love to hear more from the horses mouth, so to speak :)
« Last Edit: July 02, 2015, 08:41:01 am by monsterer »
My opinions do not represent those of metaexchange unless explicitly stated.
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads