Category Archives: Bitcoin

Bitcoin Engineering Blues: SegWit Languishes

One of the most distinctive features of Nakamotoan cryptocurrencies is the “governance” mechanism.  The so-called “consensus” process is modelled after open source software projects, allowing code to fork into alternative, often inconsistent and incompatible, versions. Users are free to choose which alternative version to use, and when to transition from old to new versions.  For that matter, users are free to ignore bug fixes or other changes, and, if necessary, create their own “fork”.

The patriarch of the dysfunctional Nakamotoan cryptocurrency family uses this procedure.  Changes to the core Bitcoin code are released, and users (developers) pick them up or not, as they see fit.  In many cases, the changes are backward compatible, which means that you can still operate using the old code even if you don’t implement or turn on the new code. (In other cases, it may be possible to run multiple versions of the code, though that gets tricky if it means multiple inconsistent blockchains.)

As any software engineer will tell you, this approach is highly problematic.  Users/programmers/managers generally don’t want to spend effort updating code, even if it is necessary to do so.  And some changes may have negative effects for some users, so there is motivation to reject changes that damage your business.

In short, if you wait for everyone to voluntarily upgrade, you may wait a long time. A very long time.  For example, the upgrade from IPV4 to IPV6 (generally agreed to be critical to the survival of the whole Internet) has been in progress for decades, and still is not even close to completed.

This is not an abstract problem for Bitcoin.  After much hoohaw and software development, upgrades intended to help scale up Bitcoins performance (SegWit) were released in early 2018.  After than, developers and operators must pick up the new code and turn it on.

As Christine Kim reports for Coindesk that, one year down the road, less than 50% of Bitcoin nodes have upgraded [1].

Whatever you think of this particular upgrade (it looks like a bag-on-the-side to me), it certainly does little good if no one uses it.  So, what is going on?

For one thing, the changes aren’t generally visible to end users (or investors), so it is easy to put it off. For another thing, there is a lot of code out there than needs to change to adopt SegWit, and there are higher priorities for programmers and funders.  (It doesn’t help any that the changes seem to be really complicated compared to the purpose.  And the release actually contains several unrelated changes, in an all-or-nothing package.)

There are people who strongly oppose aspects of the changes on philosophical grounds.  For instance, it introduces some kinds of “malleability” to transactions, which is anathema to fundamentalist Nakamotoans.  Some operators have sought to ignore transactions that use the new protocol – effectively splitting the network on ideological ground.  Survivable, but hardly an ideal situation.

In true Nakamotoan fashion, the upgrade contains financial incentives, intended to entice adoption.  However, it appears that the overall economics isn’t compelling, at least not yet.

And, of course, there are a variety of competing upgrades and variations on the theme. If one SegWit upgrade is good, then multiple alternative upgrades must be better, right?   If you expect me to explain all these permutations, you’ll be waiting a long time.  I haven’t a clue.  And neither do a lot of other people.

Overall, the situation is chaotic and unpredictable.  Will this benighted upgrade ever be completed?  What about other upgrades in the pipeline?  How much chaos can Bitcoin stand?  I mean, at some point things get so fragmented that it is difficult to even define what “Bitcoin” is or is not.

I’m not sure why anyone thinks this is a reasonable governance model for software engineering.  Decentralization has its merits I suppose, but Nakamotoan “consensus” is a terrible way to make decisions about software, especially software that is in use, and in use primarily for financial transactions.

Bear in mind that Bitcoin is the oldest, most used, and probably the best engineered of all the cryptocurrencies!  Many Nakamotoan cryptocurrencies have the same hopeless governance model.  This is not how you want the financial infrastructure of the world economy to be maintained.

This sort of thing is why Bitcoin is a perennial on the short list for Crypto Tulip of the Year.

  1. Christine Kim (2019) One Year Later, What’s Holding Back SegWit Adoption on Bitcoin? Coindesk,


Cryptocurrency Thursday

The CryptoTtulip of the Year 2018

It’s time to announce the winner of this year’s Crypto Tulip Of The Year.  <<Fanfare, please!>>

Throughout the year, a number of candidates have been mentioned.  Everyone can’t win, and it was not an easy task for the judges (well, for me) to pick just one winner.

