Spring Follies in Nakamotoland

This week I looked through one of my slush piles, a collection of headlines about cryptocurrency, blockchain, and related “Oopsies”.  The great land of Nakamoto seldom disappoints on this front! : – )

Oopsies R Us!

---

First up, we see that “Crypto Lending Platform BlockFi Attacked With Flood of Fake, Abusive Sign-Ups” [3].  Apparently spammers, likely bots, swarmed ths site, creating bogus new users, with naughty names. Tsk. Very grown up.

This issue actually has nothing to do with crypto, per se, except that this is a major “crypto lending platform” with millioins of dollars in play, which apparently lets anyone just create accounts.  You have to wonder about just who might be using this service and for what. And what other details are they blowing off.

---

Last fall, we heard from the ever controversial MakerDAO (how are they still around?).  I’m not really sure what all MakerDAO is up to, but apparently one of it’s “features” is, as James Creawley’s headline puts it, “MakerDAO Loans Can Be Gamed to Hold Out Funds From Liquidation” [2]. The details are obscure to me, but the gist of it is that it is possible to avoid repaying some loan, apparently due to a wrinkle in the complex and vague protocols.

Hmm.  Software that has bugs because it is complex and ambiguous?  That’s never happened before. : – )

---

And, of course, there is a never ending parade of just plain theft.

For example, the perhaps too aptly named, DODO decentralized finance platform was “Drained of $3.8M in DeFi Exploit” [1].   DODO is a lending service, providing instant, poorly secured loans of cryptocurrencies–unencumbered by human oversight.  What could possibly go wrong?

The exploit is question was–wait for it–a bug in an executable contract.  The bug allowed hackers to create “counterfeit” tokens, and then loan them to themselves, and cash out.  With the magic of blockchain, the heist was executed in seconds.  (I ti s reported that a lot of the stolen funds was traced and recovered.)

---

I think the thing that ties all these oopsies together is that they all are pretty normal software bugs.  Hey, all software has bugs.  It should not be trusted. 

But, the fundamental tenets of Nakamotoism hold that cryptocurrency eliminates the need to trust other people and institutions.  Essentially, Nakamoto replaces people with software, with the implicit claim that software can be trusted more than people.

OK, I’ll grant you that software can be trusted differently than people.  In particular, software may be more predictable than people, and maybe more transparent.  On the other hand, people can use common sense, and generally possess a butt to be kicked if necessary

Nakamotoan software is no worse than most, possibly better than average.  But when there are zillions of dollars involved, and things move at zilloflop speeds, the implications of bugs are gigantic.  So, no matter how “trustworthy” platforms and “smart contracts” may be, even small oopsies can drain millions in a few seconds.

Finally, note how these bugs were handled:  actual humans took responsibility and intervened to make things right.  If Emperor Nakamoto aimed to eliminate humans from the trust equation, he has not succeeded. 

---

1. Jamie Crawley (2021) DODO DEX Drained of $3.8M in DeFi Exploit. Coindesk,  https://www.coindesk.com/dodo-dex-drained-of-3-8m-in-defi-exploit
2. William Foxley (2020) MakerDAO Loans Can Be Gamed to Hold Out Funds From Liquidation, Startup Finds. Coindesk,  https://www.coindesk.com/makerdao-loans-collateralized-debt-liquidation
3. Sebastian Sinclair (2021) Crypto Lending Platform BlockFi Attacked With Flood of Fake, Abusive Sign-Ups. Coindesk,  https://www.coindesk.com/blockfi-attacks-email-spam

Cryptocurrency Thursday

Yet More Ethereum Follies: EiP-1559

I have commented many times on the difficulties of Nakamotoan software engineering.  These problems are often tagged ‘governance’ issues, because the problem isn’t a lack of ideas or ability to implement them, the problem is decision making.

Ethereum has had a slightly better history than some cryptocurrencies, due to the towering presence of Vitalek Buterin  (“All Hail, Vitalek!”).  But even so, Ethereum has had plenty of problems, and a notorious fork that created ETHC.

