Wait what?
> It should be noted that Taproot outputs are vulnerable in that they encode a 32-byte x-only public key, from which a full public key can be reconstructed.
Login to reply
Replies (10)
? To me, to you. I don’t think I’ve wrapped my head around taproot but the public key would just be a hash of the total spend path scripts without actually revealing the base public key that is associated?
.
Yes, Taproot addresses (bc1p) are just encoded public keys, so they are vulnerable.
No, it's a public key, not a public key hash. This was done to save 8.25 vB from every P2TR tx, but at the expense of showing the public key in advance.
Interesting tradeoff
It's kinda thinking about it backwards... Basically, there's the scriptPubKey and the witness... The scriptPubKey contains a SegWit v1 opcode for Taproot plus a 32 byte x-only public key. This is the address you send funds to. Then, to spend them, you have to sign a transaction, then include the 64 byte Schnorr signature in the witness to verify you own the private keys to that address. The efficiency gain here is that the 32 byte public key doesn't need to be included in the witness also (that would cost 8.25 bytes with the 4x witness discount-- 32 / 4 = 8, 1 byte for OP_PUSHBYTES32)
I am just surprised because so many, including myself have celebrated the fact that the public key is protected behind a hash. I'm surprised that this decision didn't cause controversy in the space in itself.
The Taproot decision did, somewhat, back in 2020, on the bitcoin devs mailing list. But I guess that feedback wasn't taken seriously, especially by core dev Pieter Wuille.
It didn't hit my Twitter, Reddit or Bitdevs UK at the time. 😮💨
Very interesting, thanks for the explanation!