2

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?

Improve this question

2 Answers 2

Reset to default
4

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.

Improve this answer
2

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.

Improve this answer
7
  • Yes, it would be very difficult to find hash collisions, but would it be easier if there were some qualifications? For example, the three unlocking conditions in a MAST are 1. sig from A && sig B && timelock 10 Blocks 2. sig from A && timelock 100 Blocks 3. sig from B && timelock 200 Blocks They then eventually unlocked with condition 1. The observer then tries A's public key + time lock to collide. I know this is a rare example, but it still works, right? And if you add salt to the script it seems to stop it?
    – sphpmp
    Commented Jul 19, 2021 at 7:53
  • Just checking I understand your question. In your scenario a script is revealed and a blockchain observer uses the details of that script to try to work out through (informed) brute force the other scripts in the Taproot tree (MAST) that weren't revealed and used to spend? Or uses the details of that script to try to work out the other scripts in other Taproot trees? Because obviously the observer/attacker doesn't know the private key(s) and so can't steal the funds even if he/she succeeds in brute forcing a particular script from a hash.
    – Michael Folkson
    Commented Jul 19, 2021 at 8:09
  • No, I don't want to discuss here whether an attacker could spend this UTXO, but only whether this would lead to a leak of unused scripts, as this seems to defeat the original purpose of Taproot? And by adding salt to the script, for an observer, even if he knows some information, he cannot know the script corresponding to the hash (because of the presence of the salt).
    – sphpmp
    Commented Jul 19, 2021 at 8:15
  • I think the answer to your question then is that tagged hashes are used throughout Taproot and this performs a similar role to a salt. github.com/bitcoinops/taproot-workshop/blob/…
    – Michael Folkson
    Commented Jul 19, 2021 at 8:44
  • 1
    @MichaelFolkson As the tagged hash is predictable it can't function as a salt. It prevents the data being hashed from accidentally matching a hash used in a different context, but it cannot provide privacy as the tag isn't secret.
    – Pieter Wuille
    Commented Jul 19, 2021 at 15:19

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.