This winter Ethereum is facing yet another ‘governance’ challenge, in the form of EIP 1559 [2].

This is a proposal to change the Ethereum 1.0 protocol (Ethereum 2 is still cooking….), and has the support of Vitalek (“All hail, Vitalek!”).  But many miners are resisting the change, and threatening to ‘vote it down’, i.e., reject the update.  If enough miners reject it, the protocol will remain unchanged.  This is how ‘consensus’ works.  Sigh.

As I have said, this is a hell of a way to program a railroad.  After more than a year of discussion and implementation, the code is ‘ready’.  But the decision to actually use it has yet to be made.  From an engineering point of view, this is backwards, and it is madness.

The specifics of 1559 are rather obscure to me.  The basic point is an adjustment to the payouts for miners, i.e., rewards for processing new blocks onto the blockchain.  The current incentives have led to congestion and long (and variable) latencies, and the modifications are intended to stabilize the throughput.  It does so by modifying the incentives for the miners.

If they work as intended, the new approach should reduce latency and result in more stable fees.  It may have other benefits, such as deterring DDoS attacks [1].

So, what’s the problem?

Well, the current system has seen increased traffic and fees to miners have increased rapidly.  EIP 1559 will ‘fix’ this, reducing payouts to miners.  So, duh!  Miners are going to vote against a pay cut, even if it would benefit everyone else.

Additionally, large scale miners have manufactured specialized processors to execute the current protocol.  The change will obsolete that hardware, which will be another economic hit.

In the Nakmotoan universe, these miners ‘vote’ on any changes to the software by supporting or not supporting it.  If enough miners (51%) refuse to process new style blocks, the new software will not work with the majority, and so will not be part of the consensus ledger.  I.e., 1559 will not be ‘real’ Ethereum.

Now, Nakamotoland is not exactly one-person-one-vote.  And industrial miners are not necessarily operating alone.

William Foxley reports that a number of mining operations are working together to defeat the proposed changes [3].  If enough large operations reject the change, it will be dead.

This kind of minority control isn’t necessarily how Nakamoto envisioned ‘consensus’ working, though it is hardly surprising.

---

This episode strikes me as an inevitable consequence of Nakamoto’s basic scheme.

Nakamoto-style mining incentives set up a form of operant conditioning, which rewards specific behavior.  In this case, the conditioning is highly successful, as the miners have learned to follow the protocol extremely well.  And, like many  cases, the organisms have learned very, very specific behaviors.

They have also learned behavior which is optimal in the short run but globally non-optimal.  This is a common result with operant conditioning.

The change to the protocol will demand significant ‘relearning’ for the miners, and they don’t want to do that.  (If you let experimental rats vote, psychologists would never be allowed to change the reinforcement schedule after the rats learned it.)

To me, this sort of situation is inevitable if you use ‘incentives’ to motivate miners, and also let miners control the protocol.  In politics, we call this an inherent conflict of interest.

The long term worry is that Ethereum might get stuck in a ‘local minimum’ that is highly profitable for miners, but catastrophic for users.  That could spell the end of Ethereum as a useful system.

---

1. Tim Beiko, Why 1559?, in HackMD, January 20, 2021. https://hackmd.io/@timbeiko/why-1559
2. Vitalik Buterin, Eric Conner, Rick Dudley, Matthew Slipper, Ian Norden, and Abdelhamid Bakhta, EIP-1559: Fee market change for ETH 1.0 chain. 2019. https://eips.ethereum.org/EIPS/eip-1559
3. William Foxley (2021) Minority Mining Pools Threaten to Collude Against Contentious Ethereum Update. Coindesk, https://www.coindesk.com/ethereum-mining-pools-threaten-contentious-update

 

Cryptocurrency Thursday

What Is A “Valuecoin”?

In my neverending quest to understand DeFi, I encountered a new “valuecoin”.

