Comment by jaekwon | Hacker News Reader

Comment by jaekwon | Hacker News Reader

Parent Full thread

> Promoting address reuse isn't a good idea.

Depends on the application and the purpose of the blockchain, but the paper isn't explicitly premoting address reuse.

> The assumption that an attacker will tell you he is attacking isn't a very strong one.

Users don't consider blocks committed until they've seen +2/3 of commit signatures, so a fork implies that the victim has evidence of double-signing.

> This security assumption means means that no one can safely join the network and perform an initial sync.

Not sure what you mean -- Maybe an analogy will clarify. Is this a problem that isn't present in Bitcoin? How can a brand new Bitcoin user securely join the network for the first time?

We don't prevent long-range attacks. We assume that they will happen, and the clients should be coded accordingly. For example, if my phone wallet hasn't synced with the network in a while (longer than the unbonding period) then it should warn me the next time I connect, and perhaps ask me to validate a fingerprint of the blockchain via outside channels.

I'm aware of how checkpoints prevent reorgs in other protocols like PeerCoin. That's not how Tendermint works.

> So how do the validators solve the Byzantine Generals Problem?

Perhaps a prerequisite to understanding the Tendermint paper is to first understand the DLS algorithm. It works in a similar but different way. In short it's a round-based 2-phase locking system (prevotes and precommits) with a 3rd phase of signing on top to commit. Without the round-based 2-phase locking system, the protocol would have the problem that you mentioned. But assuming that there are less than 1/3 of byzantine voting power, the validators will come to consensus before they start committing.

> stakegrinding attack with an incredibly small validator/voter %

Stakegrinding is less of an issue in Tendermint because of the deterministic round-robin algo for choosing the proposer, and the fact that the remaining validators need to commit. There are subtle attacks involving the timing-out of validators, but there are also workarounds. These attacks are probably not what you have in mind when you mention stakegrinding.

TLDR: Check out the DLR algorithm first, "Consensus in the Presence of Partial Synchrony (1988)", and then lets keep the discussion. Also check out forum.tendermint.com for some other Q&As.

>Depends on the application and the purpose of the blockchain, but the paper isn't explicitly premoting address reuse.

It defines a system in which addresses are reused.

>Users don't consider blocks committed until they've seen +2/3 of commit signatures, so a fork implies that the victim has evidence of double-signing.

No it doesn't, unless you have a severe misunderstanding of information theory and think everyone know all information everywhere (including attacking forks not published). Your security assumption shouldn't be that the attacker is dumb enough to announce that he's attacking and giving up his money by broadcasting forks.

>Not sure what you mean -- Maybe an analogy will clarify. Is this a problem that isn't present in Bitcoin? How can a brand new Bitcoin user securely join the network for the first time?

It worries me that you can't answer this and you're working on a cryptocurrency. They can achieve consensus because they can be supplied a proof by any of their peers of the transaction-output database. Not allowing reorgs allows a peer to give you a proof that prevents you from achieving consensus.

>For example, if my phone wallet hasn't synced with the network in a while (longer than the unbonding period) then it should warn me the next time I connect, and perhaps ask me to validate a fingerprint of the blockchain via outside channels.

The purpose of a blockchain is to achieve consensus without trusting anyone. If you trust that group, you probably would get along just as well with them managing a centralized database of transactions for you.

>I'm aware of how checkpoints prevent reorgs in other protocols like PeerCoin. That's not how Tendermint works.

I never mentioned checkpoints. The paper basically said it wouldn't allow large reorgs when it said it could prevent long range attacks and ignore the fork.

>Stakegrinding is less of an issue in Tendermint because of the deterministic round-robin algo for choosing the proposer, and the fact that the remaining validators need to commit.

The entire reason stake grinding is possible is because the selection of the next blocks winner is deterministic. The previous winners can change the seed over and over again until they win.

>and the fact that the remaining validators need to commit.

This is not relevant, you can wait until the end or ignore theri validations completely.

>Check out the DLR algorithm first, "Consensus in the Presence of Partial Synchrony (1988)"

This paper is fine, but it assumes 1/3 generals aren't traitors. Your system makes it trivial for a traitor to pretend to be all of the generals.

Sure, the addresses for the validators should be reused. The more it's used the better.

>> Is this a problem that isn't present in Bitcoin? How can a brand new Bitcoin user securely join the network for the first time?

> It worries me that you can't answer this and you're working on a cryptocurrency.

I'm not asking because I don't know the answer. (I know the answer.) I'm asking because your answer will help me clarify the answer for you using the framework and terminology that you're comfortable with. And in this space, each term means different things in different contexts. :)

