pull down to refresh

I’m seriously considering moving all of my P2WPKH stash to Taproot and making it my default going forward.

From what I understand, Taproot offers meaningfully better on-chain privacy, especially if I’m only using key-path spending. On top of that, txns are generally lighter and more fee-efficient compared to legacy or even P2WPKH.

My usage is very simple like below:

  • regular on-chain transactions (by this mean only single-sig sending and receiving sats)
  • Lightning Network

And I don’t use anything beyond that.

In an ideal setup, I would only:

  • open Taproot LN unannounced channels
  • close channels cooperatively

If that’s the case, then every on-chain transaction should appear as a single signature key-path spend. To me, that feels like a pretty strong privacy baseline.

For those who are not using Taproot yet(or decided not to), I’m genuinely curious:

Are there any real downsides or edge cases I might be missing?

not trying to evangelize, just trying to understand if there’s a solid reason not to move fully to Taproot in a setup like this.

Yes, I moved also to taproot long time ago, but I still keep one coinbase legacy address that I mined back in 2012... just as a reminder.

All the others were switched anyways into segwit when was the 2017 fork and doubled the stash.

reply
I moved also to taproot long time ago

do you also make use of script path, or sticking to key-path spends only?

reply

Depends of the use case and wallet used. I use multiple wallet apps with multiple wallet keys. All spread on the 3 levels pattern:

reply

Yeah, I’m very aware of your three-level stash, since I’ve been following your “be your own bank” guide.

That’s actually why I think going Taproot only makes sense, letting the hodl, cache, and spending wallets all look the same on-chain, at least from an external observer’s view.

reply

And yet you @DarthCoin refuse to enable sats MoE on Stacker News.

You have deliberately disabled BTC MoE on Stacker News yet claim yourself to be living on The Bitcoin Standard.

Lying arsemilking Hypocrit.

I think it's better for the majority of your stack to stay on native segwit addresses.

txns are generally lighter

Pretty sure taproot are slightly heavier.

The main concern is that taproot is vulnerable to quantum computers. Even though QC will likely target earlier address types first, i wouldn't want to be in that situation.

I don't have any issue with using taproot for spending via a LN channel. Like you mentioned there may be some privacy gains. But I'd close the channel funds back into a segwit address just to be safe.

reply
vulnerable to quantum computers

i believe everything under ECC is vulnerable to quantum computers, if that comes out publicly to the world. Do you have any reason why you think that taproot is specifically more vulnerable to Q-day?

Pretty sure taproot are slightly heavier.

Hmm.. i doubt that.. as far as key path spending wise..

comparing this taproot txn to this segwith txn which both have one input(taproot / segwit respectively) going to two segwit outputs, one with taproot input(key path spending) has txn weight of 520 WU, and the other with native segwith input has 562 WU.

reply
100 sats \ 1 reply \ @OT 28 Dec 2025

I guess I was wrong about segwit being cheaper. Thanks for the correction.

As for the risk of QC it's well known that taproot is vulnerable. I think segwit addresses are safe from long range attacks because they have another layer of hash. I don't remember off the top of my head why exactly taproot is vulnerable.

https://chaincode.com/bitcoin-post-quantum.pdf

Check this out if you have time.

reply
I think segwit addresses are safe from long range attacks because they have another layer of hash

i think i get your point. segwit wraps pubkey around two hashes, sha256 and ripemd160, whereas taproot does not but rather commits to tweaked public key with bech32m and it reveals its tweaked pubkey to scriptpubkey field directly. That may be one attack surface even to the unspent taproot output??

Thanks for the link, I’ll take a look.

reply

The first is wallet and ecosystem support. While Taproot has been active for some time now adoption among wallets exchanges and services is still not universal. If you ever need to receive funds from or send funds to a party that is not Taproot compatible you will be forced to maintain legacy addresses or accept the need for an intermediate spend which can reduce privacy and efficiency.

The second is fee dynamics over time. Taproot is generally more efficient due to smaller signatures but that advantage grows most prominently in complex spending conditions. In simple key path single sig spends the savings are modest though still worth taking.

A third point is Lightning interoperability. Taproot enabled channel funding especially for unannounced channels is a win for privacy in theory. However channel closes especially cooperative ones will indeed look like regular key path spends. The edge case to watch is the unfortunate scenario where cooperative closes cannot happen and you need to publish more complex scripts. In that case the anonymity set shrinks because most Taproot spends on chain are still key path at present so script path use stands out.

reply

Realized that taproot keypath output is no different than p2pk when it comes to quantum shor algorithm attack

reply