I know that one of the hot topics in Nakamotoland are “stablecoins”, which are implemented with a blockchain and other Nakamotoan technology, but are pegged to other assets.  Pegging is generally done via executable “smart contracts”, i.e., with software. The simplest form is pegged to a fixed asset, e.g., a Bahamian Dollar.   But there are a lot of possible variations that might be called a ‘stablecoin’, depending on exactly what the peg is and how it is implemented.

We should note in passing that this entire concept is pretty dramatic heresy as far as strict, fundamentalist Nakamotoism would say.  Bitcoin is “digital gold”, it has its own intrinsic value (if any), not depending on any other asset, especially the hated ‘fiat currency’.  Linking a cryptocoin to other assets is, well, just wrong.

This winter William Foxley writes about a variation on this theme, which the developers call a “valuecoin”.  As the website puts it, ARTHCoin is “World’s first non-depreciating currency” [1].  The idea appears to be to have the crypto tokens be redeemable for a fixed, inflation adjusted value in whatever the pegged assets are.

So, ARTHcoin is both pegged to an external asset, and indexed against the fluctuation of that asset.

Frankly, I don’t really understand how this stability is supposed to be done. This being Nakamotoland, this balancing act is supposed to be completely automatic, with a fancy algorithm that magically keeps everything working.  It looks to me like human interventions are available in the form of “buying bonds”.  Is this some kind of (heretical) human backup, escape hatch for the inevitable face plant of the algorithms?

As Foxley notes, this approach “hasn’t really panned out” for earlier incarnations of the idea.  I know nothing about those specific systems, but I do know that efforts to peg assets are fragile and fraught.  It is difficult to imagine an algorithm that will do this.

But MahaDAO is sure that this time is different, because they have just the right sauce.

We’ll see.

In the end, I have so many questions.

When the website says “non-depreciating”, who exactly stands behind that promise?  And what does that promise even mean?  Is it a promise, or more of a “goal”?

What is the business model here?  Is MahaDAO taking a rake off?  If so, how much and how is this covered?  (There seem to be some kind of “fees”.)

Above all, what is this coin even for?  Why is it better to have a digital token opaquely linked to a basket of assets than to simply own the assets?  This looks like it wants to mash up indexed bonds with the liquidity of “cash”.  How is that supposed to even make sense?

And, of course, nasty skeptical people could ask if you need a blockchain for this?

---

1. William Foxley (2021) MahaDAO’s Algorithmic ‘Valuecoin’ Goes Live on Ethereum. Coindesk, https://www.coindesk.com/mahadaos-algorithmic-valuecoin-goes-live-on-ethereum

 

Cryptocurrency Thursday

Ethereum Does an “Accidental” Fork?

Hmm.  I’ve remarked many times about the awkward and basically backwards software Nakamotoan engineering process.  Most Nakamotoan cryptocurrencies follow a process adopted from open source software, which amounts to (1) write the code, (2) release the code, (3) see if users accept the new code.   If not people accept it, throw the new code away.

In addition, Nakamotoan cryptocurrencies have an additional wrinkle to the universal problem of forward and backward compatibility.  Any software change that is not backward compatible, i.e., that old software can’t handle, essentially creates a new, incompatible “currency”.  Technically, there is a branch in the running ledger, with the same history up to the fork, and then two different histories going forward.

This is known as a “hard fork”, and it is “hard” because you have to choose one branch or another, new software or old.

Hard forks are painful for any software, but in Nakamotoland they tend to be chaotic and contentious because of the “consensus” process for software management.  It is easy to end up splitting the users into two camps, some using the new and some using the old software.  Worse, with the shared history before the fork, there can be gotchas that let people exploit the two branches to double spend or otherwise mess things up.

For this reason, hard forks are usually talked about for quite a while and rolled out carefully.  If nothing else, this gives people time to get ready, and time to reach “consensus”.

So the headlines this month about Ethereum doing an “unannounced hard fork” was quite worrying [2].  Hard fork is bad enough, unannounced hard fork is a serious mess up.

