Looks like these guys (Tendermint team) actually care about design, testing and scalability in their project compared to Ethereum where people are concentrating on hype rather than product (I am not rude, used Ethereum from the client's perspective) :)<p>It would be interesting to hear from people who actually use (if there are any) Tendermint:
* How easy/hard is it to create bindings to the blockchain from your own backend application (as I can see there is a GRPC option).
* How many nodes you are running?
* What's the use case?
I first tried to use Tendermint a year ago and honestly it was rough. Their codebase had very few comments, including things a go linter would harass you endlessly for like function comments, and the docs were barely existent. The codebase was also not exactly what you would call "idiomatic" go.<p>I checked back in at the Cosmos fundraiser, and then again a few weeks ago and their documentation while still needing work, as well as their code quality is definitely improved. I like their idea and I want the project to succeed, and things like independent third party audits are the way that happens.<p>Kudos to the team for not being afraid to look for the warts, better to get them now then later.
Is the intended purpose of the Tendermint protocol to solve the double spend problem, thus allowing the creation of digital tokens?<p>And, if so, wouldn’t the market value of these tokens be limited to whatever it costs to bring <i>2n</i> dishonest nodes, where <i>n</i> is the current number of nodes in the network (thus reaching 2/3 majority), and hereby allowing you to define the transaction history (and assigning all tokens to yourself and sell them in the open market — which will be profitable if the market value of the tokens exceeds the cost of bringing up the dishonest nodes)?
How does Tendermint consensus compare to Nakamoto consensus? Are 2/3 of the nodes expected to be honest? How is validator membership established/enforced?
So, to summarize, instead of trusting physical hardware owned by different people we are expected to trust that keys, that were used to sign genesis block will never leak?
Great work! I just started using Tendermint to write a cryptocurrency for supporting open source development and have several simple questions. Would appreciate it if you could answer them:<p>1) What's your estimated time to be able to run in production?<p>2) What do you think of using something like PostgreSQL to keep the state?<p>3) Is it a good approach to write cron, for example, to recalculate some values once in awhile and update the state by sending transactions?<p>4) What is the best way to handle random numbers?
Hi guys, I asked this question on Twitter as well. Is there a way to model proof of work vs proof of stake using something like Jepsen/Merkleeyes.<p>I'm looking forward to see some Jepsen style testing of the different blockchain protocols, but doesn't seem to be anything out there that can model these aspects.<p>In building Tendermint, did you figure how to test and validate these aspects of blockchains ?
I'm getting an out of memory error when loading the page.<p>java.lang.OutOfMemoryError: unable to create new native thread<p>Cached version:
<a href="http://webcache.googleusercontent.com/search?q=cache:https://jepsen.io/analyses/tendermint-0-10-2" rel="nofollow">http://webcache.googleusercontent.com/search?q=cache:https:/...</a>
java.lang.OutOfMemoryError: unable to create new native thread
at java.lang.Thread.start0(Native Method)
at java.lang.Thread.start(Thread.java:714)
at java.util.concurrent.ThreadPoolExecutor.addWorker(ThreadPoolExecutor.java:950)
at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:1368)
at java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:134)
at clojure.core$future_call.invokeStatic(core.clj:6687)
at ring.middleware.gzip$compress_body.invokeStatic(gzip.clj:70)
at ring.middleware.gzip$compress_body.invoke(gzip.clj:70)
at clojure.lang.AFn.applyToHelper(AFn.java:154)
at clojure.lang.AFn.applyTo(AFn.java:144)
at clojure.core$apply.invokeStatic(core.clj:648)
at clojure.core$update_in.invokeStatic(core.clj:5950)
at clojure.core$update_in.doInvoke(core.clj:5939)
at clojure.lang.RestFn.invoke(RestFn.java:445)
at ring.middleware.gzip$gzip_response.invokeStatic(gzip.clj:87)
at ring.middleware.gzip$wrap_gzip$fn__12777.invoke(gzip.clj:95)
at aleph.http.server$handle_request$fn__9026$f__5083__auto____9027.invoke(server.clj:156)
at clojure.lang.AFn.run(AFn.java:22)
at io.aleph.dirigiste.Executor$Worker$1.run(Executor.java:62)
at manifold.executor$thread_factory$reify__4975$f__4976.invoke(executor.clj:44)
at clojure.lang.AFn.run(AFn.java:22)
at java.lang.Thread.run(Thread.java:745)
Why did you create your own data store - Merkleeyes.<p>I mean, my question is - could you not have wrapped postgresql jsonb or redis using application logic to give you the same kind of semantics as Merkleeyes, yet not have to reinvent data storage ?<p>Would you not have to resolve all the problems that Redis has had to...Also that commercial infrastructure for Redis (e.g. Elasticache) is widely available.
Tendermint is hiring.<p>We have a hubs in Toronto and Berlin, and we're building one out in the Bay Area.<p>If you have what it takes to design and implement protocol standards for the blockchain/cryptocurrency industry, reach out. We want to hire you!<p>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!<p>We're redefining the definition of money while we build our future's financial infrastructure.<p>email: careers@tendermint.com