How Taproot actually works: the tweak, both spending paths, 5 years of numbers

[windpath]

New chapter on LearnBitcoin: How Taproot Actually Works
https://www.learnbitcoin.com/rabbit-hole/how-taproot-works

For this crowd the parts worth arguing with are probably:

• The construction section: Q = P + hash(P || root) * G, why script-free outputs are still tweaked, and the control block byte by byte (33 + 32m).
• The Schnorr section, which says plainly that batch verification is not shipped in Core (libsecp256k1 PR #1134 still open), that cross-input aggregation is not in Bitcoin, and that the patent expired in February 2010 rather than the 2008 most explainers repeat.
• The activation timeline from primary data: counting from block 681,408, threshold at 687,284 on 12 June 2021, activation at 709,632, the activation block spending zero P2TR outputs, and the first spends in 709,635.
• The adoption numbers from mainnet.observer and ChainQuery's UTXO repartition: a third of UTXOs by count, 1.1 percent by value, about 5 percent of current use, 63 percent of transactions at the January 2024 inscription peak.
• The inscription section, which takes Wuille's and Poelstra's position that the envelope is valid by design and the witness discount predates Taproot by four years.

If any of the history or the numbers are off, say so and it gets fixed and credited.

[eternalgloom]

The construction section: Q = P + hash(P || root) * G, why script-free outputs are still tweaked

Many could think that no separate tweaking is required for script-less or standard single key payment.

Theoretically it is possible to proceed by assuming h(P || root) to be zero or by simply omitting  root without applying tweak. But tweaking P is mandatory to ensure security.

Without it malicious actor could trigger key collision with another Tapscript tree, thereby compromising privacy.

and the control block byte by byte (33 + 32m).

Hmm, size calculation is correct, m here stands for depth, right?
However actual catch is if this depth is too great then size of control block will shoot up abruptly.
So for complex smart contract, you would incur higher penalty for revealing Tapscript than you would with SegWit v0, do you see?
You know many developer do not take this into account during design phase.

[ABCbits]

Because a Taproot output is the public key itself, the key is exposed to a future quantum attacker from the moment the output is created, not from the moment it is spent.

The part "a Taproot output is the public key itself" is probably inaccurate, at least based on website i usually use as technical reference.

The interesting part of P2TR is that all of the custom scripts are organized into a tree. This script tree is used to create a merkle root, which is a fingerprint for all the different ways the output can be unlocked. This fingerprint (tweak) is then combined with the public key to create a tweaked public key.

This tweaked public key is what gets placed inside the locking script.

But the quantum computer risk should remain same, based on other discussion at https://bitcointalk.org/index.php?topic=5587072.msg66898524#msg66898524.

[athanred]

The part "a Taproot output is the public key itself" is probably inaccurate

It is correct, because if you know the private key to that, then you can spend it by key, without worrying about TapScript or any internal keys. If it will be blocked in the future, and if internal keys will be always required, then things may change, but in general, all P2TR addresses are currently as vulnerable, as all P2PKs are: if you know the private key, then you can move the coins. Even if you don't know the internal key, or even if it doesn't exist.

So, tweaks are highly recommended, and implemented by almost everyone. But they are not required by consensus rules. Of course, using untweaked keys is unsafe, but well, it is technically valid, at least in the current pre-quantum consensus.

Also note, that for P2PKs, you can make the internal tweaked key, too. It will have no use, because there is no TapScript under P2PK, but well, tweaking points on secp256k1 is done in exactly the same way. Anyway, all keys from HD wallets are "tweaked", just in a different way, so it is not a new Taproot-only concept, but it was known much earlier.

[windpath]

But tweaking P is mandatory to ensure security.

Small correction, and it applies to how I worded the OP too (athanred caught the same thing below). The tweak isn't actually mandatory. Nodes can't tell a tweaked key from a plain one, so an untweaked output is perfectly valid. BIP-341 just strongly recommends it.

The reason is more about theft than privacy. Say three people combine their keys into one shared key. If nobody tweaks it, one of them can craft their part so the shared key secretly has a script hidden inside that only they can use, and the other two would never know. Tweaking the key with its own hash is a way of showing there's nothing hidden in there. That's why the chapter says "should" rather than "must".

However actual catch is if this depth is too great then size of control block will shoot up abruptly.

Yes, m is the depth, and you're right about the cost. Every level down the tree adds another 32 bytes to what you have to reveal. If you only have one script and nothing to hide, Taproot's script path actually comes out a bit more expensive than old-style P2WSH, because of that extra 33-byte control block. The smaller signatures and keys win some of it back, but not all.

Where it pays off is when there are several possible ways to spend. P2WSH makes you publish all of them every time. Taproot publishes only the one you used, plus one hash per level. The BIP suggests putting the branches you expect to use most near the top of the tree, so the usual case stays cheap. I agree a lot of people designing these don't think about depth until late.

The part "a Taproot output is the public key itself" is probably inaccurate

I think we're saying the same thing two different ways, and my sentence was the unclear one. The page you quoted says the tweaked public key goes into the locking script. That's right. All I meant was that what sits on the chain is a key and not a hash of a key, which is the difference from the older 1... and bc1q addresses.

On the quantum side athanred explains it better than I did. If someone could work out the private key for that on-chain key, they could simply sign and spend. They wouldn't need to know the original internal key or anything about the script tree, so the tweak doesn't add any protection there. I've reworded that line in the chapter to say "the tweaked output key, rather than a hash of one" so it doesn't trip anyone else up. Thanks for pointing it out.

Anyway, all keys from HD wallets are "tweaked", just in a different way

Agreed on all of it, and that last bit is a good way to put it. HD wallets derive child keys with the same kind of addition, so the trick is a lot older than Taproot. Taproot just uses it to commit to scripts.


Thanks to all three of you for reading it this closely. If anything else looks off, say so and I will fix it.

[Danish Ali]

Two other things to double-check in the text. One, it mentions Schnorr batch verification. Batch verification is possible with Schnorr, where one can verify N schnorr signatures all at once quicker than verifying them individually, but full nodes currently do not use this in IBD or block validation: the relevant PR on libsecp256k1 is still open. This was a big selling point of Schnorr over ECDSA so it’s nice to include, but saying “Bitcoin has Schnorr batch verification,” as opposed to what is true, that Schnorr enables batch verification that Bitcoin does not currently use, paints an inaccurate picture.

Next is the mention of aggregation. This is a bit harder to explain succinctly, and even the “Taproot explained” articles get this wrong, unfortunately, but Taproot enables aggregation in some contexts. The term gets thrown around with Taproot a lot (MuSig/MuSig2), so it sounds like it came out together. But it doesn’t allow aggregation across inputs within the same tx. However, for key-path spending, it can aggregate an n-of-n multisig setup into a single signature. It cannot aggregate signatures across multiple inputs though, so a tx that spends five Taproot outputs will have five signatures in it; it would require another soft fork to implement. For each input there will still be 1 sig.

I don’t know if we want to clarify these items in the text; they’re common enough misconceptions that it might be helpful. Similar to the 2008/2010 patent mix-up we caught, which is correctly updated in the chapter.