It appears that this was actually an “accidental hard fork”, due to an accumulation of changes over several months.  If I understand correctly, if you were not up to date with all the changes, you would find yourself incompatible with the latest.  I.e., a recent change made software that was current last spring incompatible.  Ooops.

Considering the complexity of cryptocurrency software, it’s surprising this doesn’t happen more often. If anyone might be running any version of the software, or any of dozens of versions, just how many possible incompatibilities can you check?

---

In subsequent days, the incident has become enmeshed in a discussion about disclosure of security bugs.  The problem seems to have stemmed from a security hole discovered and patched, but not widely disclosed.  This led some users to still have the unpatched software long after they otherwise should and would have upgraded.

The situation has led to a discussion of how and when security problems should be disclosed.  The general practice for open source (and a lot of proprietary software) is to disclose a bug to a clearinghouse immediately, to install patches in key infrastructure, and only then publish the bug.

The process aims to get the fix out in the world as quickly as possible, and not to give information to bad actors until it doesn’t matter as much (i.e., key players have already patched).

This process isn’t totally “fair”, since some users (e.g., big infrastructure) get information before the general public.  And after the bug is disclosed, some users will be vulnerable if they do not or cannot install the patches.

Over the years, the consensus is that prompt, broad disclosure is the best policy, assuring that all users and developers have as much information as possible.  “Security via obscurity”  (i.e., not disclosing bugs)  is widely considered catastrophically stupid.

Nakamotoan cryptocurrency communities are recapitulating this discussion, with the wrinkle that there are huge financial stakes.

In the context of Ethereum, the developers followed a similar process, though the bug wasn’t widely announced yet, and, as we saw, caused a big problem.

And the “unfairness” is a bigger issue.

While it’s “unfair” if Microsoft, Apple, and Cisco get a network bug patch first, it’s probably good for the world.  In fact, it actually helps other developers, because they trust the report and the patch all the more if it is already endorsed by the big guys who know what they are doing and have vast resources to test the patch.

But in Nakamotoland, giving privileged access to information to some players can be a significant financial advantage—especially if the underprivileged get into trouble as in this case.

And, as noted above, Nakamotoan “patching” is an iffy process anyway.  Disclosing a security hole can mean that the unpatched version is wide open to attack.  Implementing the patch isn’t really optional at that point, which violates the spirit of the consensus system.  Essentially, developers can force changes on the community in the name of security.

In this, the consensus system is diametrically opposed to the normal logic of security patching.

---

If all of this seems obscure to you, you are right.  Nakamotoan software engineering makes many ordinary processes much more difficult, and much more contentious.

And, just as Nakamotoans insist upon recapitulating the discoveries last 300 years of economic history, Nakamotoan software developers are recapitulating the lessons of the last 50 years of software engineering practices.

Sigh.

---

1. William Foxley (2020) Developers Debate Disclosure Protocols After ‘Accidental’ Ethereum Hard Fork. Coindesk, https://www.coindesk.com/developers-debate-disclosure-protocols-accidental-ethereum-hard-fork
2. Daniel Palmer (2020) Ethereum Service Providers Scramble to Update Software After ‘Unannounced Hard Fork’. Coindesk, https://www.coindesk.com/ethereum-service-providers-experiencing-issues-after-reported-blockchain-split

 

Cryptocurrency Thursday

 

Ethereum Struggles to Diversify—the software, not the people

One of the eternal challenges for software infrastructure is to maintain a balance between unity and diversity.

What I’m talking about is this.

For a lot of software, especially anything that works over networks, it is essential that everyone operates compatibly, which means that many crucial operations have to be the same everywhere.  This is what standards are for.  For example, URLs have to work the same way everywhere, or the World Wide Web will not work.

At the same time, there are many independent users and lot’s of different software that need to work together  The easy way to get things working is to push out one implementation that everybody uses.  Often, this implementation is what open source projects amount to, which we used to call the “reference implementation”, i.e., the pseudo-official implementation.