And finally, we published for the first time an explanation of “What It Takes” to win (?) the Crypto Tulip Of The Year award.

Hint: The award recognizes the combination of Irrational Exuberance, legal and technical disaster, and Orwellian linguistics that is contemporary Cryptocurrency and Blockchain culture.

OK, Calll it Already!

Let’s get down to it.

The envelopes please!

[See the announcement here]

Cryptocurrency Thursday


David Chaum on Blockchain

This fall Nick Paumgarten reported in The New Yorker on the Blockchain Week in NYC [3], including some interesting personal impressions of the Ethereum leadership, from Buerin to Zamphir.  It is nice to read some disinterested observations on this activity—Paumgarten is no enthusiast, nor is he a blind luddite.

Having closely followed cryptomania for many years, I can’t say I was especially surprised by his reports.  If anything, I was worried because he saw things that confirmed what I suspected but hoped were not true. The Emperor’s new clothes really are pretty threadbare.

But the best part of the article was his quote from Sensei David Chaim (who really did invent much of the technology back in the 80’s [1]).

“There’s never been, in the history of civilization, this much money aggregating as a result of doing nothing”  ([3], p. 75)


I’m not sure whether Paumgarten understood the depth of the dig in that remark.  He cites it in the context of all the non-progress and non-success of the crypto movement.

But it’s actually a wonderfully sophisticated techno-dig.

As I have said in the past, Nakamotoan cryptocurrency drives me mad because I was (and still am, I guess) a professional software engineer.  My entire career has been, to a first approximation, all about making software go faster.  Most of what I know is all about ways to speed things up, not least by avoiding unnecessary computational work.  (The fastest code is the code that doesn’t run at all.)

Nakamoto’s innovation (and the important thing he added to Chaum’s pioneering work) is the “proof of work” mechanism, which provides a difficult to cheat distributed substitute for a timestamp.  The classic version, used in the grand patriarch Bitcoin, is a scratch-off lottery, computing a cryptographic hash function over and over until a winning ticket comes up.  The whole idea is to use up so much computing power that it is practically impossible to short cut to the answer.  (This makes the answer “trustworthy”, because the computation can’t be redone or faked.)

So, the entire Nakamotoan project is based on an algorithm that is, by design, as inefficient as needed.  In fact, if and when we get better at computing this nonsense hash, there is a ‘knob’ on the protocol that is adjusted to make the computation slow down, to preserve the level of inefficiency.

This is so backwards and upside down.  It breaks my old-fashioned software engineers brain!  Everything I know how to do is wrong!

(Note: I understand the logic of Nakamotoan proof of work, which really is a clever, if unsustainable innovation.  I’m not saying it is wrong, just that it is backwards from 99% of software algorithms.)

So, to me, Chaum’s zinger is really on target.  The core innovation underlying all the crypto enthusiasm is this proof-of-work, which is “doing nothing”, at least nothing useful.

As he says, there is a lot of money being thrown at this doing “nothing”.  (And by the way, we starving academics can’t help but be irritated that we get so little funding for a lot of important “somethings” that we are trying to do.)

(By the way, the same issue of The New Yorker has a great piece by Charles Duhigg about the Google/Waymo dustup [2].)

  1. David L. Chaum, Untraceable Electronic Mail, Return Addresses, and Digital Pseudonyms. Communications of the ACM, 24 (2):84-88, 1981.
  2. Charles Duhigg, Stop, Thief! When Google Sues To Keep Its Secrets, in The New Yorker. 2018, Conde Nast: New York. p. 50-61.
  3. Nick Paumgarten, The Stuff That Dreams Are Made Of: Cryptocurrency’s Priests Envision A New Society, in The New Yorker. 2018, Conde Nast: New York. p. 62-75.


Cryptocurrency Thursday

CryptoTulip 2018: Bitcoin vs Ethereum

The heavyweights are battling it out for the CryptoTulip 2018 award!

Defending CryptoTulip Award winner Ethereum has thrashed all year on basic governance and scaling issues, with no resolution in sight.  Ehthereum is also the platform of choice for other notable CryptoTulip contenders, including EOS, FOAM, and the plethora of ICOs.  (Ethereum:  the Tulip that other Tulips grow on!)

