Why Taproot isn't catching on

Hey everyone So, Taproot, which rolled out in November 2021, is probably one of the biggest upgrades to Bitcoin since Segwit dropped in 2017. It brought us Schnorr Signatures, which is pretty cool. Now, Taproot is supposed to make transactions cheaper and boost privacy by allowing complex transaction formats like multisig and lightning channels to look like regular single-signature ones. But let’s be real, adoption has been pretty sluggish. Even now, a lot of big exchanges are still defaulting to Segwit or even Legacy for withdrawals. I think it’s because these exchanges and custodians need to completely overhaul their wallet systems to integrate Taproot. Plus, they might be worried about switching up a system that's been working fine for years. And honestly, until most wallet users are on board with Taproot, making it the go-to option for sending might get pushed back even more. Those are just my thoughts on the slow uptake. Is there anything big that could speed up adoption? Or is it even that important since Segwit still works well?

Many major exchanges are using legacy and some exchanges are using nested segwit. Nested segwit is not segwit. Most wallets make segwit version 0 the default, the reason most people are using it. Segwit version 0 still have lower fee but if it is about consolidation, taproot (segwit version 1) has the lowest fee as the input is getting more. For transactions with the same input and output or with more output, segwit version 0 has the lowest fee. The reason most wallets have segwit version 0 as default. I have not seen this on any wallet despite that it is possible, I do not think it has been implemented.

The Schnorr Signature was under the first BIP proposal, which was the BIP340. With time, more BIPs' proposal was made, updating each feature for acceptance. From BIP340 (Schnorr signature) to BIP341 (major taproot) and BIP342 (the tapscript). Don't believe everything the internet tells you until it is proven. Taproot offers low fees, but taproot transactions can still be traced easily by a true Bitcoiner. Read about the BIPs proposal from 340 to 342, and you will understand it better - https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki?utm_

From what I’ve noticed, the slow pace with Taproot mostly comes down to how much backend work exchanges would need to redo. It’s really not as simple as "enable Taproot”. They will have to adjust parts of their key-management systems, signing setups and a bunch of security routines they’ve relied on for years. Most big platforms avoid touching those unless there’s a strong reason and since SegWit already works smoothly for most people, there isn’t much pressure on them to rush anything. I honestly think Taproot adoption will pick up naturally once more wallets, libraries and multisig tools make Taproot support easier by default.

It depends. Spending from Taproot may be cheaper, but sending to Taproot is more expensive. Yes, for example the default address type is still Segwit, even in Bitcoin Core 30.0. Well, from the total on-chain data consumption, spent-by-keys Taproot addresses take less space, because 160-bit hashes are not needed. However, because 160-bit hashes are smaller, sending to Taproot is more expensive, so if someone is sending coins to a lot of recipients, then there is less incentive to adopt Taproot, as long as RIPEMD-160 is safe.

Not really, here's a chart that tracks Taproot spending: https://mainnet.observer/charts/transactions-spending-taproot/ Yes - Major exchanges that don't support sending to Taproot addresses is the main blocker. Complain to Binance & Crypto.com LND has offered private Taproot channels for awhile, and Phoenix Wallet is now fully Taproot.

Is taproot important? Not in any functional way. Although, in terms of adoption, many thousands of NFT users abused exploits introduced by taproot soft forks to pump useless data like images into bitcoin. The so called ordinals and inscriptions had a huge impact on the bitcoin Blockchain. So although very far from the envisioned use, taproot did receive a lot of use just because it introduced these colours that wouldn't have let BTC to otherwise support this ridiculous NFT tulip mania.

This doesn't make any sense, how do you explain inscriptions on Dogecoin even though they never activated Taproot or Segwit?

FWIW only some use case benefit from Taproot (see my reply below for some example). It's obvious you either don't know or forget Taproot have some actual advantage such as 1. Schnorr signature which reduce signature size if the address require N-of-M signature for spending. 2. Tapscript let you spend without reveal whole script, which reduce TX size and minor privacy improvement. Should i also mention that it'll improve LN efficiency, where LN (on Bitcoin network) eventually will move from HTLC to PTLC?