If everyone uses this reference implementation, it is the software equivalent of monocropping; and it has the same risks and benefits as genetic monocropping does.  Moncropping is the cheapest approach, because everyone can share the same software, which only has to be built and fixed once.  Monocropping also takes the least effort, because everyone is just cloning the solution that is guaranteed to work the same as all the other people are doing. Less testing, less figuring things out, less worrying about it.

The risk, of course, is that any imperfection, inefficiency or bug will be present everywhere.  If and when the code is hacked or crashes, then the whole network goes down the same way.   Furthermore, to the degree that the standard implementation is taken as the only correct behavior, it is much harder to detect fundamental errors, and difficult to change the way it works.  The software, for better or worse, becomes the standard.

All things considered, it is best to have multiple, independent implementations of key software.  This not only gives users meaningful choices, it also makes the overall system more robust in the face of inevitable problems.

I have even worked with projects that would not adopt any standard until there were at least two independent implementations of it.

The thing is, creating multiple implementations is hard.  And expensive.  Writing software is really time consuming and costly, writing multiple versions of the same software multiplies the expense horribly.

Worse, keeping multiple versions of the same software working smoothly together is even more work, requiring constant attention to make sure bugs are fixed and planned changes implemented at the right time.  And, of course, things need to be tested to make sure that the independent versions really do work together like they are supposed to.

This is a general challenge for all software, so it is no surprise to see it arise in the cryptocurrency world.

This summer, William Foxley reports that this year, Ethereum is experiencing exactly this  challenge [1].

Like other Nakamotoan cryptocurrency, Ethereum has network of servers maintaining the shared ledger, and a larger network of client software that sends and receives data to the core network.  These networks are connected by standard protocols.

In Ethereum land, the core team has implemented a version of client software (“geth”) that lets applications access the Ethereum blockchain (and “smart contracts”) in various ways.

In earlier years, there have been other independent versions of similar client software  for developers to choose among. All the client versions must do the same thing, but each has its own strengths and weaknesses, contributing to the “genetic diversity” of the overall network.

Unfortunately, maintaining these clients and libraries is expensive and time consuming, so the number dropped to two.  And the second one has effectively been abandoned since the start of this year, falling behind in bug fixing and technical development.

So now there is one.

This monocropping has had implications.  For one thing, changes to Ethereum have been delayed, trying to allow time for the alternative implementation(s) to catch up.  You can’t have one part of the network forge too far into the future without the rest, or the system will stop working, so the slowest developers set the pace for everyone.

The situation went from obstructive to fatal this summer, when the alternative version (now known as “openethereum”) of the code became unusable because of a bug.  Oops.  (“Buggy Code Release Knocks 13% of Ethereum Nodes Offline”)

The few people working on openethereum  could not prevent the bug and it will take months to fix it.  (A short glance at the bug reports suggests that this is some kind of synchronization issue, which is going to be nasty with a capital “N”, even if you understand the code.)

The recommended “fix” is to go back to a version from 2019.  Just restarting with the old code could take days or weeks just to catch up the transactions to the present.  And no one knows how long it might take to get the old code up to date.  As one github poster put it, “[I’m] switching to geth”, i.e., giving up on openethereum altogether in favor of the main version.

Long term, this situation certainly raises a question about whether Ethereum can support enough diversity in the key software.  A lot of this software is supported by volunteers and donated time.  Just how much software can be supported this way to a high enough standard?

I’ll note that the whole Nakamotoan enterprise does not really address this challenge.  The design of Nakamotoan cryptocurrencies is so complex that maintaining more than one implementation is really hard. The incentive mechanisms do not address the cost and effort of implementations. And the governance mechanisms, such as they are, have no way to coordinate multiple implementations.  Indeed, the consensus process is so awkward and painful that it tends to encourage centralization of software efforts.

All these troubles are quite familiar to anyone who has built and maintained real software with real users.  Cryptocurrency may or may not be “disruptive” technology, but it certainly isn’t immune from the challenges of software engineering.

As I’ve said before, whatever kind of “genius” Nakamoto is supposed to have been, he certainly wasn’t a particularly brilliant software engineer.

