There are likewise some inaccuracies in this post. Both OPs seems to agree on the fact that Libra has no transaction privacy and then pick nits about features not being there at this point in time:
> Libra’s byzantine tolerance on a permissioned network is an incoherent design.
This post's argument rests on their being a unused flag in the configuration file for a feature which is not implemented. The Libra whitepaper indicates that a permissionless design is beyond their ability to implement at this time. There is no reason to believe a proof-of-stake model is what is intended. Even the whitepaper states:
> The challenge is that as of today we do not believe that there is a proven solution that can deliver the scale, stability, and security needed to support billions of people and transactions across the globe through a permissionless network.
> Libra HotStuff BFT is not capable of achieving the throughput necessary for a payment rail
This seems like some actual benchmarks that simulate real system load are needed before a conclusion can be made.
> Libra’s Move language is unsound
It seems like the OP takes a more traditional view of type checkers as a Haskeller programmer. Pushing type-checking to the bytecode level is a very nontraditional approach to compiler design and contradicts the original Libra whitepaper claiming to implement linear types. Libra does not do this provide any linear typechecker or formal verification at this time.
> Libra’s cryptography engineering is unsound
This section is subject to some debate. It seems there are some unpublished audits of the libraries that may lend credibility to the Rust libraries but are unpublished. The original post doesn't claim that they are insecure, just that the more audits and testing the libraries undergo the more trusted they should become trusted (i.e. libsodium).
It also seems that Libra implements a lot of extraneous next-gen crypto that is dead code and not used for any purpose in the core logic.
> Libra has no capacity for consumer protection mechanisms
The section agrees with the OP that this does not exist.
Things like Big-O notation are part of introductory computer science classes and introductory algorithms classes.
BigO notation also applies when an algorithm is distributed and runs over a network. An algorithm that's O(n^2) will always be slower than an algorithm that's O(2n). You don't need to run benchmarks to find that out.
> Libra’s byzantine tolerance on a permissioned network is an incoherent design.
This post's argument rests on their being a unused flag in the configuration file for a feature which is not implemented. The Libra whitepaper indicates that a permissionless design is beyond their ability to implement at this time. There is no reason to believe a proof-of-stake model is what is intended. Even the whitepaper states:
> The challenge is that as of today we do not believe that there is a proven solution that can deliver the scale, stability, and security needed to support billions of people and transactions across the globe through a permissionless network.
> Libra HotStuff BFT is not capable of achieving the throughput necessary for a payment rail
This seems like some actual benchmarks that simulate real system load are needed before a conclusion can be made.
> Libra’s Move language is unsound
It seems like the OP takes a more traditional view of type checkers as a Haskeller programmer. Pushing type-checking to the bytecode level is a very nontraditional approach to compiler design and contradicts the original Libra whitepaper claiming to implement linear types. Libra does not do this provide any linear typechecker or formal verification at this time.
> Libra’s cryptography engineering is unsound
This section is subject to some debate. It seems there are some unpublished audits of the libraries that may lend credibility to the Rust libraries but are unpublished. The original post doesn't claim that they are insecure, just that the more audits and testing the libraries undergo the more trusted they should become trusted (i.e. libsodium).
It also seems that Libra implements a lot of extraneous next-gen crypto that is dead code and not used for any purpose in the core logic.
> Libra has no capacity for consumer protection mechanisms
The section agrees with the OP that this does not exist.