BitShares Forum
Main => General Discussion => Topic started by: merivercap on July 02, 2015, 07:19:28 am
-
What's the best resource to explain DPOS? I skimmed through the Neucoin whitepaper and they addressed four kinds of attacks:
1) Double spend
2) History revision using old private keys
3) Grinding attack
4) Pre-programmed long range attack
Also mentioned is the 'nothing at stack argument'... It seems DPOS is different and more deterministic because delegates or 'witnesses' are voted in and that's different from most POS systems that are forked from Bitcoin/Peercoin. Can someone explain the differences between POS and DPOS and address the common arguments against POS? Will there be a whitepaper for DPOS? I think it's important to have a resource to point to so we can bring over some open-minded Bitcoin developers to our ecosystem. Not everyone in the Bitcoin community is a Bitcoin maximalist. It's important to increase DPOS mind share and help Bitcoin influencers understand DPOS. Just like many people & developers first dismissed Bitcoin and eventually came around, I think the same thing will happen with POS/DPOS and Bitshares so it's just a matter of finding powerful ways of explaining these concepts at both a high level and at a technical level. Bytemaster?
-
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 :)
-
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
-
... 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 ..
-
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.
-
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
-
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?
-
There is no whitepaper currently but I think we definitely need one for BitShares to ever be taken seriously.
-
There is no whitepaper currently but I think we definitely need one for BitShares to ever be taken seriously.
+5% +5% +5%
-
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?
-
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?
-
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.
-
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.
-
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 (https://bitsharestalk.org/index.php/topic,13872.0.html)). 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 (https://en.wikipedia.org/wiki/EdDSA) which is a variant of Schnorr signature based on Twisted Edwards curve. The NaCl library (https://en.wikipedia.org/wiki/NaCl_(software)) seems to be a good implementation of this digital signature scheme for regular signatures, but it would need to be modified (see this paper (http://cacr.uwaterloo.ca/techreports/2001/corr2001-13.ps) 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 (http://webcache.googleusercontent.com/search?q=cache:HZ_XtDG2b4QJ:https://ripple.com/uncategorized/curves-with-a-twist/) benefits (https://www.mail-archive.com/cypherpunks@cpunks.org/msg02419.html) to using EdDSA as well.
-
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?
-
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.