9 ms·

Tendermint – The completely decentralized consensus engine

123 points by strzalek 12y ago

fortytw2 12y ago
I have to agree with the whitepaper, "Tendermint is awesome. The future is now." It seems like a marked improvement over proof-of-work style blockchains.
jsherer 12y ago
Can anybody elaborate on the destruction of coins? Sounds dangerous... "If the validator causes the blockchain to fork while its coins are locked in bond, all of its coins are destroyed. This means that as long as you sync your blockchain with the network periodically you never have to trust a central checkpoint."
- wmf 12y ago
  Only coins owned by attempted cheaters get destroyed.
  - jcoffland 12y ago
    What about accidental cheaters?
    - wmf 12y ago
      I don't know how you'd accidentally sign two conflicting forks at the same block height, but it would suck to lose your whole stake due to such a bug.
      - vbuterin 12y ago
        I think something like that would happen about an order of magnitude less often than accidentally reusing k values or publishing your private key to the internet :)
        jcoffland 12y ago
        Why, faulty software could make it easy.
teraflop 12y ago
The obvious question for anything that claims to solve Byzantine consensus is: what about Sybil attacks? If you rely on 2/3 of all nodes to be honest, but you open up the network for anyone to join, what stops me from creating a million fake "nodes" and outvoting everyone else? So far I've only skimmed the white paper, but I didn't see any response to this problem. (If the answer is "good guys can make lots of fake nodes too" then you're creating a computational arms race that will inevitably lead to just as much wasted effort as proof-of-work.) There's also the minor practical issue that every node has to do an amount of computation and network traffic that's linear in the total number of other nodes, meaning the total workload grows quadratically with the size of the network.
- zmanian 12y ago
  Sybil resistance in two forms in Tendermint. 1. You assume the initial distribution of tokens is trusted. If someone presents you a consensus without a history to make you believe that initial distribution isn't full of sybils, distrust. 2. Assuming a large trusted initial distribution, operationally you have to believe that 1/3rd of the validator nodes don't want to double spend/ present an alternate reality to you.
  - teraflop 12y ago
    For point 1, sure: Bitcoin does the same thing, and "blesses" a particular initial block as the starting point of the chain by hard-coding it into the client. No reason Tendermint wouldn't do the same thing. I don't see how your point 2 solves anything, though; it's just failing to acknowledge the problem. Why is it reasonable for me to think that a supermajority of the nodes are honest? If validators are supposed to be computationally cheap to run, compared to bitcoin miners, then what stops an attacker from running lots of them to get a larger voting share?
    - Kalium 12y ago
      In the Bitcoin/cryptocurrency world, there's a rarely-voiced but firmly believed assumption that being annoying and expensive to attack makes you secure. So the response that you are saying doesn't solve anything is what is believed to be the solution. Personally, I agree with you.
jerguismi 12y ago
At least the claims about Bitcoin sound like bullshit "Security difficult to quantify — depends on extrinsic factors" Nope, the security is very easy to quantify in Bitcoin - you know that there is certain amount of processing power behind a single block. As your transaction goes into the blockchain, you can be pretty damn sure that won't be reversed, once enough computing power is behind it. "Blockchain forks often — difficult to build applications upon" Nope, bitcoin blockchain forks very rarely. Where is this claim pulled from?
- wmf 12y ago
  in Bitcoin you know that there is certain amount of processing power behind a single block But how much did that processing cost in BTC? People come up with widely varying estimates. Cost of security matters because ultimately you want to denominate risk in the same currency that you're transacting. Blockchain forks often There are minor forks (usually called orphans) every few days: https://blockchain.info/charts/n-orphaned-blocks?timespan=30days https://blockchain.info/charts/n-orphaned-blocks?timespan=30... Orphaning requires Bitcoin software to include complex chain reorganization code; a blockchain where orphans are very rare could omit such code.
- jaekwon 12y ago
  I have to admit that the "difficult to build applications upon" is not the best selling point to put up there. But I stand by the security being difficult to quantify in Bitcoin because the mining reward (plus fees) is necessarily small in comparison to the transactions that are being moved (e.g. 25 bitcoins today vs potentially millions of bitcoins moved per block). The problem is that with a bit of coordination from the miners, forking is easy and easily profitable.
- vbuterin 12y ago
  > As your transaction goes into the blockchain, you can be pretty damn sure that won't be reversed, once enough computing power is behind it. So, this by itself is not an argument. That amount of computing power was produced once, so you can be pretty damn sure that if the incentives line up it will be produced again just on a different history. I have a few slides detailing the rather scary game theory behind PoW here: http://vitalik.ca/files/stanford_presentation.pdf http://vitalik.ca/files/stanford_presentation.pdf Particularly note the "Low incentive to protect against hacks". If the major Bitcoin mining farms get hacked, raided by men wearing ski masks and black suits, etc in order to double spend, large 51% attacks become possible, and a coordinated global attack could earn >$10-50m via double spends, and even more with shorting at 10x leverage. But from the point of view of each individual mining farm, they only lose at most 10-50 blocks' worth of rewards multiplied by their hashpower - a total private incentive of ~$100,000. In fact, if everyone else gets attacked, it's in your interest to ensure that you get attacked too! Also, the "bribe attack" variants all theoretically cost under $100,000. In fact, the largest countervailing incentive factor against all of those is the idea that each mining farm has a decently sized percentage of mining power and thus captures a substantial portion of the "public-good" incentive of the network not failing. Now, you can argue that Bitcoin has not succumbed to these and works fine in practice, but (i) right now, Bitcoin is still tiny, and (ii) if that's true, then naive proof of stake, with its supposedly fatal nothing-at-stake problems, will also work fine in practice. > Nope, bitcoin blockchain forks very rarely. Where is this claim pulled from? It forks back one block ~1-2% of the time and two blocks ~0.01-0.04% of the time. You can determine this from simple math plus network latency statistics, or check blockchain.info: https://blockchain.info/charts/n-orphaned-blocks?showDataPoints=false&timespan=&show_header=true&daysAverageString=7&scale=0&address= https://blockchain.info/charts/n-orphaned-blocks?showDataPoi... This might not seem like much, but if you are looking at the blockchain as an application platform then users are really not used to the idea of finality suddenly becoming non-final 1% of the time.
peterwwillis 12y ago
"We believe that the future is comprised of many interconnected-but-sovereign blockchains that serve different purposes for a variety of communities." They're building a securities market?
- jaekwon 12y ago
  We're building the groundwork for it, and may tackle the securities market or partner up but for now our focus is on building out the foundation -- proper consensus logic and great block chain tooling.
  - peterwwillis 12y ago
    Securities markets have existed on the internet since 1971, and apparently don't need consensus logic and block chain tooling to work, so I doubt the technical details will be the challenging part. Perhaps consulting with the federal regulatory bodies, or the billion-dollar gorillas in the room, might help ;)
jkot 12y ago
I am bit skeptical to this deposit method. Large stock can easily control perhaps 10% of all coins. I think that might be enough to cause fork. Reward is huge, risk low (declare hack and go bankrupt).
- jaekwon 12y ago
  A fork in general results in evidence of double signing by at least 1/3 of the voting power, so fork attacks (and thus double-spend attacks) are expensive to launch (depending on the market cap and existing owners of the blockchain). After slashing the double signers, the remaining validators can regroup as in a hard-fork and carry on. It would be as if launching a double-spend attack in Bitcoin resulted in the destruction of the attacker's mining equipment (and whatever other fixed cost investments that were spent in setting up the mining equipment). This isn't actually possible with mining because mining power is anonymous. Pubkey identities and traditional quorum-based byzantine consensus allows for this kind of antifragility that Bitcoin cannot have.
kushti 12y ago
I'm a member of ConsensusResearch group https://github.com/ConsensusResearch https://github.com/ConsensusResearch . We made some simulation tools around (Nxt-like) proof-of-stake consensus algo & published some papers around them. One the possible improvements to proof-of-stake we're willing to investigate now is proof-of-stake + proof of-activity hybrid, where proof-of-activity is implemented like noted in PoW+PoA paper http://eprint.iacr.org/2014/452.pdf http://eprint.iacr.org/2014/452.pdf. From my personal point of view TenderMint is also about kinda PoS+PoA hybrid but implemented in another way. Do you Tendermint folks have simulation tools or may be even stricter models around your consensus algo to play with?
- Inthenameofmine 12y ago
  Interesting, at Bitsapphire we've been working on PBFT and economic simulations https://github.com/bitsapphire/hyperledger-simulation https://github.com/bitsapphire/hyperledger-simulation. What's the best way to get in touch? Would love to work together on some things.
  - kushti 12y ago
    Interesting. What "hyperledger" means though? My mail is kushtech [at] yahoo [dot] com.
hurin 12y ago
If the validator causes the blockchain to fork while its coins are locked in bond, all of its coins are destroyed. This means that as long as you sync your blockchain with the network periodically you never have to trust a central checkpoint. This sounds very bogus. I'd like to see some algorithm details. Most likely it's just an excuse for another pyramid scheme.
jaekwon 12y ago
Hi HackerNews! We're using TM consensus to create something more interesting than just a crypto "currency", so the website and github hasn't been updated in a while. But the algorithm is still sound (as far as we know) and we're looking forward to launching soon!
lappa 12y ago
Critique follows >They propose a modification to the Bitcoin protocol such that it can tolerate colluding groups that control up to 1/4 of the mining power – less than the previously assumed bound of 1/2 of Byzantine mining power which requires an honest mining majority that follows the prescribed protocol. Selfish mining is tolerable but unideal. It is a bit misleading to claim that 25% block withholding attacks are as critical as 51% attacks. >Users keep an account in the system, where the user’s account is identified by the user’s public key or address. Promoting address reuse isn't a good idea. >When a validator signs duplicitously, a short evidence transaction can be generated by anyone with the two conflicting commit-vote signatures The assumption that an attacker will tell you he is attacking isn't a very strong one. >A user can avoid long-range attacks by syncing their blockchain periodically within the bounds of the unbonding period. This security assumption means means that no one can safely join the network and perform an initial sync. It isn't explained how they prevent long range attacks, but it can be assumed that they do it through disallowing reorgs. Disallowing reorgs allows another consensus breaking attack. The entire purpose of reorgs is to maintain consensus, so if an attacker can create a blockchain of length bond-period, they can trick you so you don't achieve consensus with the "main" blockchain. Another thing that is worrying about this whole idea is that 2/3 of validators must come to consensus on what block to use. If you choose a block and broadcast your signature, you cannot sign again. So how do the validators solve the Byzantine Generals Problem? How do they determine which block they will sign? They could go with the first block they see, but that leaves you open to sybil attackers running many nodes and sending validators different blocks in order to trick them into splitting their vote. These are the fundamental problems that consensus systems are meant to solve, consensus systems shouldn't have to have a 2nd consensus system to support itself. >There are three types of votes: a prevote, a precommit and a commit It seems the paper is attempting to solve the previously mentioned problem, however the most fundamental explanation for the problem with this is explained by Byzantine Generals Problem. The problem essentially involves you sending a message of "I'm ready to attack" back and forth, but because you cannot know they received the message, you cannot attack. If they reply with a "okay, we got the message" message, they don't know that you received the message, so they don't know whether to attack. Whether there is 1 back and forth, 3 as in a "prevote to attack", a "precommit to attack" and a "commit to attack", or 100 back and forths, you aren't achieving consensus, you're skirting the issue. The next few sections explain the mechanism, but not how it actually solves Byzantine Generals Problem. with additonal assumptions based on things that require consensus including "If there are less than 1/3 in Byzantine voting power and at least one good validator decides on a block B, then no good validator will decide on any block other than B" >Each round has a designated proposer chosen in round-robin fashion such that validators are chosen with frequency in proportion to their voting power If the pseudo-random seed for the next round validators is information that can be decided by "previous" (or not so previous) validators, a validator can choose themselves. With a high number of validators, it may take a few thousand blocks for, say, a 3% stakeholder to randomly be selected for a sufficient number of votes to choose the next seed, but once they have ground[1] their first block and made themselves a majority of validators, they can repeat over and over and control the blockchain. > Say that some good validators locked on block B and round R, and some good validators locked on block B0 at round R0, where R < R0. In this case the proof-of-lock from R0 included in a proposal by a good validator will eventually unlock those validators locked on R allowing the consensus process to continue. This "solution" helps prevent 33% deadlocks, I agree, however now you can seed your stakegrinding attack with an incredibly small validator/voter %. Depending on the parameters of the system, you may only need to become a validator once to control the entire blockchain forever. The system of voters has somewhat obscured it, but stake grinding[1] is still a major problem, in fact, it is probably the simplest and cheapest attack vector on the system defined in this paper. In conclusion, this system has severe sybil problems, consensus problems, centralizations problems (in that one person could control the entire blockchain cheaply), structure problems (address reuse) and usability/security assumption problems (no one can safely sync with the network after the first bonding period is up?). [1]Stake grinding is the process of changing data in a block to create a large number of new seeds (sometimes billions or trillions) until the seed designates you as the "winner", or in this case majority of validators.
wwsculley 12y ago
Is this another fork of Ripple? https://wiki.ripple.com/Forks https://wiki.ripple.com/Forks
- wmf 12y ago
  No, it's a completely different algorithm based on proof of stake.
curiously 12y ago
say you want to create a cryptocurrency but you want miners spending their electricity and computing power on something productive, or some transferrable state which can be consumed by another crowd of people. what would it take and how would you go about building it? This seems like what tendermint is doing?

123 points by strzalek 12y ago

I have to agree with the whitepaper, "Tendermint is awesome. The future is now." It seems like a marked improvement over proof-of-work style blockchains.

jsherer 12y ago

Can anybody elaborate on the destruction of coins? Sounds dangerous... "If the validator causes the blockchain to fork while its coins are locked in bond, all of its coins are destroyed. This means that as long as you sync your blockchain with the network periodically you never have to trust a central checkpoint."

wmf 12y ago
Only coins owned by attempted cheaters get destroyed.
- jcoffland 12y ago
  What about accidental cheaters?
  - wmf 12y ago
    I don't know how you'd accidentally sign two conflicting forks at the same block height, but it would suck to lose your whole stake due to such a bug.
    - vbuterin 12y ago
      I think something like that would happen about an order of magnitude less often than accidentally reusing k values or publishing your private key to the internet :)
      - jcoffland 12y ago
        Why, faulty software could make it easy.

