no, you are not. and this is super gay. this means there is zero protection against brute force or quantum attacks to reverse public keys. this is why i hate taproot. why could we not just have schnorr signatures on regular P2PKH? there's no upgrade path away from segwit with this horsecrap. i already hated the way that the APIs about taproot force you to specify a tweak. so now i see that every tx you make reveals the public key immediately. i doubt that their logic about why it isn't hashed washes technically either. it should have at least been a fucking sha256 hash. why not? just why FUCKING not? all of the changes starting with segwit have been a downward spiral. i think there should have been a simple single schnorr pubkey hash anyway. that's what segwit should have been. i'm gonna have to read closely through the state of bitcoin signatures and transaction formats to try and figure out if there is some hole to push something else in there that isn't this abomination. for some time to come, bitcoin's main transaction type is going to be single signature and not multisignature, and the logic of taproot signatures is based on not differentiating, so you put the pubkey at the out points instead of address hashes, and instead of reveal signatures you need the pubkey to validate the signature. after all, taproot is permitted but not understood by pre-taproot nodes, probably there is a way to do non-taproot schnorr signatures while remaining valid to old nodes but only limited to needing a wallet that can verify the signatures. i have thought about the idea of making a nostr event format that throws away the ID and pubkey and using reveal signatures (like segwit and legacy do, the hash combines with the signature and produces the public key). it would be very neat and compact for saving a full 256 bytes of data in nostr events. make the signatures base64URL and they are also only 86 bytes instead of 128. this would leave enough space for a check on it with the extra 40 bytes, merely 240 bits, hardly even truncated, which would then serve as verification and the signature and fingerprint would take the space of one hex signature and provide identification and message authenticity. you hash the revealed pubkey, and then compare to the fingerprint, and if it matches the pubkey is correct and the message is authentic.