user101033: The corresponding Merkle proof needs to be given when unlocking UTXO using MAST, where the hash of an unused script will be included. For the observation, it seems possible to guess the unused script from the hash. For example, I might be able to get some public keys from the script that is actually being executed, and then I combine one of them with some time locks to try to do hash collisions.
Adding salt to the script would seem to easily prevent this, so why hasn't Taproot done this? Is this because the hash collision described above is basically infeasible, and adding salt takes up extra witness space?

user47827: Salts are used for things like password storage where multiple users may be using the same password. By using a salt it obfuscates to an observer of the database which users are using the same password because of different salts. The only motivation for using a salt on Taproot scripts would be if users were using the same Taproot scripts. But at the very least users' public keys will be different (unless they are using the same private key) and so no Taproot scripts will be the same unless they are controlled by the same user.
To state the obvious users shouldn't be using the same password (terrible password hygiene) for non-Bitcoin services but it is even more serious for Bitcoin. If users don't generate a Bitcoin private key with sufficient entropy their Bitcoin will likely be stolen.

For the observation, it is possible to guess the unused script from the hash.

Guessing the preimage of a secure hash function is infeasible. It can only be done through brute force (trying lots of possible preimages) but there are so many possible preimages it is like looking for a needle in a haystack.

user208: In general this shouldn't be a concern, as every script almost certainly contains at least a public key, and you can use fresh public keys in every branch.
If you're still concerned about privacy of the revealed script, you can tweak the public keys in it manually with some secret that's shared between all participants (e.g. the hash of concatenation of all scripts in it, before tweaking). Or you can even add extra data to one using a push opcode and OP_DROP.

101033: <p>The corresponding Merkle proof needs to be given when unlocking UTXO using MAST, where the hash of an unused script will be included. For the observation, it seems possible to guess the unused script from the hash. For example, I might be able to get some public keys from the script that is actually being executed, and then I combine one of them with some time locks to try to do hash collisions.</p>
<p>Adding salt to the script would seem to easily prevent this, so why hasn't Taproot done this? Is this because the hash collision described above is basically infeasible, and adding salt takes up extra witness space?</p>
 47827: <p>Salts are used for things like password storage where multiple users may be using the same password. By using a salt it obfuscates to an observer of the database which users are using the same password because of different salts. The only motivation for using a salt on Taproot scripts would be if users were using the same Taproot scripts. But at the very least users' public keys will be different (unless they are using the same private key) and so no Taproot scripts will be the same unless they are controlled by the same user.</p>
<p>To state the obvious users shouldn't be using the same password (terrible password hygiene) for non-Bitcoin services but it is even more serious for Bitcoin. If users don't generate a Bitcoin private key with sufficient entropy their Bitcoin will likely be stolen.</p>
<blockquote>
<p>For the observation, it is possible to guess the unused script from the hash.</p>
</blockquote>
<p>Guessing the preimage of a secure hash function is infeasible. It can only be done through brute force (trying lots of possible preimages) but there are so many possible preimages it is like looking for a needle in a haystack.</p>
 208: <p>In general this shouldn't be a concern, as every script almost certainly contains at least a public key, and you can use fresh public keys in every branch.</p>
<p>If you're still concerned about privacy of the revealed script, you can tweak the public keys in it manually with some secret that's shared between all participants (e.g. the hash of concatenation of all scripts in it, before tweaking). Or you can even add extra data to one using a push opcode and OP_DROP.</p>
