Published on: 2019-08-11T06:08:48+00:00
In a Bitcoin developer mailing list, a suggestion has been made to drop the Y oddness bit in the witness program for Taproot outputs. This change would not affect security and would prevent Taproot outputs from being more expensive than v0 P2WSH. It would also allow for future changes that may still require the additional byte. As part of exploring this option, it has been found that introducing a type of 32-byte public keys in bip-schnorr would be the cleanest approach. This raises the question of whether 33-byte public keys are necessary at all. While bip-schnorr public keys would not be exactly the same as ECDSA public keys if this change is implemented, all derivation logic would still apply. Under this modification, the Q point in bip-taproot (the one going in the scriptPubKey) would follow the 32-byte pubkey encoding instead of needing a 33rd byte. The P point in bip-taproot (the internal key revealed during the script path) would become a 32-byte public key. All public keys inside bip-tapscript would also be 32-bytes long. If desired, the "upgradable public key" construction in bip-tapscript can be retained by triggering based on the length of public keys. However, opinions are being sought about whether it is worth making this change to bip-schnorr at this stage, considering that it has already been in use for some time. While it is possible to keep verification compatible by hashing the implied "even" byte inside the scheme, which commits to the pubkey, if changes are to be made, it is best to do so as cleanly as possible and drop that byte as well. In conclusion, this is a discussion within the Bitcoin developer community about modifying bip-schnorr to only define 32-byte public keys and how it would impact Taproot outputs and bip-tapscript. Pieter Wuille suggests making the change cleanly and dropping the extra byte, while Christopher Allen proposes considering a non-binary format for sharing public keys.
Updated on: 2023-08-02T01:16:16.596719+00:00