---

1. William Foxley (2020) Buggy Code Release Knocks 13% of Ethereum Nodes Offline. Coindesk, https://www.coindesk.com/buggy-code-release-13-ethereum-nodes-offline

 

Cryptocurrency Thursday

Crypto Trading Cards

Over the past few years, one of the most successful use cases for Nakamotoan cryptocurrencies has been digital collectables, essentially digitally realized trading cards.

This isn’t quite the “reinvention of money” that some envision.  It isn’t even very much of a reinvention of trading cards.

---

The key to this use case is the use of cryptographic signatures to create unforgable tags, essentially signed or numbered copies.  The Nakamotoan distributed ledger serves to record the provenance of each collectable, assuring that there is only one valid copy.

Like trading cards, the actual collectable is worth very little.  But the uniqueness and secure provenance may make something rare or otherwise desirable.

This concept has been deployed in games like Cryptokitties and virtual real estate collecting.  The fact is, you can do this with pretty much anything you can represent as a token.  It’s not that hard.  (And certainly not innovative.)

(Technical comment:  this is basically the same technology as used in supply chains and other provenance applications.  It is also the same as digital trading in securities.  The only difference is that the actual things owned are, almost by definition, valueless except for scarcity.)

---

This month, the notorious resource hogs at Cryptokitties are announcing a new example, NBA trading cards, NBA Top Shot [1]

Possibly the best news for most of us is that they are building on their own blockchain, rather than piggy backing on a public ledger.  This is a mercy for those of us who might want to do something else without having to deal with slews of trading card trades clogging up our network and disks.

---

I’m going to have to put this silliness in the running for Cryptotulip of the Year.  It’s a perfect example of a non-innovative solution to a non-problem.  It is also a clear indication of one of the most successful examples of how a Nakamotoan blockchain can work.

Thinking about it, I wonder if some of the enthusiasm for cryptocurrencies, with their hope to “reinvent money” and so on, come from a basic confusion about the difference between this kind of “trading card” economy and the actual, real world economy.

If you think that economics is all about bidding on commodities, commodities that you never actually produce or consume, then I can see that you might think cryptocurrencies are way more useful than they actually are in most cases.  (As far as I know, real economies are about lots of things, most of which are not traded like commodities.)

So there’s a though problem for Nakamotoans:  why are digital tokens not equivalent to money?

---

1. William Foxley (2020) CryptoKitties Creator Debuts NBA Game on Its Own Blockchain. Coindesk, https://www.coindesk.com/cryptokitties-creator-debuts-nba-game-on-its-own-blockchain

 

Cryptocurrency Thursday

Ethereum Vies For Repeat of CryptoTulip Recognition

Frankly, I’ve lost track of Ethererum’s “engineering” process, but it’s definitely “interesting”!

For a couple of years now we’ve been waiting for “Ethereum 2.0”, which includes a dramatic–and not really orthodox Nakamotoan–change to “Proof of Stake” consensus.  This massive and not backward compatible change is taking some time to get here, which is a good sign that the developers are being responsible.

But this month I read that another proposal, called ProgPOW is being pushed. <<link, cite>>  This is a different, dramatic, non orthodox Nakamotoan change to the consensus process. This proposal has been around for more than a year (i.e., code exists that could be folded in to the main code).  But it is extremely controversial.

Huh?  I thought this was dead last year.  But apparently not.

As William Foxley reports, the continuing discussions are not so much technical, but “political” [1].

Generally speaking, Ethereum 2.0 is the path advocated by Vitalik Buterin, first among equals in the Ethereum community, and the overall goal is to dramatically reduce the Carbon footprint of Ethereum consensus.

The ProgPOW proposal comes from mining companies, and aims to reduce the use of custom ASIC accelerators, which distort the Nakamotoan vision of a flat, “democratic” network.

So Ethereum is blessed with not one, but at least two possible hard forks.  (Note that neither of these would make any different to ordinary “retail” users, except in case of disastrous goof up.)

