The answer to the question implied in the article -- why does Libra make such unjustified design decisions -- is simple. Some people have become enamored with blockchain despite it having almost no good use cases, and this certainly isn't one. It seems like a classic example of focusing on the technology rather than on the problem.
--
Regardless of the other, far more important sections of this article, I find the section about the programming language misleading. Programming language theory does not study the quality of programming languages or their suitability to certain tasks. It is simply outside the purview of the discipline. PLT does not have any tools whatsoever to determine which language is more or less suitable and it is not interested in that question. The theory studies the properties of formal systems and the internal implications of their design. Much like mathematics can deduce from the Peano axioms that 10 > 5, but it says absolutely nothing about whether 10 is "better" than 5 because the answer to that depends on context (are we talking cookies or tumors?) that is simply outside the purview of mathematics. Similarly, PLT can say whether a certain formal system is sound or not, but it says nothing whatsoever about whether soundness is "good", "bad" or neutral, and certainly not how good or bad it is. Of course, programming language theorists have opinions on the matter, but those opinions are not supported by the theory.
Also, given the other glaring flaws, there is nothing to suggest that a formal definition of the programming language would improve matters in any perceptible way. After all, we do entrust the world's monetary system, and sometimes even our lives, to software written in programming languages that don't have a formal definition. As someone who studies the issue of software correctness, a formal definition of a programming language is certainly of interest to theorists, but it has not been shown to be a particularly worthwhile means of increasing correctness.
If you may spare a minute, I'd like to know your opinion on mission-critical software in dangerous-prone contexts (such as avionics, life support, even just economically for permanently-written "ROM" software, etc). Formal methods seem required in such projects, but your final paragraph seems to imply the formalism isn't key to end quality?
(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.)
Regarding 'love' for blockchain, I think it's the basic proposition of "100% accurate data that cannot be controlled by anyone" that seduces. The 'cost' of that in performance becomes a nagging second concern. It gives people a feeling of safety if no other party, not their bank nor family nor employer nor anyone can alter their data, their transactions (whatever the kind, financial is but one use).
Whether blockchain is the only way to achieve that is another matter, but (afaik?) so far it's the only working implementation of the concept of perfectly secured data. I think that's what drove people nuts. I also think Bitcoin or currency in general is but one use case and a very impractical one in the current financial environment, i.e. Earth circa 2019. I'd wager there are much better avenues to explore, eminently non-financial in nature, such as peer-to-peer 'free' communication, or formal (law, contracts) codification (anything official and 'forever' until 'revoked'). No coin, no market, no whatever but the benefits of a slow but 100% truthful database, for small data (text fits quite well).
> but your final paragraph seems to imply the formalism isn't key to end quality?
That's not what I said. I said that merely creating a verified formal specification of a language is not in itself a good path to increasing correctness, and I wouldn't focus on that as a significant cause for concern given all others. But even when you use formal methods in the development of your software -- and I'm certainly a proponent -- there are many formal methods with widely different guarantees and costs, and some of them don't require a formal specification of the programming language. Moreover, no system can be 100% error free, regardless of verification method used. Systems rely on hardware whose actual behavior can never be "proven" correct, and, at best, only probabilistically matches the spec.
I personally believe that some formal methods can greatly improve correctness, and do so affordably, but the question of which formal methods are worthwhile when and by how much each of them improves correctness is very much an open question.
> it's the only working implementation of the concept of perfectly secured data.
I strongly disagree. There is no such thing as "perfectly secure." Security is defined with respect to certain threats (e.g. a hazmat suit can protect you from poisonous gas but gives you no defense from bullets, whereas a bullet-proof vest is the opposite), and blockchain is rarely the most secure with respect to the most relevant threats in a monetary system.
I think this question is best answered by economists, and I'm certainly not one. But blockchain does seem to interfere with some of the best regulatory defenses against economic disasters.
Blockchain gives the impression that the primary threat it is designed to defend against, is a government deciding (like Germany between world wars) to inflate their currency for whatever reason. So, not surprisingly, in order to defend a currency against being decreased in value by a central authority, it is vulnerable to all of the threats that a central monetary authority might help you with.
Which of these threats you think is the more salient is, of course, a matter on which people may disagree. I personally find the risk of a central monetary authority devaluing my money, to be not one of my top concerns, but I could understand why others might think differently (especially if they were in a different country, that used a different currency).
Right, here in Argentina our currency has lost more than half its value this year, and the US dollar has lost 96% of its value since the end of the gold standard in 1973. I carry a Zimbabwe 100 trillion dollar bill in my wallet to remind people what real hyperinflation is.
I don't think that's the main threat Bitcoin is designed to defend against, though; I think there's a whole spectrum of confiscation threats, ranging from thieves tunneling into bank vaults (I know a woman here who lost her savings that way), to immigration authorities confiscating jewelry, to pirates, to trumped-up "money laundering" charges. And of course if we're mentioning Germany and World Wars, we must not forget the confiscation of Holocaust victims' entire possessions, including jewelry and fillings after the gas chambers. Bitcoin can't make genocide impossible but maybe at least it can make it unprofitable.
> the US dollar has lost 96% of its value since the end of the gold standard in 1973
It is more like 80-85%, not 96%. $1 in 1972 is $6-$6.5 in 2019. A 96% loss of value would mean $1 in 1972 is more like $25 in 2019, which is not the case.
Also to phrase it in context you should probably say "the US dollar has had an average annual inflation rate of 4% per year over the last 5 decades". Also for additional context you should point out that bonds slightly exceeded, and that $1 of stock in 1972 in the US market became ~$104 in 2019.
It depends on which particular data series you use for deflation. There are definitely things for which US$1 in 1972 is more like US$25 in 2019, such as gold and energy. To take one example among many, oil cost US$3 per barrel at the beginning of 1973, and despite the fracking boom in the US, it costs US$63 today, 21× as much. And, as you yourself point out, you need over US$100 today to buy shares of stock that cost US$1 in 1972. (And there are other things which are cheap in 2019 that were unavailable at any price in 1972, and vice versa; and there are borderline cases like videotape recorders and microcontrollers, on one hand; and 1963 Buicks, ivory, old-growth redwood lumber, and quaaludes, on the other.)
I agree that "an average annual inflation rate of 7.1%" (or, using your US$6 number, 3.9%) sounds much milder than "lost 96% of its value since 1973" (or 83%). Where I differ is on whether the milder presentation or the more dramatic presentation is more informative. I think that, except to financial traders, "3.9%" or even "7.1%" is a misleadingly insignificant number.
Consider that throughout the 1600s, 1700s, and 1800s, there were families that lived on the interest income from government bonds, both in the US and in England. Even throughout the 20th century, people would buy "savings bonds" as presents for children or as a means to save up for college or retirement; the bonds would reach maturity decades in the future, providing a healthy reward for the prudent and patriotic purchase. Since the end of Bretton Woods, that 3.9% or 7.1% has made nonsense of such ideas. Despite what you might think, this hasn't eliminated plutocracy or increased social mobility — rather the opposite has happened in the post-Bretton-Woods years, in fact. I think it's hard to obtain the historical perspective necessary to appreciate the importance of this radical experiment. But it is, I assure you, a worthwhile effort. I recommend it.
Perhaps inflationary monetary policy is a necessary instrument for avoiding financial panics; it's a plausible idea. But the evidence against it — particularly the 1970s stagflation in the US — suggests that, though plausible, it isn't such a clearly open-and-shut conclusion that we should deny everyone access to alternative, non-inflationary currencies. Moreover, in most scenarios, attempting to institute such a policy would only deny such access to everyone but the well-connected and influential.
Certain things outpace inflation, yes. Certain things are drastically cheaper. That's why we use an inflation measure that's sort of an aggregate, not pinned to one or two commodities. You don't spend 100% of your money on oil and gold.
Oil now is 3x more expensive even after a more average inflation of ~4% compared to the bottom of 1973 (though in the mid 90s it wasn't so bad).
Energy as a whole though, is not 3x more expensive. Petrol is only about a third of energy consumption. Consumer electricity prices for instance are relatively constant from the 70s through now. Slight increase in the 80s, slight decrease in the 00s, but within say <5% of prices.
I'm not making assertions about the change to bond markets (which I agree are historically fascinating, and will continue to be so in the future too).
There isn't an objectively correct basket of goods that is obviously the correct deflator to use, which seems to be a significant underlying assumption of your line of reasoning. The debate about which ones are the important ones to include in statistics like the US BLS CPI is a politically charged debate resolved in part by political means, not purely by the disinterested pursuit of truth. The CPI in particular eminently susceptible to drift over the years, since the goods in it change over time according to the Consumer Expenditure Survey — in 1973 people in the US were buying washing machines that are still in use today and Saran Wrap made of actual Saran, for example, and today they're buying washing machines that wear out in five years and Saran-free Saran Wrap. And of course it measures the prices of only mass-market consumer goods, not services (such as the essentials, child care and elder care) or custom or unique goods such as hand-tailored suits or buildings — a political decision, not an objective one.
If we want to be skeptical of carefully tailored metrics with thousands of parameters produced by political appointees, what standard should we use to measure the value of the dollar? Precious metals have been the standard against which currencies have been measured for several thousand years — the gold standard for measuring the value of currencies, you could say — and by that standard the dollar's loss of value since 1973 is about a factor of 25. This compares to about a factor of 2 over the previous 40 years, since 1933, and a factor of about 1.1 over the previous 140 or so years since the dollar was introduced.
I suspect that if you compare other goods which are, like gold and crude oil, verifiably produced to the same standard of quality in 1973 and today, you will find a similar factor of 16–32 in their dollar prices. I'm thinking of the most common grades of steel, aluminum, brass, portland cement, window glass, industrial electric motors, and so on. There will definitely be some exceptions — ±1% resistors are much cheaper now, to the point where you can't even get the ±20% kind that were the norm in 1973, and I imagine the same is true of specialty steels, synthetic sapphire, and a number of other things that were barely feasible at the time; and presumably photographic film has become more expensive, as it has ceased to be a mass-market item. If you're right about the cost of electricity "staying the same" — by which I assume you mean that, in the US, it increases in line with the BLS CPI? — this suggests that my hypothesis won't be true of coal. Do you have any other ideas?
Let's take anthracite, because it's the purest grade of coal, so it should be less vulnerable to variation in value from drift in grading standards. https://www.eia.gov/totalenergy/data/annual/showtext.php?t=p... suggests that nominal anthracite coal prices have risen from US$13.65 per short ton in 1973 to US$70.99 in 2011; https://www.eia.gov/energyexplained/coal/prices-and-outlook.... says that in 2017 they were US$93.17 per short ton, FOB the mine. That's a factor of 6.8, which is a lot closer to 6 than to 25.
> If you're right about the cost of electricity "staying the same" — by which I assume you mean that, in the US, it increases in line with the BLS CPI?
Yes I meant real price, not nominal.
US electricity is somewhere around a third from coal.
I would be interested in a study showing a 15-30x increase in similar-quality construction materials.
The fixation on gold makes no sense to me. It's just a commodity, not a super useful one either. Gold's price floats wildly based on people's fears. It's not like everything became 4x more expensive between 2000 and 2015.
We were debating precisely which data series is best for computing the "real price" from the nominal prices. But it seems you take me for a fool and beg the question.
I see your point, but I think there are plenty of examples of people losing their Bitcoins through analogous nefarious activities (e.g. MtGox). For an expert in cybersecurity perhaps Bitcoin is safer, but for the average non-technical person (in the U.S.) it is probably _more_ likely to get your money taken by a thief than if you had it in fiat currency in a bank, though of course either one is possible.
Again, this could vary depending upon your nation's government and crime situation.
I think it's true that "for the average non-technical person (in the U.S.) it is probably more likely to get your money taken by a thief than if you had it in fiat currency in a bank." But I think you're locating the problem in the wrong part of the conjunction: the reason fiat currency in a US bank is more secure is because US banks are fairly secure, not because the fiat currency is secure.
It seems like some sort of confusion to blame the Mt. Gox heist on Bitcoin. Mt. Gox's depositors gave their Bitcoins to Mt. Gox; Mt. Gox didn't give them back and claims that an unknown party absconded with them. If you lent your car to a random French PHP programmer in Japan and he came back without the car, you wouldn't blame that on cars in general being an "unsafe" investment.
If the Mt. Gox depositors had kept their Bitcoins in a paper wallet in a Bank of America safe deposit box rather than in Mt. Gox, they'd still have their money. (In fact they'd have enormously more money, but that's sort of random; it demonstrates the fickleness of markets rather than any kind of fundamental security of Bitcoin.) Conversely, the investors and banks who invested or lent dollars and yen to Mt. Gox lost as much or more as the Bitcoin depositors.
Probably a BofA Bitcoin account would be better, but that's a matter of convincing BofA to offer Bitcoin or similarly secure currencies, instead of or in addition to dollar-denominated accounts. And that's where Libra comes from.
> But I think you're locating the problem in the wrong part of the conjunction: the reason fiat currency in a US bank is more secure is because US banks are fairly secure, not because the fiat currency is secure.
Fiat currency is secure in US banks because there is vast institutional protection for banks such as FDIC insurance and extremely strict laws against bank theft, the Federal Reserve, and so on. There are no such institutional protections for Bitcoin and there never really can be, by design.
> If you lent your car to a random French PHP programmer in Japan and he came back without the car, you wouldn't blame that on cars in general being an "unsafe" investment.
Sure I would - if lending a car to strangers was an effective necessity to use one in the same way using an exchange is an effective necessity to use Bitcoin, and there were "alternative cars" (aka fiat currency) that required no such lending to strangers.
Leaving your Bitcoin in an exchange is not now and has never been an "effective necessity to use" Bitcoin. However, for fiat-currency transactions, it is an effective necessity to leave your fiat currency in an "exchange" called a bank, if you want instant electronic transactions. Unlike with the banking system, you can engage in instant electronic transactions with Bitcoin you hold in your own wallet — although some counterparties may prefer to wait for a number of confirmations.
> There are no such institutional protections for Bitcoin and there never really can be, by design.
This is nonsense. Bitcoin's design permits all the same institutional protections available for dollar bills or precious-metal coins, and additionally permits others that are enormously more secure than the mere incentive structures we must rely on in the case of dollar-based institutions. For example, a bank holding gold or dollars cannot produce a mathematical proof of its reserves as a Bitcoin bank can, and there is no dollar equivalent of multisig wallets.
So, in both cases, you are incorrectly imputing advantages to fiat currencies that in reality belong to Bitcoin in this comparison.
> However, for fiat-currency transactions, it is an effective necessity to leave your fiat currency in an "exchange" called a bank, if you want instant electronic transactions
Yes. However there is also cash which allows for instant anonymous transactions in the physical world which is sufficiently widely accepted to be used to the exclusion of banks, if you so choose.
> you can engage in instant electronic transactions with Bitcoin you hold in your own wallet
Isn't the fact that transactions are not instant widely perceived in the Bitcoin community as one of, if not the, greatest barrier to adoption? If not, why all the investment in the Lightning network?
> Bitcoin's design permits all the same institutional protections available for dollar bills or precious-metal coins, and additionally permits others that are enormously more secure than the mere incentive structures we must rely on in the case of dollar-based institutions. For example, a bank holding gold or dollars cannot produce a mathematical proof of its reserves as a Bitcoin bank can, and there is no dollar equivalent of multisig wallets.
You're saying these words but not addressing the substance of what I said. There is no FDIC equivalent for Bitcoin - unless there's an exchange that guarantees replacement of lost/stolen Bitcoins? Replacing Bitcoin seems a difficult proposition when fiat currency can just be created out of thin air but Bitcoin cannot - once it's lost, it's lost, and can only be replaced in a zero-sum way.
> There is no FDIC equivalent for Bitcoin - unless there's an exchange that guarantees replacement of lost/stolen Bitcoins? Replacing Bitcoin seems a difficult proposition when fiat currency can just be created out of thin air but Bitcoin cannot - once it's lost, it's lost, and can only be replaced in a zero-sum way.
I didn't realize you were laboring under the misconception that the FDIC has the authority to mint money, like a central bank. That's why I didn't address it. Now I can. It doesn't. The FDIC is funded by premiums paid by its member institutions, not by creating currency out of thin air; an insurance scheme for Bitcoin depositors in a bank that provided fractional-reserve Bitcoin accounts could be funded in the same way. It could even be provided by the FDIC, which already provides deposit insurance for deposits denominated in foreign currencies.
> Isn't the fact that transactions are not instant widely perceived in the Bitcoin community as one of, if not the, greatest barrier to adoption?
Bitcoin transactions are instant; they reach everywhere in the mempool in a matter of seconds. It's just that until they're a few blocks deep in the blockchain, they might be reversed, like bank transactions can be for several months. This usually takes half an hour or so, and that's a hassle for some kinds of transactions. However, I think bigger barriers to adoption include the network effect of existing currencies, a sketchy reputation, and the fact that Bitcoin exchanges are now illegal in China.
> there is also cash which allows for instant anonymous transactions in the physical world which is sufficiently widely accepted to be used to the exclusion of banks, if you so choose
Cash limits you to transacting with people you can meet in person, which condemns you to poverty unless you are very lucky indeed.
> And Bitcoin lost over 90% of its value in just under 2 years.
When do you mean? Right now Bitcoin is US$9400, which is almost exactly half of its all-time high value of US$19891 (in 2017). There are several times it has lost more than half of its value, but I don't remember a time when it has lost 90% of its value.
The reason the dollar inflates and never deflates is that it's designed to inflate. On purpose. The underlying Keynesian monetary theory is a radical experiment in stimulating economic activity by maintaining the proper level of unemployment — when unemployment is "too low", central banks raise interest rates (in effect, printing less money), while dropping them when unemployment is "too high". Of course, deliberate inflation of coins by governments has a much longer history than Keynesian monetary theory or fiat currencies — not only did Song China experience it when it introduced paper "representative money", but it's also a well-attested phenomenon in Roman commodity money and later coinages (there known as "debasement", in a technical sense different from its metaphorical use in literary English to describe degradation.) But Keynesian monetary theory, which might be correct, provides a theoretical justification for believing that inflation is good under some circumstances and bad under others, and since 1973 we are all, for better or worse, participating in a radical large-scale experiment to test this hypothesis.
Bitcoin is, in significant part, a dissident response from a group of eccentric intellectuals looking for a way to opt out of that radical experiment. Consequently it is designed to make inflation (of Bitcoin) infeasibly difficult — the existing Bitcoin supply increases asymptotically toward a fixed quantity, known in advance. So, although Bitcoin's value will fluctuate, sometimes wildly, it doesn't have the secular inflation trend designed into the dollar's governance mechanism.
> we are all, for better or worse, participating in a radical large-scale experiment to test this hypothesis.
Well if you have a suitably sound and accurate economic model that you’ve been secreting away, let us know and save us the time.
Additionally, it’s not like it’s been exclusively Keynesian economics since the 70’s: there’s been a huge amount of neoliberal economics going around-do you not remember the popularity of austerity measures during the 2008 GFC?
To me, bitcoin and co’s dogged insistence on the evils of inflation feels more like someone along the way had some personal issue with inflation alone and designed something to counteract it, plausibly at the expense of numerous other economic factors.
> When do you mean? Right now Bitcoin is US$9400, which is almost exactly half of its all-time high value of US$19891 (in 2017). There are several times it has lost more than half of its value, but I don't remember a time when it has lost 90% of its value.
Looks like I overstated it slightly. It lost 85% of its value between its all time high December 17th 2017 ($19,891) and December 16th 2018 ($3,159).
The rest of your response, in my opinion, is immaterial. I can't imagine a soul who'd prefer their money to "fluctuate wildly"—to the tune of -85% in a year—vs slowly losing 1-3% per year. Especially when there are very accessible financial instruments (e.g., TIPS) to avoid even that.
Anyone who invests in a stock is taking a significant risk of losing 100% of their investment, a risk on the order of 5% per year. Anyone who invests in gold is used to seeing it fluctuate by a factor of 2 or 3 most years. Yet not only are these popular investments — they're better investments than dollars are over all but the shortest time periods. Anyone who invested a large amount of money in stocks or gold in 1973 would be rich today, unless they were very unlucky at picking stocks. Anyone who invested a large amount of money in a bag of dollar bills in 1973 would be poor today.
In short, if any soul you could imagine had won the lottery in 1973, they'd be poor again by now because of not knowing how to manage their money, incorrectly believing that a currency is not a kind of investment.
You're moving the goalposts. Are we comparing BTC to currency or investments?
People invest in things, generally understanding the risk. Risk is not all equal. BTC is far riskier (more volatile) than virtually all publicly traded stocks or commodities. See again the very recent 85% drop in 1 year.
And let's be clear: BTC is not comparable to a stock. Company stock is valuable because it gives you ownership (and therefore a stake in) the company's profits. Gold is a much more reasonable comparison, but even that has real practical value (e.g., use in electronics, jewelry, dental work, etc.) And funny enough, Gold is worth less today than it was in 1979. So... it's not a great investment. It's just volatile, and "investment" in it is basically a 0-sum game. Just like Bitcoin.
In 1979 the price range of gold was $226 to $512 per troy ounce, a slightly higher level of volatility than the Bitcoin level you describe with a bit of exaggeration as "far riskier than virtually all…commodities." The gold price today is $1485 per troy ounce.
I'd like to caution the people who have downvoted your other comment that there is a plausible reading that is sufficiently charitable to make your new comment not actually false. Namely, although if you measure it in dollars, it's "worth" 3 to 6 times more, even over the timespan you cherry-picked, the dollar has lost more than a factor of 6 since 1979, so gold really is worth less today than it was then. The attraction of gold — just as with Bitcoin — is precisely that it doesn't have a secular decline in value built in, so it's a good vehicle for preserving wealth through periods of instability, even though it doesn't generate a return in the way that stocks and bonds do.
> I don't think that's the main threat Bitcoin is designed to defend against, though; I think there's a whole spectrum of confiscation threats, ranging from thieves tunneling into bank vaults (I know a woman here who lost her savings that way), to immigration authorities confiscating jewelry, to pirates, to trumped-up "money laundering" charges. And of course if we're mentioning Germany and World Wars, we must not forget the confiscation of Holocaust victims' entire possessions, including jewelry and fillings after the gas chambers. Bitcoin can't make genocide impossible but maybe at least it can make it unprofitable.
You cannot mean this seriously. Every example you write is worse for bitcoins. If your coins are stolen, that's it, you can pretty much kiss them goodbye. If the government wants to confiscate someone's bitcoins, they will beat the private key out of the holder with a $5 wrench. If WW3 breaks out and the world order collapses, a wholly digital asset that relies on a large network of high upkeep, high-tech infrastructure is surely not a particularly safe bet. You can bet that datacenters will be among the first casualties in such an event, whether outright government confiscation or a denial of service attack by the enemy.
If a bank gets robbed, for most cases it won't impact account holders at all. Even if the bank goes bankrupt, there are various government schemes that will cover account holders up to some limit (e.g. $250k currently for the US). There is none of this for bitcoins. There could be of course, but then the argument is: what do cryptocurrencies actually offer beyond what is already possible with normal currencies?
To the best of my knowledge, the only practical benefit of cryptos is that they completely sidestep KYC/AML regulations and therefore one can easily move money between regions that draw regulatory scrutiny. Countries with at least semi-modern banking infrastructure already have instant transfers so let's not bring that argument up. In any case, that's not a feature uniquely enabled by cryptocurrencies.
The fact that bitcoins are deflationary I consider a bug, not a feature. Perhaps history will prove me wrong, but in my opinion money is not supposed to be an investment asset. People should not hold cash expecting it will appreciate. It should be reinvested as much as possible.
Basically, scams. The ability to block a planned payment or ask your bank to chargeback is one of the keys to trust in online economy.
If our banking system had used something like bitcoin to implement online transactions, odds are that e-business would have had much less successs and much higher barrier to entry.
Given a system with irreversible transactions you can always add structure on top to support escrow, chargebacks, or whatever other protection mechanisms you deem prudent. It doesn't work so well the other way around.
Protection from scams requires that a malicious actor with full technical control of some account is still unable to make irreversible transactions by opting out of whatever structure supports escrow, chargebacks, etc; so either those mechanisms (conditional reversibility, with technical controls defining a reasonable regime of when reversals will be possible and when not) are built in the core system and aren't optional, or the system doesn't have a sufficiently usable reversibility because all the really large scams will simply avoid that "structure on top".
The other alternative, of course, is someone taking on full legal liability for transactions that can't be secured technically. If Facebook would offer Libra to consumers in e.g. UK, then all that "transactions are technically irreversible" means is that Facebook would be required to "reverse" the transaction to customer while being unable to recover the funds from the beneficiary - and if they can afford to do that, that's their choice to make.
You're asking way too much. It's not as if the current system actively prevents you from opting out of all the safety measures and, say, irreversibly handing cash (or something else of value) directly to a scammer; nor should it. Reversible transactions come with costs, especially when the other side of the transaction is not reversible. Chargeback fraud, for example, is a big problem for merchants, and can only occur in a system with reversible transactions. Contracting parties should be free to negotiate both the form of payment and the degree of risk each side is willing to take.
The main problem is simply the novelty of it all. Once reasonable and customary structures to handle disputes are in common use asking people to bypass those structures without a very good reason will be just as much of a red flag as it is under the current system.
Facebook is not a party to a transaction between any other two Libra users and should have no liability in the event of a dispute over payments beyond maintaining accurate records and providing a fair and above all neutral platform to conduct business.
There's a bunch of "should" in this argument. I won't debate whether it should have liability, but I'll point out that no matter how it ought to be, according the law of the land at least in EU any payment service provider inavoidably has liability in certain cases e.g. when your account has been hacked; if they are unable to reverse a transaction that wasn't authorised by me but by someone else, well, that's their problem, they still have to compensate the consumer above a self-risk of 50 Eur.
The original article mentions UK Consumer Credit Act which IMHO is not appropriate (its scope is limited to credit relations, and the protections of that act generally exclude both debit cards and most e-money systems including Libra), so the scope for potential payment service provider involvement in disputes between buyer and seller is narrower than that - and probably closer to your "should" statement than the arguments of the original article.
However, it can't be a fully neutral platform distancing itself from all liability. It is illegal to "simply" offer payment services without incurring any liability for misuse of them, breaching AML/KYC regulations, etc. Facebook has not yet (as far as I know) stated what exact legal structure they'll use for compliance with the legal requirements, so I can't comment on that, but they did make statements that Libracoin will comply with the EU regulations so I presume that some legal entity regarding Libracoin (possibly co-owned by the consortium members, or possibly multiple entities) will (have to) be a licensed payment service provider in EU, and similarly (it's usually done with separate legal entities) in other major jurisdictions.
Technical structures that "just happen" such as Bitcoin can ignore regulations but any person or organization that wants to offer services using these technical structures is fully liable for meeting all the legal requirements - and if the technical structure makes impossible to do something, they're still fully responsible for any consequences of not achieving the impossible thing; if they don't want the liability, they're free to not use that technical structure and not use/offer/advertise anything with it.
This thread was originally about the social and technical issues of scams in the context of irreversible ledgers, not legal liability. As far as that goes I am in full agreement with you: Facebook and other Libra consortium members are likely to face quite a bit of legal heat from various jurisdictions desiring them to block or reverse transactions and willing to hold them accountable for others' actions on the network. In my opinion the only sane way to introduce something like Libra would have been to give up control entirely, along with the ties to fiat currencies, and make it a permissionless, decentralized system like Bitcoin. Exchanges in a decentralized system have various regulations applied to them but in the end they aren't inherently in the position of transmitting money on behalf of their users; nor are they strictly necessary for the network to function. Libra, on the other hand, will be seen as a payment system controlled by Facebook and the other consortium members, and Facebook itself as a money transmitter, not a mere buyer and seller of coins.
Personally I find it much more interesting and productive to debate what the law ought to be rather than what it is, but as a practical matter Facebook will obviously need to take the various injustices of the jurisdictions in which they intend to operate into account—and the centralized design of Libra doesn't seem very well suited to deal with that reality.
There are a lot of minor threats to monetary systems that blockchain does not address. Bitcoin addresses the rare but fatal threat of hyperinflation (runaway inflation). Historical examples https://en.wikipedia.org/wiki/Hyperinflation#Notable_hyperin...
The only known solution to this threat is not have a single supplier of money (i.e. a lot of independent miners digging metal out of the ground, or the block chain equivalent)
I reckon the only way to error-free is redundancy, i.e. 'out of the box' we just put two boxes, or actually three for "high availability"; the underlying controller being just a dead man's switch — if A's life signal dies, failover to B; set up C as new failover; reboot A.
> I personally believe that some formal methods can greatly improve correctness, and do so affordably, but the question of which formal methods are worthwhile when and by how much each of them improves correctness is very much an open question.
Oh I can see that.
In general terms, I think cost should be focused on the most critical components; like we don't need to test every single bit of code before production. You just crash gracefully and resume state when the loss (if any) is acceptable. When it's not, then it's not a choice to front the cost, it's an imperative, part of your 'spec' as a business/product/service/free thing. Tor is slower than normal browsing, but that's the tradeoff. Fast forward 10 years and costly workloads have become either accelerated by hardware or simply benefit from general improvements, like encryption is now fundamentally cost-free for usual things like TLS (AES-based things), or increasingly AI workloads.
> blockchain is rarely the most secure with respect to the most relevant threats in a monetary system.
I very much agree. Key words being "in a monetary system", and indeed it's about economics more than tech (what I alluded to in saying 'Earth circa 2019', i.e. globalized monetary system, central-bank driven, mostly insured for most customers, etc).
Hence why I advocate that blockchain proponents explore other domains. I know businesses are, but it has more to do with topics like compliance (internal, legal).
> I reckon the only way to error-free is redundancy, i.e. 'out of the box' we just put two boxes, or actually three for "high availability"; the underlying controller being just a dead man's switch — if A's life signal dies, failover to B; set up C as new failover; reboot A.
>That's not what I said. I said that merely creating a verified formal specification of a language is not in itself a good path to increasing correctness, and I wouldn't focus on that as a significant cause for concern given all others.
This seems to be poorly considered. Isn't it easier for an OS and a language to be verified once even at great cost than hoping future billions of lines of developer code already produced at lesser cost per line are actually correct?
A formal specification for the programming language doesn't automatically verify all programs written in it; in fact it verifies none, or at most one. It serves two purposes: it defines what each language primitive does so that proofs of programs written in the lang can make use of those definitions, and sometimes it is also used to verify that a compiler indeed preserves the language's semantics, as defined in the spec, when translating it to some other language; in other words, it can be used to verify the compiler.
Focusing on a formal language spec is like saying that a good way to make your software more correct is to work hard to ensure your compiler doesn't have bugs. I'm sure you'll agree there are more important things. As to use by program proofs, often an approximate ad-hoc specification is good enough.
BTW, the article you linked to is about one particular formal method -- deductive proof. There are many others, with varying costs and benefits.
Perhaps, but PLT is not the main discipline studying software correctness -- those would be formal methods and software engineering -- although it has some overlap with those disciplines. PLT is not the general name for all study of programs; it is the name for a particular perspective, and a particular component of that study.
> my agenda, for transparency: I want to send SOC's in space on tiny RISC-V satellites
I've seen your posts in multiple threads K0SM0S, and I generally enjoy reading your thoughts and opinions. When I meet people I find interesting, I like to ask what they plan on doing with their lives. I understand completely if you don't want to share further details, but I for one would be interested in an off-topic detour into your intentions with these microsatellites. One application I always toy with in my head is a time+location verification service, but I don't think satellites are strictly necessary for that one unless you're trying to work around region-specific laws that would regulate towers.
First of all, thank you so much for your kind words, they mean the world to me, and for your interest — which is now reciprocal, I want to hear about you as well!..
I must admit I've spent way too much time trying to answer your questions in a 'concise' manner —HN's norm— but, as usual with this topic, it proved unusually hard fo me. It's rather complex, several independent yet synergistic 'moving parts' — too much repetition and cognitive bloat for a mere comment.
Thus I'm drafting something to share and discuss the concepts, if time permits it'll be up on some website (maybe reddit, maybe a forum, maybe some blog, idk...) by month's end. I'll keep you updated, if you so wish. You can reach me by email `cosmos// a t //vcx.cx` ;-)
The gist of it, FYI:
- the satellite thing is a personal research project (in very tangible ways, the experiment is to actually do it and launch). But the endgame (think 2030-2040) is a massive swarm of ~8 billion devices or more, if you catch my drift.
- However, it's an extension to a ground network which essentially aims at being an alternative infrastructure to internet. Formally it's something along the lines of a distributed, decentralized ("peer-to-peer") mesh network, fully encrypted yadi yada.
- This network is but an "optional" medium for my original idea (in ~2010) which was, in dumb terms, a communication network (which people would call 'social network' I guess, but it's not against such existing services, it's more of a global standard / spec whose primary goals are security/freedom/privacy, interoperability (like email), and to be 'unstoppable' (in the event of war, catastrophe, etc). Going back to first principles, this 'network' is not even an application but a formal protocol I suppose. It's the kind of thing that would ideally exist as an RFC 'standard' by the IETF.
This is more generally motivated by some of my philosophical values, notably freedom, empowering individuals (in the name of progress, civilization, but also happiness, self-growth).
Oh yeah, mesh nets are another great thought. We definitely need our own pipes. CJDNS is beautiful (I love that addressing scheme), but lacks incentives for people/corporations to build infrastructure for non-ideological reasons. The OpenLibreNet whitepaper had the incentives theoretically correct, but didn't go anywhere. I honestly haven't kept up on this space, but I still think about it a lot.
My biggest question is how to handle payments. Bitcoin can't realistically handle the micropayments for this purpose -- I'm not waiting for a block to hash before my website loads, nor do I want to pay miner fees for every request. The best proposal I'm aware of is that nodes keep track of balances to neighboring nodes, and when you want to establish a new connection with an unknown node you need to send them an up-front payment for X amount of data in advance. (The price of data wouldn't really be per byte of course, it's bytes multiplied by the arbitrary node-selected edge-costs all the way to the actual source and back through the cheapest/fastest path as selected by the end user.) Then when you're approaching the limit you pay more in advance, aggregating the micropayments. This means the inital connection still has to wait for a block to be hashed, and it's annoying from the perspective of a user trying to find valid peers once it's profitable enough to launch malicious fake nodes that eat up-front payments and refuse to forward packets. The initial connection time issue might be mitigated by allowing a Zahavian signal worth of coins to be sent to a burn pile, like an address that is just all zeroes, since a user who was willing to burn a pile of coins covering X+Y data Z hours ago probably isn't trying to rip you off for X data now even if they haven't successfully made a payment to your specific node yet. I'd like to believe that something like IOTA could probabalistically work well enough for micropayments that we don't have to worry about that, but I'm not convinced. Ideally a connection could be established quickly enough that vehicles passing along highways/oceans could route traffic as they go, breaking apart and reforming as necessary.
IPFS is worth googling too, if you haven't seen it already.
I'll send you an email before the end of the month!
I need to research more into that. Great pointer, thanks!
> IPFS
Yup, definitely, it's on the radar. It's still not production ready though, I'm unsure whether it will/can (I mean this particular project/implementation, not the concept).
> payments
You've definitely thought this through, maybe developed already on e.g. blockchain?
Note that my initial idea, for a neutral human communication medium/protocol, dates back before bitcoin, blockchain, etc. My "system" was designed thus works without those. The inspiration was another 'bit' network: bittorrent.
Later on when I found out about bitcoin etc., I researched the tech. While I ignore the 'currency' aspect of blockchain for this project (because 'currency' is an application; and I'm merely concerned with the protocol beneath all applications), I did find interesting ways to integrate the blockchain paradigm itself (the idea of a database that can't be tempered with, and may be distributed).
My system remains independent of its database implementation though, it should work with simple txt files, or more typically some postgres.
The naive architecture is simpler than you might think, it relies on tried-and-true enterprise-inspired models and implementations. Simple things. Where we do the magic is precisely in the execution, to make it extremely efficient (eg target the lowest viable solution space; have a "concurrency-driven design" for scaling, modularity, distribution). And as of 2019, we have incredible computing resources in the hands of half the population, so 'efficient' is 'enough'.
So there's no payment at this level. It's a protocol, a language we agree to use, and one application may be human communication, but I may be wrong about that part. The protocol stands nonetheless. We are fundamentally not far from XMPP conceptually, although we integrate much deeper (XMPP could probably be a high-level API of a node in this system).
However there's this simple equality rule: "for every bit you ask the network to process n times, you too must process n bits for the network in return". Take some, give back some.
So nodes come a la "BYOR" (Bring Your Own Resources: CPU, RAM, storage, GPU, sensors, whatever), and each node is both server / client; like bittorrent or Tor you simply receive and serve continuously.
This puts the burden of scaling entirely on users individually (remember, it's decentralized: there's no central anything, no 'final' or 'higher' authority) and you'd expect the biggest traffic producers to also be those who make a business out of it (and I'm sure there would exist many applications on this system to let users charge/pay e.g. content or merch etc). Note that "sharing" should probably mean you are willing to 'seed' said shared content, thus fairly distributing load in viral cases.
Note that the network should guarantee anonymity of all accounts (each of your chosen 'persona' is derived but your core account is never exposed and can't be compromised by misuse, only theft in-real-life).
> mesh
It's a hard problem though, I'm aware of that. The MVP may definitely 'cheat' by using regular internet to bridge the gaps (it will be necessary anyway between cities). But one primary goal is that whenever possible (i.e. within range), two devices should never communicate but through an ad hoc LAN between them. Why go to Google's server when I just need to serve a file that's locally cached in the next room, or maybe just next house?
Regarding mission-critical software in dangerous-prone contexts, there is good information from experts from the Apollo program on http://www.htius.com/
> (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.
Thanks so much for all the food for thought and recommendations. I had a hunch for "capable of recovering", and now I have a clearer roadmap (some critical steps). I see your way of thinking. This in particular:
> 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.
High-availability of components seems like a given to me (e.g. have 2, 3, 4 batteries as distant from each other as possible, to mitigate loss if one gets shot by some collision or outright fails; rinse and repeat for every critical component, starting at circuit design). In another comment, user "pjc50" suggests to me “"lockstep" chips, such as TI Hercules”, and yet my intuition would be to put two redundant ones on each satellite, just for good measure.
But the ultimate economics of the project can be made to work, imho, because I envision a swarm of such tiny satellites actually, wherein you can afford to lose a few nodes now and then, if that makes all of them orders of magnitude cheaper — and thus you can send orders of magnitude more, overall. Brute-force the reliability issue by making them expendable to a reasonable degree. No human life means they can die for all we care, if it makes sense cost-wise. Hence why in that perspective, a discussion on the cost versus benefit of formal methods is of great interest.
Needless to say, any advanced draft of the project would inevitably have to be vetted by, actually co-developed with field experts like you. To each contributor their domain. I hope it will be a given too, since I'm thinking of a 100% open-source project (both software and hardware ideally). The more eyeballs...
____
I see your points about blockchain, and they make a lot of sense; the problem I see with current 'cryptos' in general (including the big one) is that they simply aren't welcomed by most decisive institutions, including those who combat on principle the problems you mention. Like, you see the EFF et. al defending e.g. E2E encryption, but none of that drive to promote bitcoin.
Thus that 'respectable' cryptocurrencies exist to solve these problems, sure, please, yesterday! — but that they reform the financial system by their very existence? There doesn't seem to be much appeal in the mainstream. I think it's a matter of time, how much each generation weighs demographically in the global opinion / decision power. For now, it's boomers, and they're not in that place.
I'm not a field expert; I didn't design Satellogic's satellites.
Satellogic's CubeBug design did use a TI Hercules TMS570 Cortex-R, and I think it's safe to say our experiences with chips like that were good — for the relatively restricted tasks they can perform. The automotive industry has a lot of lockstep chips available for it, because it's a mass market that demands reliability under harsh conditions.
I'd like to point out that what you're describing is pretty similar to Satellogic's original business plan.
I disagree. You're making two different arguments. The first is that PLT does not study suitability, but then you switch course and say that math analagously can define suitability for specific tasks but suitability is not (and this is my own words) a normed space.
Programming language theory does not, in fact, make value judgments, but it does make statements upon which value judgments can be built given context, which contradicts your first statement.
I think you've misread my comment. Also, of course theory could be used to make judgment given all the necessary context, but the context, in this case, is much harder to obtain than the theory. If we knew whether a language's type system being sound is greatly positive (for some metric), slightly positive, neutral, slightly negative or greatly negative, then the knowledge that a certain language is sound or not could be valuable in making certain judgments. But PLT does not even attempt to ask that question, and it seems to be a much harder question than the ones PLT does ask.
Don't get me wrong -- I think that PLT is a valuable theory, but people are often confused about what it actually studies. PLT most certainly cannot tell us whether certain language designs are desirable or not as that is not what the theory studies. It can't even tell us if certain language designs lead to more correct programs or programs that are easier to read. It does tell us that if certain typing rules are used, then, say, all types in the language can be inferred, or that a system with certain typing rules is sound.
I’m new to this space so I’m not sure how PLT is distinct from formal verification, but my view of it is that formal methods are another form of testing. Unit testing also does not guarantee that you’re testing the right things, but it’s a good way to catch issues post-compile but pre-release. Formal verification moves that so that you catch issues as part of the compilation step, which is just another tool in the general toolbox of finding errors before you ship them to your users. It’s not about proving that your spec is good, it’s about automatically generating tests that find certain types of bugs.
Formal methods are a large set of methods that allow you to analyze a program in ways that can verify it satisfies certain (correctness) properties. Most formal methods don't generate tests (although some do), but the term "compile-time" is not often used, as most formal methods are not part of the compiler.
There is some overlap between PLT and formal methods, as that some concepts studied in PLT -- most notably type systems -- can be used for formal verification, but the main thrust of formal methods uses other techniques. Both disciplines heavily rely on formal logic.
>PLT does not have any tools whatsoever to determine which language is more or less suitable and it is not interested in that question.
You are slightly off here. Look at [1], it views over a metric which correlates with language utility and provides 1) result of the metric applied to various languages and 2) reason why some languages can be more of utility (less errors, for example).
I disagree that blockchain has almost no good use cases.
All a blockchain is, is a Merkle tree with a third party that ensures there is only one “main line”. That’s the use case.
All the other stuff — such as having all computers in the network watch every transaction — that’s the wasteful part. There are other ways to have a set of third party validators, that is a subset of the network watching a given merkle tree, simply says which branch is correct. SAFE network uses a Kademlia DHT with various mechanisms to ensure the validators have no say in what they watch and they need to “earn” their way into having any say about anything over time.
There are tons of useful properties, some of which are used in Merkle trees like git:
Immutability
Quick verification of tree membership using Merkle branch
Ability to download different parts from different actors (Bittorent)
Consensus and rule enforcement (eg chess game or any other evolving document)
Smart contracts and autonomous code execution
And much much more. The main problem is when people think of blockchain they think of a giant monolithic chain of blocks each of which contains ALL TRANSACTIONS IN THE NETWORK. This is wasteful.
What’s even more wasteful is when you have divisibility of the tokens, leading to an exponential growth of UTXOs and unlimited storage requirements. And each full node needs to verify the entire history of every transaction because then they get intertwined. That’s the ridiculous part.
And proof of work is the most wasteful thing of all. People need to get off of that!
> All a blockchain is, is a Merkle tree with a third party that ensures there is only one “main line”.
No. The "wasteful part" is also part of the definition of the blockchain.
Just because the word "blockchain" seems to describe only the data structure, doesn't mean that's the case.
The innovation was to couple a Merkle tree with a proof-of-work system. Both existed before in standalone forms. The Merkle tree in many, many applications, the proof-of-work for example in Hashcash to combat email spam.
Only the combination of both reached a level of novelty that deserved a new name.
(That we still haven't found a single compelling use case is another matter.)
What you mean is indeed succinctly and correctly named "Merkle tree" or "hash tree". It would have been wasteful to coin another word for it.
Blockchains are just a datastructure and proof of work is not a strict requirement. I believe the rising popularity of Proof of Stake blockchains will make that evident.
> proof of work is not a strict requirement. I believe the rising popularity of Proof of Stake blockchains will make that evident.
I thought for a second whether I should include PoS and other schemes, but decided (wrongly) that nobody would try to squeeze imaginary internet points out of being willfully misunderstanding.
But so be it: proof of stake is a different mechanism that fulfills the same role as proof of work in blockchains.
My comment had nothing to do with imaginary internet points. You just said being wasteful was part of the definition of a blockchain which is a common argument people like to make when promoting the false idea that blockchains are inherently bad for the environment. It felt important to point out that there are non-wasteful ways of accomplishing the same thing as PoW.
There is no requirement that blockchains must be secured by proof of work. Many blockchains use proof of stake. A blockchain is one or more Merkle Trees plus an external ledger saying what the last state of each tree is. The innovative piece is Consensus about this last thing. How it is achieved can vary. Ultimately consensus is achieved by the end users checking the results.
The "efficiency savings" are probably because they've rejigged their processes to make them cleaner as part of the new initiative - NOT because of blockchain. If you control and trust your data source, blockchain is a really silly choice for storing your data. And the fact that SAP is the provider says it all really - them and their like are purveyors of superfluous hokum, sold to corporate managers that don't know any better.
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 :)
The key in your explanation is "without any middlemen". It's really easy to build a system that lets you send tokens to other people with low transaction costs: just trust someone to run a central database of all the account balances. This is how you can trade Team Fortress 2 hats with virtually no fees or settlement time, for example.
What blockchain ostensibly allows you to do is create that system without having to trust anyone to run the central database. But why would Coca-Cola ever need to do this? There will always be a trusted central party who can maintain the Coca-Cola bottle production database: the Coca-Cola company itself.
> the core benefit of blockchain is reduced transaction costs.
No, this is not true. It might incidentally currently be the case with, say, Bitcoin vs. $US, but there's nothing technical that inherently makes it so. In fact, as this article and countless others reiterate, from a technical perspective blockchain is almost always more costly.
Indeed. The main reason why a given bitcoin transaction might be cheaper is because nobody's checking to make sure it's actually legal.
It's the same reason why AirBnB is often cheaper: hosts don't pay business fees and don't follow other regulatory requirements like safety inspections.
Yes, I'd agree that, today, typically nobody is checking to make sure that an Ethereum transaction is legal.
But, it's important to understand that Ethereum is not a replacement for or opponent of KYC, AML, or checking if transactions are legal. Ethereum is a starting point, a base layer. It is necessary to rebuild all kinds of monetary controls into Ethereum's app layer. I support this development. Within 5-10 years all of the traditional controls will become available on various parts of Ethereum -- KYC, ability for government to freeze accounts, etc.
You just reminded me: A friend of a friend who worked at Autodesk told me once that their inter-office "mail" system was international and didn't go through customs.
Blockchain (ie. Ethereum) is, overall, a reducer of monetary and non-monetary transaction costs.
Example of reduced monetary transaction costs:
The current Ethereum gas price for a token transfer is $0.04 (https://ethgasstation.info/). Operations on Ethereum are relatively inexpensive and will become much cheaper with Ethereum v2 in a couple of years. The cost of Ethereum operations is orthogonal to the value of the money being manipulated. You can transfer $100M for $0.04.
Example of reduced non-monetary transaction costs:
Say you wanted to launch an eBay-type app with a single market for a dozen countries. Some customers may bring Euros, others Swiss Francs, some USD. Each market auction selects a currency from a whitelist. All bids for that auction must be in its selected currency. On Ethereum you can bid Swiss Francs which will be dynamically exchanged for USD. Unlike using your VISA for forex, this currency exchange is at the same price that whales and banks get; you pay no spread fee for being an end consumer. The non-monetary transaction cost part is that this Ethereum-based currency exchange API can be permissionlessly integrated in an afternoon.
2nd example of reduced non-monetary transaction costs:
https://www.pooltogether.us/ is a no-loss, audited, provably fair lottery built on Ethereum. The way the lottery works is -- you always get your money back, but your money bears interest during the lottery period, and all the interest goes to a single lottery winner. So the cost of the lottery is the time value of your money. PoolTogether is built on other Ethereum projects, that's why the lottery proceeds earn interest. The non-monetary transaction cost part is that PoolTogether is able to access interest-bearing deposits as easily as you can use jQuery. Also anyone in the world can participate - reduced cost of being in another country.
Here's how monetary and non-monetary transaction costs are relevant to a Coca-Cola supply chain --
Blockchain (ie. Ethereum) excels when a heterogenous network of 3rd and 4th parties come together in a commons and interact permissionlessly based on a set of rules enforced by the system.
Ethereum is basically the World Wide Web with hyperlinks except with programs in general and money can live inside those programs.
An Ethereum-based supply chain system could do a lot of things. Not sure if these are valuable because I'm not a supply chain expert. But I can speculate.
Coca-Cola's Ethereum-based supply chain system could...
1. associate an eBay-style reputation with each supply chain participant. These reputations could then be used by more parties (eg. Pepsi) than if they were locked in a centralized system. Coca-Cola might retain the option to override any reputation.
2. provide a global audit trail of supply tracking. Similar to FedEx's "track my shipment", except you could transfer payment for supplies in the same blockchain transaction that updated their status. And those updates could automatically feed into the reputation system.
3. pay for supplies with a security. For example, Coca-Cola could tokenize a portion of its common stock and pay suppliers tokens of common stock in the same transaction that pays them currency. Or Coca-Cola could automatically distribute a pro rata stock grant to the entire supply chain each quarter. This could better align a global, heterogenous supply chain with the long term interests of Coca-Cola.
4. integrate with other Ethereum-based systems. For example supply payments held in escrow could automatically earn interest in https://compound.finance/. Payments crossing international borders could automatically exchange currencies at a very competitive, no-fee rate (eg. https://dex.ag/).
Should Coca-Cola embrace an Ethereum-based supply chain? I have no idea. But after spending hundreds of hours studying Ethereum I feel very confident that there is something very special going on here.
Blockchains are genuinely pretty promising for supply chain tracking. Distributed ledgers are most famously useful when you distrust the motives of a central authority like Bitcoin, but they're also a reasonable option if you distrust the accuracy of a a central administrator.
So for the purposes of supply tracking, different Coca-Cola facilities and shipments are 'individuals' which might report mistaken or dishonest results to the central server. And once somebody screws up, that trusted authority becomes a problem for others facilities to work around. For sufficiently large and restrictive systems (like US military supplies), correcting an error can become functionally impossible. At that point, you start resorting to awful two-wrongs-make-a-right solutions like entering fictional shipments which "move" a misdirected item from the listed location to the real one, or even redoing needless part replacements to match reality to documentation.
Obviously you can track supplies without a blockchain, and I'm sure a lot of Coke's actual gains came from tearing out a bad system and replacing it, but a blockchain does at least encourage good tracking design (one authoritative record per item, transactions are assessed by peers rather than immediately accepted by an authority). And if the goods in question have individual identifiers, "proof of work" is actually a great addition. It doesn't have to be computationally hard if you trust all the users, but you still get a system where "I am holding this and hitting it with an RFID scanner" is allowed to overrule any number of past errors regarding that object.
(Did Coke get all those gains? No idea. They probably just scrapped some legacy nonsense for a not-too-stupidly designed system.)
As the article explains, they're expanding their test because it's demonstrated that they could reduce order-reconciliation duration from 50 days to just a few days. That's a big deal for a $21 billion-a-year supply chain.
So, for those of you who are so sure that blockchain is pointless end-of-story, it seems like you're not taking into account how messy and expensive it is to manage data and legal contracts with many small business entities throughout supply chains. But I'll read more into the links you sent with your arguments, thanks for that.
--
Regardless of the other, far more important sections of this article, I find the section about the programming language misleading. Programming language theory does not study the quality of programming languages or their suitability to certain tasks. It is simply outside the purview of the discipline. PLT does not have any tools whatsoever to determine which language is more or less suitable and it is not interested in that question. The theory studies the properties of formal systems and the internal implications of their design. Much like mathematics can deduce from the Peano axioms that 10 > 5, but it says absolutely nothing about whether 10 is "better" than 5 because the answer to that depends on context (are we talking cookies or tumors?) that is simply outside the purview of mathematics. Similarly, PLT can say whether a certain formal system is sound or not, but it says nothing whatsoever about whether soundness is "good", "bad" or neutral, and certainly not how good or bad it is. Of course, programming language theorists have opinions on the matter, but those opinions are not supported by the theory.
Also, given the other glaring flaws, there is nothing to suggest that a formal definition of the programming language would improve matters in any perceptible way. After all, we do entrust the world's monetary system, and sometimes even our lives, to software written in programming languages that don't have a formal definition. As someone who studies the issue of software correctness, a formal definition of a programming language is certainly of interest to theorists, but it has not been shown to be a particularly worthwhile means of increasing correctness.