diff --git a/Comments:BIP-0178.md b/Comments:BIP-0178.md
index 5ce7c94..38d0005 100644
--- a/Comments:BIP-0178.md
+++ b/Comments:BIP-0178.md
@@ -2,4 +2,6 @@
 
 Most wallets support BIP32 to allow the user to backup their secrets once and generate multiple keys and receiving addresses from that secret. BIP32 defines a [serialization format](https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#Serialization_format) of the extended private and public keys and uses a 4-byte length "version bytes" (xpub and xprv on the BTC mainnet). There are competing extensions to that serialization format. [SLIP-0132](https://github.com/satoshilabs/slips/blob/master/slip-0132.md) registers extra version bytes that were introduced by the Trezor and the [Electrum](http://docs.electrum.org/en/latest/xpub_version_bytes.html) wallets (ypub, zpub...). Another extension, [SLIP-0032](https://github.com/satoshilabs/slips/blob/master/slip-0032.md) serializes the full derivation path and therefore lets the wallet that imports the extended key detect the used script templates by the purpose part ([BIP-0043](https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki)) of the key derivation. This is made possible, because [BIP-0084](https://github.com/bitcoin/bips/blob/master/bip-0084.mediawiki#public-key-derivation) uses `m/84'` as a subtree for P2WPKH scripts and [BIP-0049](https://github.com/bitcoin/bips/blob/master/bip-0049.mediawiki#public-key-derivation) uses `m/49'` as a subtree for P2WPKH-nested-in-P2SH scripts.
 
-This BIP-0178 seems to completely ignore that keys are nowadays in a hierarchy and the derivation path determines the script templates. If we assume that each key is independently created, backed up and later restored onto a fresh device, I completely see the purpose of this suggestion. But then I would even extend it with a way to backup a custom script template at the end of the exported WIF together with the private key.
\ No newline at end of file
+This BIP-0178 seems to completely ignore that keys are nowadays in a hierarchy and the derivation path determines the script templates. If we assume that each key is independently created, backed up and later restored onto a fresh device, I completely see the purpose of this suggestion. But then I would even extend it with a way to backup a custom script template at the end of the exported WIF together with the private key.
+
+-- [Wigy](https://github.com/wigy-opensource-developer), 2019-05-30