jaekwon

Eris Industries is built on Tendermint. Tendermint doesn't use PoW mining, but it can secure a distributed ledger.

https://github.com/tendermint/tendermint/wiki/Byzantine-Cons...

There's a lot of great innovations in Bitcoin. One of the primary reasons why it's exciting, is that it's the first widely deployed BFT ledger. Tendermint uses a different BFT algorithm that doesn't use mining.

Raft and Paxos aren't BFT, btw. As of 2012 there still weren't good implementations of PBFT/BFT middleware. http://cgi.di.uoa.gr/~mema/publications/middleware-2012.pdf . Tendermint is that middleware.

Here's a post on why Tendermint ledgers should be called blockchains:

https://news.ycombinator.com/item?id=10847136

A lot of people say that blockchains aren't blockchains without PoW. It's not surprising that people are saying this... there's been a ton of phony consensus algorithms that purport to not use PoW mining. Tendermint is different.

Hello Ben, thanks for the great tool.

If Bolt supports MVCC using a page log, why does Redis destroy Bolt on random write volume?

Also, I'm seeing wildly different write performance measures. Siddontang on #237 back in 2014 for Ledis suggests 970 Sets per second. This HN article mentions 800 requests per second. Running "bolt bench --count 10000000 --batch-size 10000 --write-mode rnd" gets me 29203 ops per second. Can you shed some light on what random write performance I can expect?

Tendermint founder here. What we're doing with Tendermint is creating a new protocol. See TMSP from the tutorial from Tendermint.

http://tendermint.com/posts/tendermint-socket-protocol/

Yes, we're moving away from "PoS" from the time being, because our clients are more interested in posting collateral external to the blockchain. That said, the original security properties still hold. It's the combination of three things that create security on a non-PoW blockchain, for Tendermint.

* Validators have posted collateral (either on chain or off chain) that is not immediately transferrable, so there is something at stake.

* The BFT consensus algorithm ensures that at least +1/3 of validators must deviate from the protocol to attack the network.

* If there is a fork, then we can find out who had caused the fork. The validator-set is held accountable.

That hasn't changed. What has changed is our client base. We don't want to launch a cryptocurrency ourselves because as US/Canadian residents, that's a legal gray area. On the other hand, fin-tech clients and banks are interested in utilizing this technology for creating a distributed multi-write database. Thus the change in direction.

That said, we're very much interested in support the original PoS design. Other designs as well. For example, we're building out an experimental governance app that allows for arbitrary proposals. Perhaps we can use that to empower users or designated administrator groups to decide on updates to the validator set.

https://github.com/tendermint/governmint

There are many ways to update the validator-set, PoS just being one of them. We will build out our platform to accommodate a wide variety of strategies for managing the validator set. For all strategies, they will make use of our robust BFT consensus algo.

Finally, there are sound technical reasons why a BFT ledger should utilize a hash-chain of blocks (list of txs). It is both a speed optimization (validators only need to sign block hashes, not each tx) as well as a security requirement. To expound on the latter, note that the original PBFT implementation does not provide any guarantees when more than 1/3 are Byzantine (see http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.121...). But the hash-chain ensures fork consistency. So there you have it, a chain of blocks of transactions is fundamentally important for non-PoW ledgers. That's why we use the term "blockchains".

Thanks for the pointers, cockroachlabs. Your posts really help developers building real applications on Golang.

I haven't read the article. For the lazy, what sort of level of pH changes are we talking about? Would if affect me if I go swimming in the ocean?

The inner structs (of which the outer writer struct is composed) cannot access any of the functionality or fields outside of itself. Each inner struct is completely encapsulated, so you can't override an inner struct method and expect the inner struct's behavior to change.

The accessibility of inner struct methods from the outer struct is a syntactic convenience.

Java: https://gist.github.com/jaekwon/8025b9f3a482b3219a21 Go: https://gist.github.com/jaekwon/0f6e5555ab6a592aa4c8

Once you Go, you never go back. ;)

What does that say about the EFF marking this a neutral?

Specifically, the block is an optimization for more transaction throughput in a consensus system. Without blocks, consensus would take longer because every binary decision requires at least a couple rounds of communication amongst every "validator".

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

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.

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

;) Where are you at? We're in the Bay Area.

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.

+1 Yes, you raise a valid point. It's a weakness that must be addressed. There needs to be additional assumptions in the model, e.g. the respective voting powers should be on the same order of magnitude, and the number of validators should only be as large as the throughput (in blocks/s).

More bandwidth && less latency && more CPU helps.

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.

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

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.

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!

Yes, the algorithm allows for skipping absent or Byzantine validators. It doesn't skip the height, it just progresses to the next round. In the end it's about getting more than 2/3 of commit votes.

You can prevote or precommit more than once per height (on different rounds), but a commit for a height must be the last signature for that height.

The sudden mass bonding is a problem for light clients doing a certain type of desirable SPV. We're considering options to mitigate this issue. One such option is to throttle the bonding and unbonding at the protocol level, or to introduce a second class of coin for validating and controlling issuance of it.

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.

But I want to know more about the equations!

What does y^2 = x^3 + ... have to do with an ellipse or the arc length of it?

This is really interesting. One or both of you all should write a blog post on it because I'm eager to learn more.

I love C. Love Go. Love the idea of Rust though I've never tried it, and I just want to know more.

> is incentivized to produce one in which you cannot disable the built-in DRM/security

Why is that? I don't see why this has to be true.

Huh interesting... how does Go do it under the hood?

As long as I have the choice to disable it, I want trusted computing. For example, I want to be able to run a secure cryptocurrency wallet on a portable device. Also would like to be able to introspect the hardware, even if it's costly and potentially destructive.

Well, they do make the hardware over there -- maybe they're pretty comfortable with beta software.

And besides, there was already some Android integration even before Google announced it.

Translated: "The article doesn't explain why, only that it is."

So laowushi, why do you think it is?

Proof of assets.

Proof of liabilities.

Leaks be instadetected.

Yes. That's my point. Most of us live under terrorist regimes. Black people are terrorized by the police. The middle east is terrorized by the US. We're terrorized by Russia.

To isolate a few and to give them the label of "terrorist" for being a bit more terrifying is a form of brainwashing.

Aren't you making a mistake in assuming that those who fall under this neologism are different? Isis for example wants to be a nation, not just terrorize people. Haven't there been religious crusades of terror for that purpose in the past?