1 files changed, 28 insertions, 0 deletions
diff --git a/bip-0119.mediawiki b/bip-0119.mediawiki
index 5c02f3f..bf12b35 100644
--- a/bip-0119.mediawiki
+++ b/bip-0119.mediawiki
@@ -394,6 +394,34 @@ Furthermore, if OP_SHA256STREAM is added in the future, it may be possible to wr
 allows adding a single output to a list of outputs without incurring O(n) overhead by committing to
 a hash midstate in the script.
 
+=====Using SHA256=====
+
+SHA256 is a 32 byte hash which meets Bitcoin's security standards and is
+available already inside of Bitcoin Script for programmatic creation of template
+programs.
+
+RIPEMD160, a 20 byte hash, might also be a viable hash in some contexts and has some benefits. For fee efficiency,
+RIPEMD160 saves 12 bytes. However, RIPEMD160 was not chosen for BIP-119 because it introduces
+risks around the verification of programs created by third parties to be subject to a 
+[birthday-attack https://bitcoin.stackexchange.com/questions/54841/birthday-attack-on-p2sh] on
+transaction preimages.
+
+=====Using Non-Tagged Hashes=====
+
+The Taproot/Schnorr BIPs use Tagged Hashes
+(`SHA256(SHA256(tag)||SHA256(tag)||msg)`) to prevent taproot leafs, branches,
+tweaks, and signatures from overlapping in a way that might introduce a security
+[vulnerability https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-June/016091.html].
+
+OP_CHECKTEMPLATEVERIFY is not subject to this sort of vulnerability as the
+hashes are effectively tagged externally, that is, by OP_CHECKTEMPLATEVERIFY
+itself and therefore cannot be confused for another hash.
+
+It would be a conservative design decisison to make it a tagged hash even if
+there was no obvious benefit and no cost. However, in the future, if OP_CAT were
+to be introduced to Bitcoin, it would make programs which dynamically build
+OP_CHECKTEMPLATEVERIFY hashes less space-efficient. Therefore, bare untagged hashes
+are used in BIP-119.
 
 =====The Ordering of Fields=====