Taro and Taproot—just empty carbs

Recently an article published in Bitcoin Magazine by an anonymous author (what does a tech author have to hide?) seemingly aimed to promote the new “scaling solution” proposal on the Lightning network BTC. This article was a well-crafted introduction to the Taro protocol on Lightning Network, which aims to expand the smart contracting capabilities of BTC, which has been fallow since 2012.

As is any article written by an anon, this article should be highly scrutinized, as should anything written by someone who avoids any responsibility or repercussions for being wrong or misleading. Do give the article a read, though, as once again, having both sides of the argument is crucial before we dive into why this author thinks that Taproot and Taro is nothing but an overly complicated hoodwink to get people to move over from Bitcoin to another system (Lightning) while still thinking that they are using bitcoin somehow.

Prima facie, Taro aims to allow for NFT and token issuance on top of Lightning. They do this by using a modified form of the Merkle tree to prove commitments on a UTXO or output level of granularity.

As a reminder to readers, in the base bitcoin protocol, the Merkle tree is used only at the level of the transaction so that individual transactions can be proved to be included in a block by the public with the help of a chain of block headers (blockchain) and a Merkle proof¹. With Taro, the proposal is to use an encapsulated Merkle tree, which has UTXOs as its leaves instead of a transaction. In other words, it is a Merkle tree internal to each transaction. Where a Merkle tree exists at the block level and maps a block to all its contained transactions, a transactional Merkle tree (aka Merklized Abstract Syntax Tree—MAST) on a transaction relates to all of its UTXOs. Taproot is just the fancy name for the agreed method in which this transactional Merkle tree is implemented on the transaction, and Taro is the protocol by which use of this transactional Merkle tree can be used to implement a token protocol over Lightning.

The proposal suggests using this transactional Merkle tree (MAST) to commit each outputs locking script into the transaction so that only the eventual output spent out of the set of possible outputs spendable needs to be revealed in an eventual contract ‘closing’ transaction. Coupled with committing to the sum of all the outputs allows for balance tracking of tokens created using this method.

They claim that this method is good for scalability and privacy, but we will investigate this claim more closely.

First is the claim that it is more scalable. The argument is twofold: first, that by making asset transfers through Taro on the Lightning network, allows for tokens assets to be transacted on Bitcoin “without burdening the bitcoin network with storing extra data.” Well, the notion that data storage is a scaling barrier is ill-grounded, to begin with. Miners and transaction processors will “do the needful” and ensure that they procure sufficient resources and infrastructure to support the network, as long as they are compensated sufficiently for it. As long as the ecosystem provides the transaction processors with sufficient profit incentives, they will continue to provide the service.

So scalability is directly proportional to whether or not the supply of transaction fees is sufficient to support the miners’ costs. We will see why it’s actually a problem if you base the long-term scalability and viability of the bitcoin network on increased *Lightning Network* use, simply because miners do not earn a cent of transaction fees that are done off-chain in Lightning channels! If miners don’t earn from the increased usage of the system, then they won’t be incentivized to keep on hashing and maintaining block production.

An in-depth analysis of this failure scenario of the Lightning networks model can be found in this great article here, written by a long-time blockchain economist. It basically explains how the best scenario for Lightning Network adoption will mean the end of Bitcoin security and the network itself due to miner attrition.

The second scalability claim is that it keeps the required computation at the ‘leaves’ of the computation tree. The example is that an unbounded number of tokens can be issued by a single taproot transaction, and therefore this ‘saves’ computation, perhaps by way of not needing servers to keep off-chain balances and state in the same way that Ethereum nodes need to. The argument here is that the UTXO model is more scalable than the account-based model.

This is indeed true, and leveraging the UTXO set is a better way to ensure global consensus than a model that requires computation to arrive at the latest state (balance). 

The only sidebar worth mentioning here is that BSV uses the original bitcoin scaling model and shares the same scalability, without the need for a second layer network like Lightning to ensure it is accessible by all. Additionally, use of tokens on BSV directly pays the miners the transaction fees, so there is no issue of how the transaction processors are compensated by increased consumer usage.

