The Taproot adoption Failure

[casey15]

Hello Bitcointalkers

The Taproot soft fork which was introduced in November 2021 was one of the most important upgrade to Bitcoin since Segwit in 2017. This is what Introduced Schnorr Signature.

Taproot as we know offers cheaper transaction fee for users and it enhance privacy by using complex transaction firmat like multisig, lightning channels etc which are indistinguishable from simple single signature transactions.

Even with all this, you will agree with me that the adoption is rather slow. Many major exchanges still uses Segwit for default withdrawals sometime even Legacy.

I figured that the  integration of Taproot requires these exchanges and custodian to completely rework their underlying wallet infrastructure .. and sometimes it could be that they are scare of changing the system that has been proven and runs for years.
I also feel like until a large majority of wallet users support Taproot, then using it as a default sending option may be delayed further.

These are just my assumption on why the adoption has been slow over the years.  Is there any major actions that can push the adoption faster,??
 or is it even a necessity for the adoption to take place since Segwit is still very much functional and does well.??

[Charles-Tim]

Even with all this, you will agree with me that the adoption is rather slow. Many major exchanges still uses Segwit for default withdrawals sometime even Legacy.

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.

Taproot as we know offers cheaper transaction fee for users and it enhance privacy by using complex transaction firmat like multisig, lightning channels etc which are indistinguishable from simple single signature transactions.

I have not seen this on any wallet despite that it is possible, I do not think it has been implemented.

[Agbamoni]

The Taproot soft fork which was introduced in November 2021 was one of the most important upgrade to Bitcoin since Segwit in 2017. This is what Introduced Schnorr Signature.

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).

Taproot as we know offers cheaper transaction fee for users and it enhance privacy by using complex transaction firmat like multisig, lightning channels etc which are indistinguishable from simple single signature transactions.

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_

[Donneski]

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.

[stwenhao]

Taproot as we know offers cheaper transaction fee for users

It depends. Spending from Taproot may be cheaper, but sending to Taproot is more expensive.

Is there any major actions that can push the adoption faster,??

Yes, for example the default address type is still Segwit, even in Bitcoin Core 30.0.

Code:

createwallet ""
{
  "name": ""
}
getnewaddress
bc1q...

is it even a necessity for the adoption to take place since Segwit is still very much functional and does well.??

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.

[Kruw]

Even with all this, you will agree with me that the adoption is rather slow.

Not really, here's a chart that tracks Taproot spending: https://mainnet.observer/charts/transactions-spending-taproot/

Is there any major actions that can push the adoption faster,??

Yes - Major exchanges that don't support sending to Taproot addresses is the main blocker. Complain to Binance & Crypto.com

Taproot as we know offers cheaper transaction fee for users and it enhance privacy by using complex transaction firmat like multisig, lightning channels etc which are indistinguishable from simple single signature transactions.

I have not seen this on any wallet despite that it is possible, I do not think it has been implemented.

LND has offered private Taproot channels for awhile, and Phoenix Wallet is now fully Taproot.

[alani123]

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.

[Kruw]

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?

[ABCbits]

or is it even a necessity for the adoption to take place since Segwit is still very much functional and does well.??

FWIW only some use case benefit from Taproot (see my reply below for some example).

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.

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?

[Charles-Tim]

LND has offered private Taproot channels for awhile, and Phoenix Wallet is now fully Taproot.

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?

[Kruw]

Let me be very specific about what I meant, are there wallets that are supporting the multisig taproot?

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.

[satscraper]

LND has offered private Taproot channels for awhile, and Phoenix Wallet is now fully Taproot.

Let me be very specific about what I meant, are there wallets that are supporting the multisig taproot?

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.

[Mia Chloe]

~snip

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.

~snip

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.

[mcdouglasx]

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.

[NotATether]

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.

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.

[gmaxwell]

Interesting breakdown. So the cost-per-output is actually higher for the sender creating a Taproot transaction?

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.

[1440000bytes]

Should i also mention that it'll improve LN efficiency, where LN (on Bitcoin network) eventually will move from HTLC to PTLC?