https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki#cite_note-2

so, their logic is that not using a pubkey hash in the output saves 32 bytes for the following spend, and that sha256+ripemd160 provides only 80 bits of security. the logic goes that by using ripemd160 the search space for valid solutions is expanded by 48 bits, so only 2^80 tries should get one valid solution.

what this means is that you only have to search 80 bits (10 bytes, or 2^80 possible values) to find a candidate secret key that generates the same pubkey hash. so to increase that to 128 bits, as you get with a 256 bit hash, you would need to remove the ripemd160 - and probably don't need to do it twice.

but the note goes on to explain why this isn't enough:

it's assumed that *most of the use* of P2TR is going to be multisig. i suppose they were thinking lightning channel opens. idk about that. i think onchain is gonna still be common in 10 years time but only by then maybe channel opens predominate. Ark doesn't need this, it operates without making onchain transactions until it closes its routes, which it can basically defer almost indefinitely because of the way VTXOs work.

the logic behind the justification to make the single signature transaction essentially sacrifices the security against public keys being revealed, by forcing them to be revealed immediately on spend what signature must be on the spend for a UTXO. so actually, they are handing a lot more time to quantum and brute force attackers and attackers using side channels, a shitload of time to break the pubkey of P2TR transactions.

for the sake of 32 bytes

which is the whole selling point of P2TR - smaller transaction.

yes, because they sacrificed a type of security that at the time was not considered as important, and because they are thinking that most taproot tx's are going to be FUCKING MULTISIG.

i don't think this is reasonable. i think they should have retained the pubkey hash, and not muddled up the separate concerns of a single signer versus multisig. my first impression of what i first learned about taproot from reading the APIs of the btcec codebase was that it was mashing together two things that were not necessarily linked or secure to be linked. a domain boundary violation, a code smell of a bad architecture.

if my atomic swaps are going via taproot, then they are single sig. if my onchain payments are going via taproot, they are single sig.

it is only the one out of three case of a lightning channel open that it's got two of two.

definitely gotta read up more on this because it just seems like they have designed the security model not in favor of hodling, to me.

hodling in taproot might not be a good idea. that's the thing that springs to mind out of reading this. the first crack of an EC pubkey deriving the secret from it probably will happen in the next 10 years. it might be very expensive but this leaves taproot addresses wide open to this attack for anyone who isn't spending the SINGLE SIG transaction quickly again.