This is a well-written post, although obviously carrying some confirmation bias against the idea of a cryptocurrency.
I'm also obviously biased, but if people are interested in my opinion (and only my own) here it goes.
> Libra’s byzantine tolerance on a permissioned network is an incoherent design.
There are two aspects here that the author seems to forget:
* The next best system, that a consortium of very different companies (think from different countries) would agree to run together is probably a protocol like Certificate Transparency which would be too slow and would have no mechanism to prevent double spending. If you're not doing this, then you're probably using a protocol that doesn't tolerate faults and the first time you have a fault your protocol collapses. There's probably a reason that Venmo cannot talk to Paypal which cannot talk to Square.
* Libra will eventually move to a permissionless setting, which means it has to be designed from scratch to support this evolutionary change. You can agree or not with this, but this is the way it was planned.
> Libra HotStuff BFT is not capable of achieving the throughput necessary for a payment rail.
Two things again:
* The number of people in the world who uses GBP vs the number of people who will use Libra at launch is probably not comparable. This means that Libra will be perfectly fine to carry the load for a number of years.
* Current research has shown that the largest throughput improvements are hidden in layer 2. If you don't know what layer 2 is: basically you do transactions off-chain, with whatever protocol you have, and only sometimes do you confirm the current state on the chain.
> Libra’s Move language is not sound.
I believe the type checking (and other checks) are done by the VM, (but that's not my domain so I might be wrong). Indeed, why would you trust the compiler to do the right thing?
> Libra’s cryptography engineering is unsound.
There are two things in this section that are completely wrong:
* No, dalek is not the "wild west” and is actually written by some of the few people who you could trust to write such a library. Yet, audits are planned. Also: we do actually use formally verified code! We have integrated fiat-crypto (a formally verified library, not a cryptocurrency :D) into dalek in order to use formally verified field operations.
* Neither do we use VRFs, bilinear pairings, and threshold signatures (they are just experimentations at this point) nor are these new tools or techniques. I don't have to say much at this point but I would take the author "It should be assumed this entire crypto stack is vulnerable to a variety of attacks" with a huge grain of salt.
> Libra has no capacity for consumer protection mechanisms.
Of course, it is a financial backbone, not a financial service.
I'm also obviously biased, but if people are interested in my opinion (and only my own) here it goes.
> Libra’s byzantine tolerance on a permissioned network is an incoherent design.
There are two aspects here that the author seems to forget:
* The next best system, that a consortium of very different companies (think from different countries) would agree to run together is probably a protocol like Certificate Transparency which would be too slow and would have no mechanism to prevent double spending. If you're not doing this, then you're probably using a protocol that doesn't tolerate faults and the first time you have a fault your protocol collapses. There's probably a reason that Venmo cannot talk to Paypal which cannot talk to Square.
* Libra will eventually move to a permissionless setting, which means it has to be designed from scratch to support this evolutionary change. You can agree or not with this, but this is the way it was planned.
> Libra HotStuff BFT is not capable of achieving the throughput necessary for a payment rail.
Two things again:
* The number of people in the world who uses GBP vs the number of people who will use Libra at launch is probably not comparable. This means that Libra will be perfectly fine to carry the load for a number of years.
* Current research has shown that the largest throughput improvements are hidden in layer 2. If you don't know what layer 2 is: basically you do transactions off-chain, with whatever protocol you have, and only sometimes do you confirm the current state on the chain.
> Libra’s Move language is not sound.
I believe the type checking (and other checks) are done by the VM, (but that's not my domain so I might be wrong). Indeed, why would you trust the compiler to do the right thing?
> Libra’s cryptography engineering is unsound.
There are two things in this section that are completely wrong:
* No, dalek is not the "wild west” and is actually written by some of the few people who you could trust to write such a library. Yet, audits are planned. Also: we do actually use formally verified code! We have integrated fiat-crypto (a formally verified library, not a cryptocurrency :D) into dalek in order to use formally verified field operations.
* Neither do we use VRFs, bilinear pairings, and threshold signatures (they are just experimentations at this point) nor are these new tools or techniques. I don't have to say much at this point but I would take the author "It should be assumed this entire crypto stack is vulnerable to a variety of attacks" with a huge grain of salt.
> Libra has no capacity for consumer protection mechanisms.
Of course, it is a financial backbone, not a financial service.