1 files changed, 25 insertions, 1 deletions
diff --git a/bip-0174.mediawiki b/bip-0174.mediawiki
index 445e350..65fa9a9 100644
--- a/bip-0174.mediawiki
+++ b/bip-0174.mediawiki
@@ -143,7 +143,7 @@ The currently defined per-input types are defined as follows:
 * Type: Non-Witness UTXO <tt>PSBT_IN_NON_WITNESS_UTXO = 0x00</tt>
 ** Key: None. The key must only contain the 1 byte type.
 ***<tt>{0x00}</tt>
-** Value: The transaction in network serialization format the current input spends from. This should be present for inputs that spend non-segwit outputs and can be present for inputs that spend segwit outputs. An input can have both <tt>PSBT_IN_NON_WITNESS_UTXO</tt> and <tt>PSBT_IN_WITNESS_UTXO</tt>. <ref>'''Why can both UTXO types be provided?''' Many wallets began requiring the full previous transaction (i.e. <tt>PSBT_IN_NON_WITNESS_UTXO</tt>) for segwit inputs when PSBT was already in use. In order to be compatible with software which were expecting <tt>PSBT_IN_WITNESS_UTXO<tt>, both UTXO types must be allowed.</ref>
+** Value: The transaction in network serialization format the current input spends from. This should be present for inputs that spend non-segwit outputs and can be present for inputs that spend segwit outputs. An input can have both <tt>PSBT_IN_NON_WITNESS_UTXO</tt> and <tt>PSBT_IN_WITNESS_UTXO</tt>. <ref>'''Why can both UTXO types be provided?''' Many wallets began requiring the full previous transaction (i.e. <tt>PSBT_IN_NON_WITNESS_UTXO</tt>) for segwit inputs when PSBT was already in use. In order to be compatible with software which were expecting <tt>PSBT_IN_WITNESS_UTXO</tt>, both UTXO types must be allowed.</ref>
 *** <tt>{transaction}</tt>
 
 * Type: Witness UTXO <tt>PSBT_IN_WITNESS_UTXO = 0x01</tt>
@@ -200,6 +200,30 @@ The currently defined per-input types are defined as follows:
 ** Value: The UTF-8 encoded commitment message string for the proof-of-reserves.  See [[bip-0127.mediawiki|BIP 127]] for more information.
 *** <tt>{porCommitment}</tt>
 
+* Type: RIPEMD160 preimage <tt>PSBT_RIPEMD160 = 0x0a</tt>
+** Key: The resulting hash of the preimage
+*** <tt>{0x0a}|{20-byte hash}</tt>
+** Value: The hash preimage, encoded as a byte vector, which must equal the key when run through the `RIPEMD160` algorithm
+*** <tt>{preimage}</tt>
+
+* Type: SHA256 preimage <tt>PSBT_SHA256 = 0x0b</tt>
+** Key: The resulting hash of the preimage
+*** <tt>{0x0b}|{32-byte hash}</tt>
+** Value: The hash preimage, encoded as a byte vector, which must equal the key when run through the `SHA256` algorithm
+*** <tt>{preimage}</tt>
+
+* Type: HASH160 preimage <tt>PSBT_HASH160 = 0x0c</tt>
+** Key: The resulting hash of the preimage
+*** <tt>{0x0c}|{20-byte hash}</tt>
+** Value: The hash preimage, encoded as a byte vector, which must equal the key when run through the `SHA256` algorithm followed by the `RIPEMD160` algorithm
+*** <tt>{preimage}</tt>
+
+* Type: HASH256 preimage <tt>PSBT_HASH256 = 0x0d</tt>
+** Key: The resulting hash of the preimage
+*** <tt>{0x0d}|{32-byte hash}</tt>
+** Value: The hash preimage, encoded as a byte vector, which must equal the key when run through the `SHA256` algorithm twice
+*** <tt>{preimage}</tt>
+
 * Type: Proprietary Use Type <tt>PSBT_IN_PROPRIETARY = 0xFC</tt>
 ** Key: Variable length identifier prefix, followed by a subtype, followed by the key data itself.
 *** <tt>{0xFC}|<prefix>|{subtype}|{key data}</tt>