teraflop 12y ago

The obvious question for anything that claims to solve Byzantine consensus is: what about Sybil attacks? If you rely on 2/3 of all nodes to be honest, but you open up the network for anyone to join, what stops me from creating a million fake "nodes" and outvoting everyone else? So far I've only skimmed the white paper, but I didn't see any response to this problem. (If the answer is "good guys can make lots of fake nodes too" then you're creating a computational arms race that will inevitably lead to just as much wasted effort as proof-of-work.) There's also the minor practical issue that every node has to do an amount of computation and network traffic that's linear in the total number of other nodes, meaning the total workload grows quadratically with the size of the network.

zmanian 12y ago
Sybil resistance in two forms in Tendermint. 1. You assume the initial distribution of tokens is trusted. If someone presents you a consensus without a history to make you believe that initial distribution isn't full of sybils, distrust. 2. Assuming a large trusted initial distribution, operationally you have to believe that 1/3rd of the validator nodes don't want to double spend/ present an alternate reality to you.
- teraflop 12y ago
  For point 1, sure: Bitcoin does the same thing, and "blesses" a particular initial block as the starting point of the chain by hard-coding it into the client. No reason Tendermint wouldn't do the same thing. I don't see how your point 2 solves anything, though; it's just failing to acknowledge the problem. Why is it reasonable for me to think that a supermajority of the nodes are honest? If validators are supposed to be computationally cheap to run, compared to bitcoin miners, then what stops an attacker from running lots of them to get a larger voting share?
  - Kalium 12y ago
    In the Bitcoin/cryptocurrency world, there's a rarely-voiced but firmly believed assumption that being annoying and expensive to attack makes you secure. So the response that you are saying doesn't solve anything is what is believed to be the solution. Personally, I agree with you.

jerguismi 12y ago

At least the claims about Bitcoin sound like bullshit "Security difficult to quantify — depends on extrinsic factors" Nope, the security is very easy to quantify in Bitcoin - you know that there is certain amount of processing power behind a single block. As your transaction goes into the blockchain, you can be pretty damn sure that won't be reversed, once enough computing power is behind it. "Blockchain forks often — difficult to build applications upon" Nope, bitcoin blockchain forks very rarely. Where is this claim pulled from?

wmf 12y ago
in Bitcoin you know that there is certain amount of processing power behind a single block But how much did that processing cost in BTC? People come up with widely varying estimates. Cost of security matters because ultimately you want to denominate risk in the same currency that you're transacting. Blockchain forks often There are minor forks (usually called orphans) every few days: https://blockchain.info/charts/n-orphaned-blocks?timespan=30days https://blockchain.info/charts/n-orphaned-blocks?timespan=30... Orphaning requires Bitcoin software to include complex chain reorganization code; a blockchain where orphans are very rare could omit such code.
jaekwon 12y ago
I have to admit that the "difficult to build applications upon" is not the best selling point to put up there. But I stand by the security being difficult to quantify in Bitcoin because the mining reward (plus fees) is necessarily small in comparison to the transactions that are being moved (e.g. 25 bitcoins today vs potentially millions of bitcoins moved per block). The problem is that with a bit of coordination from the miners, forking is easy and easily profitable.
vbuterin 12y ago
> As your transaction goes into the blockchain, you can be pretty damn sure that won't be reversed, once enough computing power is behind it. So, this by itself is not an argument. That amount of computing power was produced once, so you can be pretty damn sure that if the incentives line up it will be produced again just on a different history. I have a few slides detailing the rather scary game theory behind PoW here: http://vitalik.ca/files/stanford_presentation.pdf http://vitalik.ca/files/stanford_presentation.pdf Particularly note the "Low incentive to protect against hacks". If the major Bitcoin mining farms get hacked, raided by men wearing ski masks and black suits, etc in order to double spend, large 51% attacks become possible, and a coordinated global attack could earn >$10-50m via double spends, and even more with shorting at 10x leverage. But from the point of view of each individual mining farm, they only lose at most 10-50 blocks' worth of rewards multiplied by their hashpower - a total private incentive of ~$100,000. In fact, if everyone else gets attacked, it's in your interest to ensure that you get attacked too! Also, the "bribe attack" variants all theoretically cost under $100,000. In fact, the largest countervailing incentive factor against all of those is the idea that each mining farm has a decently sized percentage of mining power and thus captures a substantial portion of the "public-good" incentive of the network not failing. Now, you can argue that Bitcoin has not succumbed to these and works fine in practice, but (i) right now, Bitcoin is still tiny, and (ii) if that's true, then naive proof of stake, with its supposedly fatal nothing-at-stake problems, will also work fine in practice. > Nope, bitcoin blockchain forks very rarely. Where is this claim pulled from? It forks back one block ~1-2% of the time and two blocks ~0.01-0.04% of the time. You can determine this from simple math plus network latency statistics, or check blockchain.info: https://blockchain.info/charts/n-orphaned-blocks?showDataPoints=false&timespan=&show_header=true&daysAverageString=7&scale=0&address= https://blockchain.info/charts/n-orphaned-blocks?showDataPoi... This might not seem like much, but if you are looking at the blockchain as an application platform then users are really not used to the idea of finality suddenly becoming non-final 1% of the time.

peterwwillis 12y ago

"We believe that the future is comprised of many interconnected-but-sovereign blockchains that serve different purposes for a variety of communities." They're building a securities market?

jaekwon 12y ago
We're building the groundwork for it, and may tackle the securities market or partner up but for now our focus is on building out the foundation -- proper consensus logic and great block chain tooling.
- peterwwillis 12y ago
  Securities markets have existed on the internet since 1971, and apparently don't need consensus logic and block chain tooling to work, so I doubt the technical details will be the challenging part. Perhaps consulting with the federal regulatory bodies, or the billion-dollar gorillas in the room, might help ;)

jkot 12y ago

I am bit skeptical to this deposit method. Large stock can easily control perhaps 10% of all coins. I think that might be enough to cause fork. Reward is huge, risk low (declare hack and go bankrupt).

jaekwon 12y ago
A fork in general results in evidence of double signing by at least 1/3 of the voting power, so fork attacks (and thus double-spend attacks) are expensive to launch (depending on the market cap and existing owners of the blockchain). After slashing the double signers, the remaining validators can regroup as in a hard-fork and carry on. It would be as if launching a double-spend attack in Bitcoin resulted in the destruction of the attacker's mining equipment (and whatever other fixed cost investments that were spent in setting up the mining equipment). This isn't actually possible with mining because mining power is anonymous. Pubkey identities and traditional quorum-based byzantine consensus allows for this kind of antifragility that Bitcoin cannot have.

kushti 12y ago

I'm a member of ConsensusResearch group https://github.com/ConsensusResearch https://github.com/ConsensusResearch . We made some simulation tools around (Nxt-like) proof-of-stake consensus algo & published some papers around them. One the possible improvements to proof-of-stake we're willing to investigate now is proof-of-stake + proof of-activity hybrid, where proof-of-activity is implemented like noted in PoW+PoA paper http://eprint.iacr.org/2014/452.pdf http://eprint.iacr.org/2014/452.pdf. From my personal point of view TenderMint is also about kinda PoS+PoA hybrid but implemented in another way. Do you Tendermint folks have simulation tools or may be even stricter models around your consensus algo to play with?

Inthenameofmine 12y ago
Interesting, at Bitsapphire we've been working on PBFT and economic simulations https://github.com/bitsapphire/hyperledger-simulation https://github.com/bitsapphire/hyperledger-simulation. What's the best way to get in touch? Would love to work together on some things.
- kushti 12y ago
  Interesting. What "hyperledger" means though? My mail is kushtech [at] yahoo [dot] com.

hurin 12y ago

If the validator causes the blockchain to fork while its coins are locked in bond, all of its coins are destroyed. This means that as long as you sync your blockchain with the network periodically you never have to trust a central checkpoint. This sounds very bogus. I'd like to see some algorithm details. Most likely it's just an excuse for another pyramid scheme.

jaekwon 12y ago

Hi HackerNews! We're using TM consensus to create something more interesting than just a crypto "currency", so the website and github hasn't been updated in a while. But the algorithm is still sound (as far as we know) and we're looking forward to launching soon!

lappa 12y ago

Critique follows >They propose a modification to the Bitcoin protocol such that it can tolerate colluding groups that control up to 1/4 of the mining power – less than the previously assumed bound of 1/2 of Byzantine mining power which requires an honest mining majority that follows the prescribed protocol. Selfish mining is tolerable but unideal. It is a bit misleading to claim that 25% block withholding attacks are as critical as 51% attacks. >Users keep an account in the system, where the user’s account is identified by the user’s public key or address. Promoting address reuse isn't a good idea. >When a validator signs duplicitously, a short evidence transaction can be generated by anyone with the two conflicting commit-vote signatures The assumption that an attacker will tell you he is attacking isn't a very strong one. >A user can avoid long-range attacks by syncing their blockchain periodically within the bounds of the unbonding period. This security assumption means means that no one can safely join the network and perform an initial sync. It isn't explained how they prevent long range attacks, but it can be assumed that they do it through disallowing reorgs. Disallowing reorgs allows another consensus breaking attack. The entire purpose of reorgs is to maintain consensus, so if an attacker can create a blockchain of length bond-period, they can trick you so you don't achieve consensus with the "main" blockchain. Another thing that is worrying about this whole idea is that 2/3 of validators must come to consensus on what block to use. If you choose a block and broadcast your signature, you cannot sign again. So how do the validators solve the Byzantine Generals Problem? How do they determine which block they will sign? They could go with the first block they see, but that leaves you open to sybil attackers running many nodes and sending validators different blocks in order to trick them into splitting their vote. These are the fundamental problems that consensus systems are meant to solve, consensus systems shouldn't have to have a 2nd consensus system to support itself. >There are three types of votes: a prevote, a precommit and a commit It seems the paper is attempting to solve the previously mentioned problem, however the most fundamental explanation for the problem with this is explained by Byzantine Generals Problem. The problem essentially involves you sending a message of "I'm ready to attack" back and forth, but because you cannot know they received the message, you cannot attack. If they reply with a "okay, we got the message" message, they don't know that you received the message, so they don't know whether to attack. Whether there is 1 back and forth, 3 as in a "prevote to attack", a "precommit to attack" and a "commit to attack", or 100 back and forths, you aren't achieving consensus, you're skirting the issue. The next few sections explain the mechanism, but not how it actually solves Byzantine Generals Problem. with additonal assumptions based on things that require consensus including "If there are less than 1/3 in Byzantine voting power and at least one good validator decides on a block B, then no good validator will decide on any block other than B" >Each round has a designated proposer chosen in round-robin fashion such that validators are chosen with frequency in proportion to their voting power If the pseudo-random seed for the next round validators is information that can be decided by "previous" (or not so previous) validators, a validator can choose themselves. With a high number of validators, it may take a few thousand blocks for, say, a 3% stakeholder to randomly be selected for a sufficient number of votes to choose the next seed, but once they have ground[1] their first block and made themselves a majority of validators, they can repeat over and over and control the blockchain. > Say that some good validators locked on block B and round R, and some good validators locked on block B0 at round R0, where R < R0. In this case the proof-of-lock from R0 included in a proposal by a good validator will eventually unlock those validators locked on R allowing the consensus process to continue. This "solution" helps prevent 33% deadlocks, I agree, however now you can seed your stakegrinding attack with an incredibly small validator/voter %. Depending on the parameters of the system, you may only need to become a validator once to control the entire blockchain forever. The system of voters has somewhat obscured it, but stake grinding[1] is still a major problem, in fact, it is probably the simplest and cheapest attack vector on the system defined in this paper. In conclusion, this system has severe sybil problems, consensus problems, centralizations problems (in that one person could control the entire blockchain cheaply), structure problems (address reuse) and usability/security assumption problems (no one can safely sync with the network after the first bonding period is up?). [1]Stake grinding is the process of changing data in a block to create a large number of new seeds (sometimes billions or trillions) until the seed designates you as the "winner", or in this case majority of validators.

wwsculley 12y ago

Is this another fork of Ripple? https://wiki.ripple.com/Forks https://wiki.ripple.com/Forks

wmf 12y ago
No, it's a completely different algorithm based on proof of stake.

curiously 12y ago

say you want to create a cryptocurrency but you want miners spending their electricity and computing power on something productive, or some transferrable state which can be consumed by another crowd of people. what would it take and how would you go about building it? This seems like what tendermint is doing?