(See also this, this, this, this.)

Ethereum now has a recognized “hard fork coordinator”, and he confirms that ProgPOW is not on any schedule for future forks at this time.  It is difficult to stress how innovative this “coordinator” is, for the cryptocurrency community!

The meeting itself was the usual yackfest, with no strong conclusion. In other cryptocurrency communities, this could easily lead to different parties claiming victory, and possibly competing versions of the code.  But Ethereum has an official roadmap, for better or worse, and a shepherd keeping track of what is on that roadmap.

It’s hard to know what’s going to happen with Ethereum. The community has a culture unlike most cryptocurrencies, with a benevolent patriarch not interested in personal profit and a semi-professional software development organization apparently concerned with good engineering.

This is not you father’s cryptocurrency!   It also is less and less Nakamotoan, no matter what the rhetoric says.

Interesting, from so many angles.

---

1. William Foxley (2020) Ethereum’s ProgPoW Call Features Frustration but Little Progress. Coindesk, https://www.coindesk.com/ethereums-progpow-call-features-frustration-but-little-progress

 

Cryptocurrency Thursday

bTz: Crypto Ooopsie of the Month

One of the “features” of Nakamotoa’s Alternative Universe is that it replicates all the features of conventional systems, without adult supervision.  For true believers, this is not only a good thing, it is nearly the only thing.

So, the Nakmaotoan Alternative Universe has electronic trading, which looks the same as conventional trading. This is called “Distributed Finance”, and goes by the terrifying tack DeFi. But inside, the systems are unregulated (or “self-regulated”).  Caveat Emptor.   You are on your own.

And with the genius of the Internet (which I certainly helped boot up), the systems are all talking to each other, and generally “the system” is actually a bunch of independent components working together to do your biz.  At light speed.  Without guardrails or seat belts.

What could possibly go wrong?

(If you actually worry about such questions, you probably spend time studying the history of financial systems and regulations.  But who’s got time for all that.  Move fast, break things, apologize later.)

This winter the Ethereum community was treated to a wonderful demonstration of life in the Nakmotoan Alternative Universe of DeFi.

In a particularly embarrassing incident, a decentralized finance project reassuringly named “bZx” was showing off their stuff at a hackathon in Denver.  During this strut session, they were hacked, and the attackers walked off with hundreds of thousands of dollars worth of digital assets [1].  Ooops.

As William Foxley  reports that the attack was somewhat complicated.  The attackers borrowed over 2 million dollars in a “flash loan” (which I assume means no collateral and no diligence, due or otherwise).   Then they bought a million dollars worth of short contracts on one exchange, and dumped the shares on another.

The sell off was targeted and succeeded in manipulating the “oracle” that sets prices for bZt, and they were able to exploit the swing to make big money off the short.

I don’t have precise information about the timing (see this perhaps), but I’m pretty sure this all happened in a few seconds, bing-bang-boom.

As Foxley put it, this attack “Reveal[ed the] Experimental Nature of Decentralized Finance.”

One of the problems seems to be the use of “oracles”, which are, well, systems that you have to trust.  It isn’t clear, but the experimental system may have had only one such oracle, which was exploited by the attack.  In any case, the fact that no one  knows for sure what oracle or oracles might ahve been involved indicates the opacity of the system.

Here’s the good news:  the system worked almost exactly how it was supposed to.  There was one bug that should have stopped the trade, maybe.

These transactions were done with “smart contracts” without need for human intervention.  No pesky paperwork, and “the man” was nowhere to be seen.  So the brakes were all software.  (What could possibly go wrong.)

Here’s more good news:  this was probably legal.  “DefFi” is unregulated, so who knows what, if any, legal framework applies.

So, congratulations bZx, on a successful demonstration of “Decentralized Finance”.

---

1. William Foxley (2020) Exploit During ETHDenver Reveals Experimental Nature of Decentralized Finance. Coindesk, https://www.coindesk.com/exploit-during-ethdenver-reveals-experimental-nature-of-decentralized-finance

 

 