But the grand patriarch of the Nakamotoan family, Bitcoin, is not to be denied.  With a stunningly non-Nakamotoan bug fix (at least we hope the bug is really fixed!), and the neverending scaling debates, Bitcoin has done its own thrashing.  (And, by the way, the bug in Bitcoin has been copied into any number of other “coins”, so it affects a whole extended family of cryptocurrencies. )  (Bitcoiin: the Tulip from which all other Tulips are descended!)

This month we see further action from both these contenders for the non-coveted CryptoTulip of the Year Award.

This month, a cunning plan was floated to help Bitcoin scale.  It is now clear that this great idea is not only not strictly Nakamotoan, it also relies on a wrinkle in the consensus protocol that many consider to be a bug [2].    Yessiree, let’s turn a bug into a feature!

Astonishing enough, many people want to fix the bug (which would kill the scaling concept), and many people want to keep the ‘bug’ (and use it to improve the network).  It also seems that the Bitcoin code has grown complex enough that it isn’t even easy to plug this hole in the protocol if you wanted to, at least not without a side effect of splitting the network.  (I don’t understand the details of these fixes, I’m relying on second hand info.)

A tough choice—valid data, or scaling up the network.  Bitcoin is certainly contending for the CryptoTulip Award this year.

Of course, Ethereum continues to thrash along on its own path.  The long awaited, much debated “Constantinople” upgrade—way overdue, still contested, and somewhat trimmed down—is entering live testing.

Or, it would be, if only people would do the tests.  At this stage, the proposed new version was booted on a test network, but “stalled”, not processing more data.  It is reported that there aren’t enough miners who are running the code.

However, the testing did succeed in revealing a serious bug “which caused two different iterations of the same software upgrade to run on testnet.  I don’t really understand this problem, but it doesn’t sound ready for release, to me. But what do I know?

This test run doesn’t bode well for the November release date.  Enthusiasm seems to be low, quality seems iffy.  So just when, if ever, will this upgrade really happen?

Update 20 October 2018:  The release has been pushed back to January 2019 or later.

With this disaster, Ethereum certainly might repeat as CryptoTulip of the Year this year.  We’ll see what happens.

Both these contenders are showing that the software is buggy and the maintenance process unworkable.  Plus, significant fractions of the “community” don’t even want the upgrades to happen at all.

This is a technical and governance horror show, and it is not the universe Nakamoto envisioned!

But we all still believe, really believe, in our CryptoTulips!

That’s the essence of CryptoTulip Mania, isn’t it?

  1. Alyssa Hertig (2018) ‘Bitcoin Bug’ Exploited on Crypto Fork as Attacker Prints 235 Million Pigeoncoins. Coinbase,
  2. Alyssa Hertig (2018) Not Everyone Wants to Fix Bitcoin’s ‘Time Warp Attack’ – Here’s Why. Coindesk,
  3. Christine Kim (2018) Ethereum’s Next Blockchain Upgrade Faces Delay After Testing Failure. Coindesk,


Cryptocurrecy Thuraday

Big Bitcoin Bug

As the competition for CryptoTulip of the year contest enters the final stretch, we now hear from the arch, patriarch of all Tulips:  Bitcoin.

This month we learned that there was a huge, massive, bug in the oldest, stablest, “most secure” cryptocurrency of them all, Bitcoin   (There are also an unknown number of copycats who use code from the Bitcoin source base, so the bugs may affect other systems, too.)

Actually, there were two bugs, one a possible denial of service attack, and another that could allow double spending.  Nothing major, just a potential for a crippling shutdown and/or counterfeit coinage!  The bugs were accidentally introduced two years ago!


The bugs themselves aren’t especially notable. All software has bugs.  Bitcoin is software.  Ergo, Bitcoin has bugs.

The interesting and Tulip-y thing is how it was handled.

Notably the “open source”, “transparent” development team took it upon themselves to keep quiet about most serious part of the problem until there was a patc [1].  This is, of course, perfectly standard and reasonable behavior for proprietary code.  The developers took responsibility for the welfare of the code and its users, and tried to get the patch out before the details of the flaw were explained to potential attackers.

