Facebook Libra Is Architecturally Unsound

The actual cost of processing payment is far less than 1.5-3% - especially with debit cards (which actually implement most of what you think "is not a thing") but even when dealing with credit cards and the necessity to include some overhead for countering card fraud and chargeback costs and whatnot, the total cost is far lower, below 1%.

How can I know this? Well, how do all these credit cards that offer cashback bonuses in the realm of typically 1-2% make this unbelievable feat of paying you for paying stuff happen? They pay for it out of the 2-3% that they get for the transaction. Let's take 2.5% as a middle ground and deduce 2% cashback, that leaves us with 0.5% from which the actual costs of doing the payment have to be covered - and the profits to be paid to shareholders, of course.

Also, Europe has this nice regulation in place limiting credit and debit card interchange fees to 0.3% for credit and 0.2% for debit cards. This regulation has been in effect for a few years already, and the only thing that disappeared were these 2%-cashback-on-every-payment cards (or similar offerings, like granting airplane miles of about the same value). Debit and credit card issuers seem to be entirely able to operate under these conditions, which means that their actual costs of doing business must be under these fractions of a percent.

Because while the core innovation of blockchain is a trusted database a context without trust, the core benefit of blockchain is reduced transaction costs.

A blockchain is a singleton global computer of program code and data. It turns out this is sufficient to represent capital (money) on that computer.

In practice this results in dramatically reduced transaction costs. For example you can transfer money with an API call.

Another example is that an API can be "implemented with money". The https://uniswap.io/ API allows you to exchange currencies without any API keys or middlemen. But, the Uniswap API only works because there's a large amount of liquidity deposited by 3rd parties into its system, much like an inventory of food in a grocery store that shoppers can then access.

"What's the big deal?", you might say. "Uniswap sounds just like a bank. Who cares?". Well as I understand it Uniswap was built by a dude in a basement over a few months, not a multi-million dollar bank project. And you can integrate your app with Uniswap in an afternoon. If you don't think that's going to change the world then you might consider spending a few dozen hours reading https://weekinethereumnews.com/ and see if your opinion is stable :)

> (my agenda, for transparency: I want to send SOC's in space on tiny RISC-V satellites, and the lowest layers of those should be 100% error-free because there's no going physically there to reboot a working shell, remote is all we have.)

Speaking from a bit of experience at Satellogic as well as folklore, trying to make the lowest levels 100% error-free isn't a good strategy. A better strategy is to make the lowest levels capable of recovering from the errors that will occur most frequently. Radiation is going to flip bits; processors are going to fail and sometimes hang; batteries are going to go low; temperatures are going to exceed specifications. If your system is built on the assumption that the lowest layers are going to be 100% error-free, you won't give sufficient attention to handling those errors when your assumption inevitably turns out to be wrong.

One suggestion: include a remotely-triggerable reset sequence in a hardware state machine. A 4-bit state machine driven by 4-bit symbols will work reliably if your channel error rate is small compared to one error per 16 symbols, and it has a false positive trigger rate of 5.4 × 10⁻²⁰. (This is of course vulnerable to malicious DoS attacks if a malicious party learns the 64-bit reset code, but in practice those have historically been an enormously smaller concern than satellites failing randomly in ways that a reset switch can correct.)

It's worth thinking through the fault tree of that reset mechanism. It needs to use omnidirectional antennas, for example, because otherwise it's dependent on attitude control. It needs to be on all the time, not just when you're passing over ground stations, because otherwise it depends on the clock and whatever kind of navigational system you have. It needs to be unencrypted, because otherwise it depends on your encryption protocol, which typically also involves clocks. It unavoidably depends on some kind of power source, but you can connect it directly to the solar panels and/or batteries, rather than through a switch. You probably want to use logic that can tolerate a fair bit of uncontrolled variation of the power supply voltage, not, say, TTL. But then you need like 4 flip-flops and a couple dozen gates. It can fail, but it's simple enough that you can make it highly reliable, unlike a RISC-V.

So, don't think in terms of making the bottom level 100% reliable. You won't get there. Think in terms of how to prevent inevitable unreliability from snowballing, how to make the satellite resilient against inevitable damage and malfunctions, as well as reducing that bottom-level unreliability to an absolute minimum.

As for blockchains, I think they're a very pragmatic solution to serious problems that are otherwise unsolvable: how can I send money to a friend in Venezuela? How can refugees carry their money safely without it being confiscated by pirates, corrupt police, or immigration authorities? How can people pay for illegal drugs without meeting in person with the vendors? How can we fund Wikileaks so they have the resources to transport Ed Snowden to safety? How can we fund Sci-Hub so that knowledge is available to everyone and not lost? Even international remittances to family members work enormously better with Bitcoin than with Western Union or SWIFT, particularly between countries with some degree of unfriendly relations.

It's a similar approach to that with satellites: we know there are bad actors in the financial system, and we want to engage in transactions with them, without giving them the opportunity to sell our credit card numbers to the Russian Mafia or take all our money. We want to prevent the small amounts of inevitable unreliability from snowballing and destroying the entire civilization. Also, we want to minimize the number of attempted ripoffs, so that our defenses against them can be less costly. It turns out that thieves, unlike cosmic rays, respond to incentives, so by making thefts more difficult to pull off, we can also decrease the number of attempted thefts.

Obviously I don't trust Facebook to design the world financial system, though. They elected Trump.

It is a mis-feature - it is done intentionally, but it is a bad idea. Having to go through the legal system to reverse a fraudulent transaction is a huge hurdle compared to the current state of affairs, and it will significantly impact the use of Libra for internet payments.

The article also incorrectly claims that curve25519-dalek has never had security audits. It's had at least two by reputable cryptography auditing firms (Quarkslab and NCC), the former of which is public (the NCC audit was done at the request of my former employer and is private, but like the Quarkslab audit only found minor issues):

https://blog.quarkslab.com/security-audit-of-dalek-libraries...