The privacy aspect is another misdirection. If the goal is to hide the payment conditions of any given contract, then it is arguable that no honest party would want to do that. What people really want when they talk about privacy is for transactions not to be personally identifiable to a given natural or legal person. Not necessarily whether or not the terms themselves are private. Imagine the year is 2005, and you have smart contract locked funds that had logic like the following: (let’s imagine for a second that Bitcoin was around back then)

Lock 10 BTC:

if Democrats win the next election: pay Jeffrey Epstein’s slush fund 0.5 BTC
else if Pfizer stock goes up 30%: pay Anthony Fauci support fund 1 BTC
else if year >2022 pay myself any amount

I can understand if you were supporting some potentially dubious characters, that you may not want it openly scrutable that you had locked up some funds that potentially pay them. After all, after it came out that Epstein was a child sex slave trafficker, it would be pretty embarrassing that you had associated with him and were even prepared to send him money. In a system that Taro proposes, if both Epstein and you delete your copies of the smart contract, then nobody would ever be able to know that you both had an outstanding deal or that you were besties and you flew on his private jet once a month. Good for you, bad for corruption.

The alternative model of privacy revolves around keeping the identities (Epstein, Fauci, yourself) and ownership of the public addresses mentioned in the smart contract separate. However, the conditions and payment amounts are public, just like bitcoin itself. The benefit of this alternative model is that by keeping the contract conditions and amounts scrutable and publicly transparent, we discourage corruption and encourage accountability in that although the party identities are private, IF at a later date it is discovered that Epstein was a criminal, and through the course of a police investigation, there was a court-issued warrant to investigate his connections, then law enforcement would theoretically be able to trace back who the owner of the other addresses were, and you would be discovered as an Epstein supporter. Then it would be up to you to argue or explain how you were associated with him and why. As uncomfortable as this may be for you, and even if you made this contract under the best pretenses (after all, who would have thought that the most influential guy in political circles was a sex trafficker?), it is important for transparency and anti-corruption that law enforcement is able to proceed with such investigations information comes to light. 

This is the basic honesty incentive that bitcoin employs by ensuring that offenders and rule-breakers are publicly exposable but not exposed by default. If this wasn’t the intent of Satoshi, then bitcoin would have been a totally encrypted system or employed coin mixing or advanced trace obscuring technology such as the kind used by anonymity coins like Monero or ZCash from day one.

So Taro’s proposal of hiding smart contract payment conditions in the name of privacy is a red herring. You can achieve the level of privacy if you employed technology to generate one-time use addresses and never reuse them.

But what if all of this doesn’t matter, as you are willing to accept all of these complications because you really like the idea of being able to make smart contracts on Bitcoin by only revealing the contract path that is taken. Well, then you can pretty much do the equivalent thing as Taproot on BSV in about 20 lines of code. Really makes one wonder why it has taken BTC 4 years and many protocol changes and Lightning overlay network to work. The reason it took them this long is that they refused to return to the original Bitcoin protocol, and insisted on working with a handicapped version of Bitcoin script², which makes this sort of advanced programming extremely difficult. Talk about reaching around your butt to touch your nose³!

Perhaps this is the reason why there is so much trumped-up animosity towards Craig and his company.

In the end, Taproot and Taro are like empty carbs, 99% hype, and no calories. But if it makes people feel better and superior to others around them for using it, then, by all means, load up!

/Jerry Chan

***

NOTES:

[1] A Merkle proof is nothing more than a merkle path, or a pruned tree that walks from the transaction in question, up to the Merkle root, with hashes for all other branches off the path.

[2] With the lack of the original OP_CODES in bitcoin BTC is unable to write smart contracts which put spending conditions on the outputs of a given transaction. This is why they need extra protocol changes to affect what can be done very simply in BSV. With OP_PUSH_TX pseudo-opcode in BSV, developers can write logic locking an output that can impose conditions on future outputs of the transaction, which includes it as an input.

[3] You have to either have really long arms, or you are a d*ckface.