This is a sensible process, but it is not exactly a Nakamotoan process.  Bearing in mind that many enthusiasts advocate the principle that “the code is the law”, which means that, for a while, it was perfectly proper, even “intended” that people might be able to ravage Bitcoin through these loopholes in “the law”.  And the unelected developers in fact took it upon themselves, without consultation or notice, to change “the law” to preclude these highly profitable moves.

Naturally, this being cryptoland, the unannounced bug was, in fact, soon unofficially leaked by non-cooperative folks. (Thanks for helping, guys.) And even according the official announcement, only half the affected systems had been patched so far- probably.  The bug notice itself essentially begs people to update with the bug fix. And no one can do more.

Apparently, many Bitcoinistas believed their own propaganda about how ‘secure’ this stuff is, and about how invincible ‘open source’ code is.  So some people were “shocked” by this bug. [2]   In response, there have been naïve calls for more and better testing, as if any software ever has enough and good enough testing.  (And, by the way, decentralized, asynchronous, network protocols are really, really hard to test.)

There have also been calls for multiple implementations, which is a good idea until it isn’t a good idea.

As Alyssa Hertig reports, “developers don’t necessarily agree on exactly what needs to be done.”

At this point, we might ask, “Is this bug really patched?”  Who knows?

At this time we believe over half of the Bitcoin hashrate has upgraded to patched nodes. We are unaware of any attempts to exploit this vulnerability.” (from [1])

Not exactly a ringing assurance.

This episode shows just how vulnerable this technology really is.  There can and surely will be huge bugs, but they can be patched only through the indirect and voluntary cooperation of many anonymous operators.  And, as we have seen with Ethereum and the DAO, a bug can be exploited in seconds, but may take years to fix.

The CryptoTulip award will surely have to consider this episode.

Bitcoin was lucky this time (as far as we know).  With billions on the line, it’s only a matter of time before this CryptoTulip explodes.

  1. BitcoinCORE, CVE-2018-17144 Full Disclosure.  Bitcoin Core Notice, 2018.
  2. Alyssa Hertig (2018) In Wake of ‘Major Failure,’ Bitcoin Code Review Comes Under Scrutiny. Coindesk,
  3. Alyssa Hertig (2018) The Latest Bitcoin Bug Was So Bad, Developers Kept Its Full Details a Secret. Coindesk,


Cryptocurreny Thursday

Tracking Bitcoins, Mitigating Evil

Bitcoin was designed to be difficult to regulate, in the same way that gold is difficult to regulate. Possession (of a private key) is ten-tenths of the law as far as Bitcoin is concerned, and it can be very difficult to tell exactly how a particular Bitcoin came to be possessed by a particular individual.

This relative opacity is one of the properties that makes Bitcoin and other cryptocurrencies so attractive for criminals, extortionists, tax evaders, and dark markets.

From the point of view of believing Nakamotoans,  untraceability is a feature.

From the point of view of the law and society in general,  opacity is often considered a bug. Civil society in general has little appetite for unregulated financial systems, so Bitcoin will never succeed unless it can be brought into civil society and the rule of law.

This month researchers at Cambridge University describe how an old legal principle might be applied to Nakamotoan cryptocurrency to rein in abuses and “make Bitcoin legal” [1].

The researchers point out that many Internet technologies have been put forward as “outside the law”, but this is an assertion not a fact.  The fact is that “the law” decides what the law is and how it is applied.  No one gets to simply secede from the legal system, at least not without resort to pure power politics.

“we have repeatedly seen a pattern whereby the promoter of an online platform claims that old laws will not apply.”

“The key is making online challengers obey the law – and the laws may not need to change much, or even at all.”

In the case of Bitcoin, the researchers explore how conventional financial controls, especially anti money laundering rules, could be applied to Nakamotoan cryptocurrency.  They conclude that it is surprisingly straight forward and does not require changes to the network protocols.  I.e., the legal system can adapt to cryptocurrencies as they stand now, without any cooperation or consent from programmers or users.

