
Tendermint – The completely decentralized consensus engine - strzalek
http://tendermint.com/
======
teraflop
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.

~~~
teraflop
One more question/critique:

Section 6.5 purports to give a game-theoretic justification for why a node
should include as many valid signatures from its peers when proposing a block,
for fear of retaliation. But nothing stops me from dividing my voting share
among, say, a thousand nodes which appear to be unrelated.

If one of those nodes decides to "defect" (steal a larger-than-intended share
of fees by excluding some signatures) then the expected time before it is
selected again can be made arbitrarily large, by making the node's voting
share arbitrarily small. If that expected time is significantly larger than
the unbonding period, then there's no way to retaliate, is there? It can just
unbond and then transfer its coins to a "new" node.

EDIT: I originally typo'd "arbitrarily large" instead of "arbitrarily small"
above, but hopefully the meaning was clear.

~~~
zack-bitcoin
If the blockmaker excludes signatures, then a larger portion of the fees get
burned, and the blockmaker gets a smaller reward.

------
jaekwon
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!

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

------
wwsculley
Is this another fork of Ripple?

[https://wiki.ripple.com/Forks](https://wiki.ripple.com/Forks)

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

------
kushti
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
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
Interesting. What "hyperledger" means though?

My mail is kushtech [at] yahoo [dot] com.

------
peterwwillis
_" 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
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
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
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
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.

------
jerguismi
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
_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=30...](https://blockchain.info/charts/n-orphaned-
blocks?timespan=30days) Orphaning requires Bitcoin software to include complex
chain reorganization code; a blockchain where orphans are very rare could omit
such code.

------
jsherer
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
Only coins owned by attempted cheaters get destroyed.

~~~
jcoffland
What about accidental cheaters?

~~~
wmf
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
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
Why, faulty software could make it easy.

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

~~~
zack-bitcoin
I agree with you that the random number generator in tendermint isn't good
enough. I am going to add one I have put in a different cryptocurrency before.
Each validator gives the hash of a secret, and later gives their secret. All
the secrets are XORed to find the random seed.

Tendermint consensus is based off the solution to byzantine generals for
partial synchronicity explained in this paper:
[http://groups.csail.mit.edu/tds/papers/Lynch/jacm88.pdf](http://groups.csail.mit.edu/tds/papers/Lynch/jacm88.pdf)

~~~
lappa
>I agree with you that the random number generator in tendermint isn't good
enough. I am going to add one I have put in a different cryptocurrency before.
Each validator gives the hash of a secret, and later gives their secret. All
the secrets are XORed to find the random seed.

Tendermint doesn't have a random number generator at all. You cannot have
consensus on random numbers, or else _they wouldn 't be random_. It is a
fundamental problem that you are determining the next blocks winner based on
numbers that can be influenced by previous winners.

~~~
zack-bitcoin
2 examples of multiparty games of choosing random numbers: 1) You and I each
write either "1" or "0" onto a piece of paper, and simultaneously reveal to
each other.

If the sum is even, I win. If the sum is odd, you win.

This simple 2-person game randomly generates 1 bit. It can be extended to
arbitrary numbers of people by replacing addition with XOR.

2) N people each vote either "0" or "1". They reveal votes simultaneous. The
minority participants are rewarded. The median of the votes is the next random
bit.

I prefer (1) over (2).

~~~
lappa
Yeah, these work great out of consensus systems. Please consider that you're
working on a consensus system though.

"Simultaneous" has no meaning. There are no means of instant communication,
there is latency. There also is no _proof_ of time without a consensus system.

So what is the proof that I committed my 0 or 1 value before they revealed?
Well you could trust a central authority to maintain that timestamping, or you
could even use Bitcoin for your timestamping. In fact, your PoS system could
probably work if it piggy backed on Bitcoin completely.

If that's too abstract for you, consider that I say I'm ready to commit,
everyone sends me their commits, I construct a block with all their commits
and a ton of other possible commits and then once I have created a seed that
allows me to win and control the network permenantly.

~~~
zack-bitcoin
After reflecting more on the difficulties of a random number generator on a
consensus system, we decided to use round robin method to choose the next
leader from the validators.

Thank you for the important issues you raised.

------
hurin
_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.

------
curiously
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?

