Two Worrying Crypto Upgrades
Bitcoin (BTC) and monero (XMR) are the two most important cryptocurrencies at the moment. They are important for opposite reasons. Bitcoin is probably our last chance at freedom-money escaping a niche; monero is probably our last chance at freedom-money keeping a niche. Needless to say, I want both cryptos to do well. I’m worried about them. Putforth upgrades will have damaging outcomes in my opinion.
Let me outline how.
The two upgrades
Bitcoin and the Covenant Upgrade
This is called the ‘BIP-119’ or ‘OP_CHECKTEMPLATEVERIFY’ upgrade.
It allows bitcoin (BTC) to do something called ‘covenants’. A covenant is an all-or-nothing set of conditions on a transaction. Unless every condition is met to a tee, the transaction does not go through.
How would covenants work on bitcoin (BTC)? Let’s imagine an analogy with cheques. In this hypothetical world, there are only bearer, negotiable cheques. Whoever holds the cheque can cash it in.
- Alice wants to give Bert a cheque for $500.
- She wants Bert to put it in his savings account.
- Alice puts Bert’s savings account number and his full name through a computer-hashing program, which spits out a unique digital ID.
- Alice stamps this digital ID, or ‘hash’, on the back of the cheque with indelible ink.1
- Bert tries to cash the cheque at the local liquor shop.
- The shop owner computes his own name and bank account, and it doesn’t match the digital ID on the cheque.
- The shop owner hands back the cheque to Bert.
See how it’s a covenant? The payor has locked the payee into a next-step.
Wait! Isn’t the cheque a negotiable, bearer asset? Why does some text on the back of the cheque matter? Herein lies a big briar patch for covenants. How are they enforced? Fans of OP_CHECKTEMPLATEVERIFY say that this protocol has the best enforcement. It bakes it into the cake, so to speak.
Monero and the Payor-Privacy Upgrade
This is called the ‘Full Chain Membership Proof’ upgrade, or FCMP++.
Monero (XMR) has more fiddly tech than bitcoin (BTC) because it builds in a lot of privacy. Monero makes all transactions on the public transaction log (i.e. the blockchain) anonymous. We can see that a transaction happened, but the sender and recipient are just numbers. I mean, they are untied to any other number.2 The underlying tech for the privacy of senders is different from that of the privacy of recipients. This is crucial, because FCMP++ deals with sender-privacy.
Currently, when sending monero (XMR), folk are anonymized with decoys. When you send monero, you put your real monero with fifteen other chunks of monero from the monero transaction log. Those fifteen others are the decoys. Imagine sixteen people in a private room with a locked box. They are courtiers, and, in the box, one courtier must put a criticism of the tyrannical king. Each courtier has one key and any key can unlock the box. Hence, the king knows that one courtier did the criticism, but not which one.
This works okay, but not great. Modern snooping techniques have gotten so good that they can narrow down the decoys to about four.
The upgrade does away with the decoys. Instead, one does some fancy math. The sender proves that his or her about-to-be-sent monero is one of the millions of recorded monero transactions— but not which one of course.
This fancy math is not a piece of cake. It takes some serious CPU power. It’s doable. At least with non-ancient phones.
Because you need to prove that you’re one of all transactions, you need to be 100% up-to-date. You may not act like a worker on a Friday afternoon giving her inbox the cold shoulder. Your app needs to spring to action the millisecond a new batch of transactions comes in.
The status of each
- Bitcoin’s upgrade is just a draft; far from a done deal.
- Monero’s upgrade is almost ready for primetime.
- I’d rate the chances of bitcoin’s upgrade at 50%, and the chances of monero’s upgrade at 95%.
My worry about Bitcoin's upgrade
I’m hardly original here.
My worry is that this kind of upgrade is the thin end of the wedge. It makes bitcoin ‘cunning bastard money’. Bitcoin would be programmable in a way that could be used for social engineering.
I imagine the following situations arising:
- Exchanges will be forced by law to make a covenant on BTC withdrawals, so that the BTC must be sent next to a tax registrar.
- Unwitting merchants will be rug-pulled.3
- Drug dealers will use covenants with their mules and a dumbed-down version of this story will be used to smear bitcoin in the media.
Give me dumb money, please! Physical cash is still the benchmark. Call me old-fashioned...
Interesting tangent
Satoshi Nakamoto and Gavin Andresen mooted this very issue. Andresen pointed out that every extra script code adds complexity, and complexity is the enemy of security. You may look up Satoshi’s reply yourself; I don’t have time here.
My worry about Monero’s upgrade
I can’t see how this won’t lead to a compatibility list.
Remember that FCMP++ needs a 100% up-to-date and accurate snapshot of the transaction log. Murphy’s Law states that just when your app has finished the calculation of a payment to your grumpy neighbor, the last few blocks will be swapped out, rendering your calculation invalid. At this point, your app will need to fail gracefully.
Failing gracefully is not easy to code.
It’s an art as well as a science. Failing ungracefully looks like your app locking up and you spending the next two hours resynking the whole database.
Risky, but this isn’t my worry. I have faith that the leading monero devs will work out a ‘graceful fail’. I don’t have faith in just any old dev. Nor do I have faith that old devices will be up to snuff in less than ideal circumstances. Enter: a compatibility list. Just like Linux’s device drivers in the noughties, there will need to be a list of tried-and-tested hardware-software combos. This is my worry. A compatibility list opens up a can of worms:
- Will the list be official?
- Will it be updated by volunteers?
- Will it be reliable?
- What if someone ignores the list?
- Will the list go further and become some kind of de facto warranty?
- How much centralization is okay?
The problem is not just this can of worms, but that this can of worms would be at the core of monero’s mass adoption.
“Can I buy this buritto?”
“Sure. Download this app first, but you’ll need to check your phone’s compatibility on the Official Compatibility List.”
Solutions
- For bitcoin (BTC), I would do covenants on the BitVM network. Another option would be Bitcoin PIPES, but I have only scratched the surface of this idea, so can't put any weight behind it.
- For monero (XMR), I would boost the number of decoys to 32. It’s simple; it works. If, at best, the effective decoys sum to eight, that’s still enough plausible deniability. I would also set a minimum fee for all transactions. Moneristoj4 don’t take heed that the snoops’ winning hangs on low fees plus slow user-adoption.5 Even with low fees, honest actors can play the snoops’ game and flood the zone with more decoys.
- Why the digital ID? A hash is used because it is a tiny piece of data. It’s very efficient. It’s also unambiguous. (Return)
- Strictly speaking, they are tied with math. The owner of the XMR in the transaction can prove that he or she has the only private key which can make a predetermined math equation work. (Return)
- Fans of OP_CHECKTEMPLATEVERIFY say that the addresses will be different, and the apps will have built-in warnings. I still think that this adds in an attack-vector which is not worth it. (Return)
- From the Esperanto for ‘money-user’. Singular = Moneristo. Plural = Moneristoj, pronounced ‘mon-air-RISS-toy’. The term is not used much, but I think it’s a nice touch to keep up the Esperanto theme. (Return)
- Beating decoys banks on flooding the blockchain with covert, spook transactions. This in turn hinges on a roughly even ratio of ‘fake’ to real transactions. This is the contamination problem. To a lesser extent, it hangs on the believability of the fake transactions, the so-called Gamma-distributed decoy selection. (Return)