There is a common legal principle that one may not profit from the fruits of crime.  Similarly, you cannot receive goods from someone who does not legitimately own them.  If someone gives you a stolen coin, it must be returned to the original owner (and you may well be out of luck).  Thus, it is very important not to trade in ill-gotten goods.

It is often the case that the monetary fruits of crime are passed along mixed in with other money.  In the case of Bitcoins, this kind of mixing occurs rapidly and across the whole Internet.  This presents a dilemma for the law.  The funds are “partly” stolen, but which part can be confiscated?

The Cambridge team discusses the history of this problem.

Theft and misuse of Bitcoins are a significant issue, to the point that even most Bitcoin users are concerned.  If there is a significant risk that your assets may be stolen (or misplaced), with no possible recourse, then cryptocurrency is unattractive for many uses.

Philosophically, Nakamotoans generally do not want government guarantees (e.g., registration of ownership) or other conventional mechanisms for protecting assets.  An alternative would be for courts to enforce rules, e.g., to allow recovery of stolen or extorted Bitcoins.  But how would courts adjudicate such a case?

In the past, the general legal approach has been to consider the funds “poisoned” by the presence of illegal money.  Someone who holds the funds will have to pay a penalty proportional to the illegal funds.  This stands as a deterrent to dealing in potentially “toxic” assets.

One way to do this is to consider all the money to be N% illegitimate, i.e., to confiscate part of the value of the whole batch.  This approach can be used with Bitcoin, though it is a blunt instrument.  Anderson et al. indicate that a very large proportion of Bitcoins would be touched by such “pollution” (5% in one sample–one in every twenty!)

They propose an alternative mechanism that echoes an approach used in nineteenth century English law:  First-in-first-out.   The idea is to trace the flow of coins and to assign an order to each transaction.  The first coin taken out of an account is equated to the first coin put in, and so on.  When a stolen coin is spent, that transaction is identified and the payment is illegal.  This is a sort of “reverse lottery” – an unlucky user ends up losing.

This approach is much more precise way to identify and deter accepting ill gotten money.  The paper argues that this is quite possible with Bitcoin, using the public blockchain and crime reports.  Furthermore, the FIFO principle works even when “mixers” are used to conceal the origins of the Bitcoins.  In the end, when this legal doctrine is applied, accepting Bitcoins from a mixer risks losing the entire payment in the unpredictable event that you receive coins designated “poison”.

This approach isn’t “centralized”, and it doesn’t break Bitcoin.  It doesn’t even change Bitcoin. It just wraps Bitcoin in a legal framework.  Honest users would have a way to behave honestly (use honest exchanges), crime could be punished, and the system functions as efficiently or inefficiently as now.

“In short, we might be able to turn a rather dangerous system into a much safer one – simply by taking some information that is already public (the blockchain) and publishing it in a more accessible format (the taintchain). Is that not remarkable? “

It is difficult to overstate how important it is for Bitcoin and other cryptocurrencies to get “legal”.  Whatever the technical merits of Nakamotoan technology, it cannot succeed outside the law.

  1. Ross Anderson, Ilia Shumailov, and Mansoor Ahmed, Making Bitcoin Legal. Cambirdge University, Cambirdge, 2018.
  2. Andy Greenberg (2018) A 200-Year-Old Idea Offers a New Way to Trace Stolen Bitcoins.,



Cryptocurrency Thursday

Detailed Study of Ransomware

It is widely known that Bitcoin has become a favorite tool for ransomware. It is easy enough for victims to deliver, can be swiftly “disappeared”, and is readily convertible into other currencies.

Everyone knows what ransomware looks like to the victim.  But what happens to the ransom after it is paid?  And how much extortion is going on?

This spring researchers from several US Universities and Google report a study tracing ransomware payments through the Bitcoin blockchain [1].  The study examined more than 19,000 cases over a two year period, tracing the Bitcoin from acquisition (by victims) to cash out (often in the now seized BTC-E exchange).

While Bitcoin has many attractive properties for illicit commerce, it also has the interesting property that the ledger is completely public.  Ironically, this makes it possible to study illicit transactions in considerable detail, compared to other methods of extortion and covert payments.