It's not trivial for a traitor to pretend to be all of the generals. Say there are validators A, B, C, D, and they have equal voting power. Given this configuration, it's impossible for A to be the proposer for 2 blocks in a row unless some of the other validators were absent. It's not just deterministic -- it's round-robin.

>Sure, the addresses for the validators should be reused. The more it's used the better.

That's not at all what I said, but this is besides the point.

>t's not trivial for a traitor to pretend to be all of the generals. Say there are validators A, B, C, D, and they have equal voting power. Given this configuration, it's impossible for A to be the proposer for 2 blocks in a row unless some of the other validators were absent. It's not just deterministic -- it's round-robin.

And you whitepaper allows for block creation with absent validators which makes it trivial because you have total control over the seed determining the next set of valdators. Even if you changed that, it would be trivial because you would only need to have last input into the seed one time to grind and generate a signature such that you are the exclusive validator.

You continue to assert the attack isn't feasible, but you aren't actually paying attention to what the reason I have told you twice now.

"It's not [feasible] for a traitor to pretend to be all the generals <no explanation>, say there are [arbitrary example]. Given this configuration it's infeasible for the attack to be performed <no explanation>. <Repetition of facts that are part of the reason stake grinding works including it's determininsticness>."

If you aren't aware of what stake grinding allows, it is an attack where you calculate the deterministic results of many many signatures (seeds) and finds signatures that result in you winning, allowing you to perform the attack once again.

> control over the seed determining the next set of validators

That notion makes sense in something like PeerCoin or other preexisting PoS designs, but I don't see how that phrase applies to Tendermint. There is no "sampling" -- all validators must sign every block.

I think you underemphasize this point. My Slasher algo ( https://blog.ethereum.org/2014/01/15/slasher-a-punitive-proo... ) from way back then does use sampling; Tendermint does not, and thus gains a whole bunch of robustness properties at some cost to efficiency.

>all validators must sign every block.

Well now you're defining a new system. You can't expect me to explain the security of an undefined system, so I am sticking to the system defined in your paper which states that not all validators need to sign every block.

The whitepaper says that +2/3 of the entire validator set (in voting power) must sign every block. In the ideal scenario (in other words, in the stable state) every validator does sign every block.

Yes, it is pointless for me to argue about an undefined system. If you mean to say that 67% of the validator set must sign every block, then you shouldn't argue with the premise that 100% must sign every block.

It would be interesting to see a more well defined attack from you.

I've explained stake grinding attacks. Your response was redefining the system opening a new attack vector.

> you have total control over the seed determining the next set of valdators

There are many possible algorithms for determining this seed, some of which do solve the stake grinding problem. I personally like the NXT algo; its basic approach in simplified form is:

seed(genesis) = 0

seed(block) = hash(seed(block.parent) + block.proposer.address)

No grind capabilities at all. No matter how many times you try, you will always generate the exact same result. The randomness basically comes from absentee proposers, so the only way to influence the outcome (not proposing) is costly as you sacrifice your reward and all other influence over the block beyond signing / not signing it.

>seed(block) = hash(seed(block.parent) + block.proposer.address) No grind capabilities at all. No matter how many times you try, you will always generate the exact same result. The randomness basically comes from absentee proposers, so the only way to influence the outcome (not proposing) is costly as you sacrifice your reward and all other influence over the block beyond signing / not signing it.

That is trivially grindable. If the seed is your address then you create an additional address such that the next winning address is yours.

> The purpose of a blockchain is to achieve consensus without trusting anyone. If you trust that group, you probably would get along just as well with them managing a centralized database of transactions for you.

See https://blog.ethereum.org/2014/11/25/proof-stake-learned-lov...

Specifically:

> This security assumption, the idea of “getting a block hash from a friend”, may seem unrigorous to many; Bitcoin developers often make the point that if the solution to long-range attacks is some alternative deciding mechanism X, then the security of the blockchain ultimately depends on X, and so the algorithm is in reality no more secure than using X directly – implying that most X, including our social-consensus-driven approach, are insecure.

> However, this logic ignores why consensus algorithms exist in the first place. Consensus is a social process, and human beings are fairly good at engaging in consensus on our own without any help from algorithms; perhaps the best example is the Rai stones, where a tribe in Yap essentially maintained a blockchain recording changes to the ownership of stones (used as a Bitcoin-like zero-intrinsic-value asset) as part of its collective memory. The reason why consensus algorithms are needed is, quite simply, because humans do not have infinite computational power, and prefer to rely on software agents to maintain consensus for us. Software agents are very smart, in the sense that they can maintain consensus on extremely large states with extremely complex rulesets with perfect precision, but they are also very ignorant, in the sense that they have very little social information, and the challenge of consensus algorithms is that of creating an algorithm that requires as little input of social information as possible.

Reply on news.ycombinator.com