Let me be very specific about what I meant, are there wallets that are supporting the multisig taproot? This is the area that is also about privacy about taproot and also it will significantly reduce transaction fee as it will aggregate keys and signatures in a single ones, making the transaction fee very cheap. Singlesig taproot is BIP86. What about multisig taproot, which BIP is the derivational path proposed?

Lightning is multsig, so yes. The script doesn't even need to be executed for cooperative closes since Musig2 allows cosigners to spend with the Taproot public key instead.

Not many but there is at least one namely Nunchuk which I know. As explained in BitBox blog, multisignature schemes on Taproot can be implemented using either MuSig2 or FROST, but developers aren’t in a hurry to support them. A few months ago I contacted Passport Core developers to ask when they would add support for MuSig2. They promised it would be “soon,” but that “soon” still hasn’t happened.

Well I have an analogy on why it's this way. Even if SEGWIT and taproot are better and more popular these days exchanges are still using legacy addresses because the downsides especially fee wise have been drastically reduced because more people are using SEGWIT and taproot. Back in 2018 it would be a major hassle compared to now that we have a higher percentage of segwit and taproot generally reducing the fee problem. Let's not also forget most big exchanges have their pools which contribute a lot to reduce fees they spend and speed up confirmation. If not for the backward compatibility of the upgrade they would all be forced to switch but that would defy the essence of decentralization in my opinion.

I think the title is a bit clickbait, but after reading the content, I see you have an expectations bias. It's a direct comparison with SegWit, and it's unfair. SegWit was adopted quickly simply because it solved "urgent" problems at the time, while Taproot's improvements aren't as urgent; they're designed for the future. So you're measuring both by the same standard and assuming that one adoption is a failure (I say this because of the thread title) simply because it's slower. I still don't think its adoption needs to be accelerated any further. We should let it run its course in terms of implementation improvements. Its "slowness" isn't a flaw, but rather a reflection of Bitcoin functioning well and not having any urgent crises to resolve.

Exactly. Segwit was in simple terms, pretty much "use this new kind of address hash, and add a witness stack to the end of the transaction". Very little dev work was required to use this new feature. And fee savings were enormous. Whereas with Taproot not only must you implement a hardened Schnorr signing algorithm, but also a slightly different address encoding bech32p. To say nothing about any optional features you may want such as branch spending conditions or address batch signing.

The total cost is still lower, but its divided differently-- more on the transaction that creates the txout.  Which probably has good incentives for the system (favors consolidating outputs vs creating them)-- and the cost has to go up in any case because the 160 bit hash only has 80 bits of security against some kinds of attack  which is no longer considered adequate (I mean like bitcoin POW has done ~2^96 work).  You basically need to be a cryptographer to really know if the 2^80 work attacks on 160-bit addresses mater to you, so best to provide that security to everyone by default. The only reason that this comparison works at all is because p2sh embedded segwit was created as a backwards compatibility mechanism to avoid immediately needing new address types in order to benefit from the capacity increase.  The p2sh embedded outputs though use a fair amount of extra on-chain capacity in total, since they have to encode all the same things the taproot payment does plus another 20 bytes. Of course as soon as someone does anything with script-- like even just multisig the resource savings are even more considerable. I haven't heard any concern from exchanges that the 12 bytes of extra scriptpubkey was a reason for lack of deployment-- every time I've spoken to an engineer at an exchange without pay to taproot support the story has always been the same: their efforts are almost entirely directed to shitcoin support which is both a growth area and a constant source of problems. ... while their bitcoin integration just works so they're not giving it much attention.  This should be particularly true now since prevailing feerates have been fairly low. When I'd originally proposed the ideas in taproot I'd expected it to come with cross input signature aggregation which would have provided a significant deployment incentive, particularly for large players who can batch multiple payments.  But the community decided to cut back on the proposal to get something which could be deployed quicker.