This study used a variety of techniques to suss out the end-to-end activity of ransomware.  For the first step, known victims reveal some of the payment addresses, and sandboxed “synthetic victims” provided additional addresses.  The study also statistically clustered addresses to identify other likely but unacknowledged ransomware payments.  In addition, making micropayments by the “synthetic victims” made it possible to trace addresses that are associated with the scheme in question.

The researchers also searched for bursts of payments associated with known ransomware attacks.  In fact, they constructed a timeline of ransomware events and payments.  (This ideas is so obvious, I’m surprised there isn’t one already on the web.)  This chart makes clear that there are likely large gaps in the data.

The researchers also looked for patterns such as many identical payments to the same address which could indicate ransom payments from multiple victims.  They also identified patterns such as known ransom payments that were quickly emptied into a common address.  Other addresses that paid to that same address probably represent other victim payments.

The study also documents where victims purchased Bitcoin. In this (incomplete) dataset, over $16M was identified.  Much of the activity identified was in Korea, i.e., the victims were Korean.

The payments typically are transferred to a output address, often into a mixer that will obscure the origins and destinations of further transactions.  It is difficult to trace the cash outs in many cases, though the study showed the Bitcoins being passed on after a few days (or, in the case of WannaCry, after many weeks).  For those cases that can be identified, several major exchanges were used, presumably to exchange for other currencies (“cash out”).  BTC-E was the top choice. (BTC-E has since been seized by the FBI, presumably for its nefarious activities.)

Analysis of the behavior of the infection software documented that it takes ten minutes or less for the ransomware to encrypt the victim’s files.  This is the window in which defensive measures might be possible, if an attack is detected as it begins.

The researchers comment on some tricky ethical challenges in this work.

Some ransomware posts the payment address on a web page, and when the victim visits the page, a counter starts.  This design means that examining these URLs could potentially harm victims, e.g., by starting the count down without their knowledge.

They point out that even this incomplete analysis would enable them to disrupt or possibly take down parts of the payment infrastructure.  This might deter attacks, but it would prevent victims from regaining their files, which would be harmful.

In many ways, this study is a confirmation of what is widely believed.  I don’t think there is anything particularly surprising here, except maybe some of the details of particular ransomware.  There is some variation in the design of these programs, and some seem pretty sloppy.  That’s bad news, because they are likely to evolve to become much harder to trace or disrupt.

Overall, the amount of money involved isn’t especially large.  Millions of dollars globally, and even several million in a single place like Korea isn’t a huge deal.  Indeed, the ransoms are generally in the range of a few thousands of dollars.  This is basically in the class of a local protection racket.  (“Gimme $100 a week, or we’ll slash your tires.”)

But, like groups of local tough boys, there is probably an infinite supply of them, so the problem will not go away.

Why Bitcoin?

The paper lists features of Bitcoin that make it useful in this racket:  Bitcion is “

“decentralized, largely unregulated, and all parties in a transaction are hidden behind pseudo-anonymous identities. Moreover, all transactions are irreversible, and it is widely available for victims to purchase.”

There is one more feature of Bitcoin that is essential:  the relatively low transaction cost. Bitcoin’s transaction costs will never be as low as enthusiasts imagine, but they are as low enough to make a profit from $1,000 ransoms.

In addition, much of the ransomware technology is built from open source technology, which is cheap and ubiquitous. Besides Bitcoin, ransomware uses encryption, standard network interfaces, Web sites, and so on. This is a very successful, but scarcely innovative technology.

I’ll add one more thing.  If ransomware is a problem today for poorly maintained office software, imagine what is going to happen when it attacks the “Internet of Too Many Things”.  It won’t be your accounting database or documents, it will be your electric grid, car, or hospital equipment that is locked out.  It’s going to be really dangerous.  Doubly dangerous because IoT is generally not “owned” by the user—so who will pay the ransom, if we wanted to?

  1. Danny Yuxing Huang, Maxwell Matthaios Aliapoulios, Vector Guo Li, Luca Invernizzi, Kylie McRoberts, Elie Bursztein, Jonathan Levin, Kirill Levchenko, Alex C. Snoeren, and Damon McCoy, Tracking Ransomware End-to-end, in IEEE Symposium on Security & Privacy. 2018: San Franscisco.


Cryptocurrency Thursday