coinculture

Not quite - see other comments about needing a trusted local source the first time you sync up. Otherwise, forks are never tolerated. If the keys leak, and there's a new history, it will be ignored by all nodes who have been online.

You're probably right, we could have.

The primary reason to use our own is to support Merkle proofs of the state. For the Jepsen tests, it wasn't really needed, and may have been smarter to just wrap something else. But we didn't really reinvent any data storage, we just used goleveldb.

It means we simply give two different nodes the same signing key and get them to sign conflicting proposals and votes. A more complicated Byzantine fault would take into consideration the structure of the underlying protocol to try to thwart consensus safety in a more intelligent way.

It's not some single centralized trusted source. It's a local trusted source. Like a friend or a shop or a website you make payments on that uses the network and has been keeping up to date. Ideally folks should check multiple sources to ensure they agree.

In the same way folks need to figure out which software to download when they join the Bitcoin network.

That's right. The first time you sync up, you're particularly vulnerable. You need to authenticate first against a trusted source.

I think it's still a big experiment and there's a lot to figure out around the right state machines and the right models for computation in these systems. We hope that Cosmos and Tendermint help that experiment along

Thanks!

1) We're looking to get the Cosmos Hub up before the year is out, and to roll out production support in 2018.

2) Great, if you like. But if you want to support light clients you will need a scheme for producing Merkle proofs. Streaming data out of the app into Postgres to better serve clients, sure. But Postgres within the hot paths of your app? Not sure.

3) Sure. Or you can use BeginBlock or EndBlock messages to have the blockchain automatically run code even without transactions :)

4) We're still working on this. For now you can use an external random number oracle, or the block hash, which is available in the Header passed into BeginBlock. The block hash is currently highly manipulable.

Good points. Tendermint aims to be a general purpose consensus system - how the validators are actually chosen and changed is outside Tendermint's domain.

All Tendermint wants to know is an initial set, and leaves it up to the App to tell it how the validators should change with every block.

You can build PoS at the application level, if you need it. This is what we're doing with https://cosmos.network/. With every block, the application can decide, according to its particular PoS design, how the validators should change.

There's actually no reason you couldn't build a Tendermint app that determines who the next validators are based on PoW they did and submitted as a transaction. Not quite the PoW we're used to, but it shows Tendermint is quite flexible. That said, a 2/3 coalition of the current validator set always has complete control on what goes in the blockchain, and a 1/3 coalition can halt it - we can't bail out of that without a hard fork.

Note PoW is also only safe in a synchronous network, though it hedges this with an economic random lottery. Of course PoW guarantees a thermodynamic immutability that nothing else can.

Tendermint isn't inherently economic, and is safe so long as <1/3 of the validating power is malicious, even in asynchronous networks. That's what Jepsen shows here (well, fails to disprove).

Arguably, Tendermint is most useful as an analog of Paxos/Raft but in a multi-stakeholder, or otherwise more adversarial, setting.

We aim to prove it's also useful for structuring global financial systems and scaling cryptocurrencies :)

Tendermint consensus is more like classic BFT consensus than Nakamoto. It provides deterministic finality/safety with every block, unlike the probabilistic 6-block safety of Nakamoto.

Yes, 2/3 are expected to be honest.

Validator membership is established in the genesis state, shared by all participants, and can be updated in arbitrary ways, as determined by the particular application running above Tendermint.

Tendermint/Cosmos | Software Engineer: Consensus, Networking, Formal Verification | Toronto, Berlin, Bay Area | Full-time

If you have what it takes to design and implement protocol standards for the blockchain/cryptocurrency industry, reach out. We want to hire you!

If you have significant open-source software development experience in distributed systems design, operating systems design, database systems design, or language design, reach out. We want to hire you!

If you have a background in formal verification and proofs, and familiarity with tools like TLA+, Coq, Isabelle, etc., we want to hire you!

We're redefining money while we build our future's financial infrastructure.

email: [email protected] site: https://tendermint.com/careers

Have you considered using Tendermint? We just published the results of a few months of Jepsen testing: https://news.ycombinator.com/item?id=15175984

Thanks! A year ago we were just two guys working on this project on the side without any funding. Now we're a full time team of talented devs swinging in full force. The comments and docs continue to improve, and we're excited that folks like yourself continue to take a look.

If you have more specific issues/comments/suggestions, please open an issue! https://github.com/tendermint/tendermint/issues

Tendermint doesn't use Proof of Work (PoW). PoW is hard to test with Jepsen because it only supports probabilistic safety, which means the chain can constantly reorganize. If I'm not mistaken, Jepsen would consider PoW's routine reorgs as linearizeability failures. That said, Jepsen could potentially be modified to support this better, for instance only considering something accepted if its buried X blocks deep.

Tendermint, in contrast, provides deterministic safety, and serves as a building block for Proof of Stake networks.

It means "arbitrary". Byzantine faults refer to "any arbitrary behaviour by the machine". The term was coined by Leslie Lamport in the early 80s when he defined the Byzantine Generals Problem

Thanks for the compliments! We do really care about quality software design and testing, and we're looking to hire folks that share our values: https://tendermint.com/careers

Lots of people are using Tendermint. The biggest users would be Hyperledger Burrow (https://github.com/hyperledger/burrow) and our own Ethermint (https://github.com/tendermint/ethermint). We're also working on an SDK for building apps in Golang (github.com/cosmos/cosmos-sdk) but it won't be ready for another month or two. There are a variety of apps built by members of the community, and ABCI servers in different languages - you can see a somewhat up-to-date list here: https://tendermint.com/ecosystem