Cryptocurrency Thursday

Cryptocurrency Winter Follies, Bitcoin-Cash Edition

One of the innovations of Emperor Nakamoto’s Bitcoin is the “consensus” mechanism, which let’s everybody do whatever they want, ultimately settling on the most agreed version of reality to be the consensus reality [2].

This mechanism makes updating the software a weird and wacky process.  A proposed new version is completely implemented and deployed, and then users either use it or not.  If enough people pick up the new code, it becomes the official version.  But people can continue to use the old version, effectively “forking” off an alterative version of the currency, and a new branch of alternative history.

What a way to run a railroad!

---

In the Bitcoin world, one of the most notorious “splitters” is Bitcoin Cash (a deliberately confusing name), which split from the original Bitcoin circa 2017, implementing larger block sizes.  There has been a second split, driven by perennial pest Craig Wright, to create Bitcoin SV. (“SV” stands for “Satoshi’s Vision”—Wright himself claims to be Satoshi, so you can parse that how you want.).  And, to boot,  earlier this year the BCash people fixed an oopsie by deliberately subverting the consensus protocol to rewrite history.  (That is not supposed to be possible.)

These earlier splits were deliberate, driven by disagreements among developers and users.

This month Bitcoin Cash experienced an unexplained fork.

There was a scheduled software upgrade which was not backward compatible.  Most of the users picked up the change as expected, but at least one large mining operation did not upgrade.  This means that the mystery miners are crunching away, still adding records to the old branch instead of the new, creating a new fork of Bitcoin Cash, and generally sowing confusion.

Sigh.

It isn’t clear who is doing this or why.  As William Foxley puts it “Unknown Mining Pool Continues Old Chain” [1].  This could be an accident.  It could be deliberate.  Who knows?

Whatever the reason, this fork is a hazard for users who might accidentally use the old branch instead of the new. And it is a pain for developers who might have to support both versions, adding to the confusion of the crypto world.  On the other hand, so far as we know, the old branch isn’t being maintained anymore, so bugs are not being fixed, ports aren’t being kept up, and the two branches will soon diverge even farther as changes are made to one and not the other.

This definitely is not the way to run a railroad!

---

Bcash and its dysfunctional family are certainly in the running for the 2019 CryptoTulip of the Year, though Libra may stomp everybody.

---

1. William Foxley (2019) As Bitcoin Cash Hard Forks, Unknown Mining Pool Continues Old Chain. Coindesk, https://www.coindesk.com/as-bitcoin-cash-hard-forks-unknown-mining-pool-continues-old-chain
2. Satoshi Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System. 2009. http://bitcoin.org/bitcoin.pdf

 

Cryptocurrency Thursday

Betting on Libra

William Foxey reports that there is now a futures contract that let’s you bet on when  Facebook’s Libra cryptocurrency will launch [1].

My first reaction to this headline was something like, “those crazy Nakamotoans are at it again!”  Not content with their thriving market in Cyber Tulips, they want to bet on when the next ship load of Crypto Tulips will arrive in port!

But then I realized that this isn’t really about cryptocurrency, per se.  This is betting on the date that vaporware will be “launched”.

Look, I’ve been making software that doesn’t work for almost forty years now.  And I’ve been missing software release deadlines for, well, forty years now.  Software is never on time.  Only a fool would bet on a software release date.

Obviously, this is an idiotic bet for many reasons.  Who cares what day Libra is released, anyway?  For that matter, what defines the “launch”?  It’s likely to be a long, slow, incremental start, with lots of hype announcements and limited availability at first and so on.

At this point, we don’t even know what it will actually be, or what you will be able to do with it.  And we certainly don’t know just how “legal” it will be.

File this under, “What fools these mortals be!”

---

1. William Foxley (2019) Now Traders Can Make Bets on When Facebook’s Libra Will Launch. Coindesk, https://www.coindesk.com/now-traders-can-make-bets-on-when-facebooks-libra-will-launch