Published on: 2022-07-23T04:28:08+00:00
In a recent email, Peter from Coinkite Inc mentioned that the BIP-322 proposals did not gain wide acceptance in the past. However, there is renewed interest in using BIP322 to validate signatures related to upgrading the Bitcoin-native Decentralized Identifier Method (did:btcr) beyond its current specification, to version 2.0. This has been discussed in detail in the advance-readings of the RWOT11 conference in The Hague and in the DID Core specification document by W3C. The proposed use of BIP322 would allow for improved security and privacy in the handling of decentralized identifiers on the Bitcoin blockchain.Ali Sherief proposed a BIP to address the lack of standardization for Segwit message signatures. Currently, wallets that support signing and verifying a Bitcoin message can only sign legacy addresses. Although it is technically possible to sign and verify segwit addresses, the absence of an accepted standard for signing segwit messages means that wallets that do support this feature simply insert the segwit address into the address field. Verification also only works using the procedure on that specific wallet software. This BIP does not enforce anything but sets guidelines for writing a message signing and verification procedure. The proposal standardizes the practice of placing the segwit address into the address field and does not require alterations to the message signing format like those in BIPs 173 or 322.In the verification part, the following address hashing algorithms will be tried in sequence in an attempt to reconstruct the address in the signed message: P2PKH (legacy address), P2WPKH-P2SH (nested segwit), and P2WPKH with version from 0 to MAX_WITNESS_VERSION (covers native segwit with version 0 as well as future native segwit address types such as Taproot) - where MAX_WITNESS_VERSION is the maximum supported witness version by the bech32 encoding. The verification procedure stops if any of these hashes yield the correct address, and fails if all of the above methods fail to reproduce the address in the signed message.In the signing procedure, the only modification is the insertion of the segwit address in place of the legacy address in the signed message. The proposal does not require any changes to existing signed messages, and the original sign/verify algorithms will continue to interoperate with this improved sign/verify algorithm, without any action necessary from the developers.Craig Raw verifies the signature by converting the message and signature to a public key, trying first BIP137 and then the approach used by Electrum. The script type is extracted from the provided address and compared against the address constructed with the public key using the same script type. BIP322 is suggested as a reference, which was not widely accepted.The original approach for signing segwit messages was directly from Satoshi himself and has never been codified in a BIP. The proposal does not replace, supersede, or obsolete BIPs 173 or 322 and only aims to standardize the practice of placing the segwit address into the address field. However, any universal BIP that encompasses all signatures would have to check for BIP137 signatures. Fortunately, only the verification algorithm needs to be adjusted to identify BIP137 signatures.Ali Sherief, a developer, is proposing to create a Bitcoin Improvement Proposal (BIP) to address the lack of standardization for Segwit message signatures. Currently, wallets that support signing and verifying a bitcoin message can only sign legacy addresses. There is no generally-accepted standard for signing segwit messages. Ali's proposal will standardize the practice of placing the segwit address into the address field and set guidelines for writing a message signing and verification procedure.The BIP does not replace, supersede, or obsolete BIPs 173 or 322. In the verification part of the proposal, P2PKH (legacy address), P2WPKH-P2SH (nested segwit), and P2WPKH with version from 0 to MAX_WITNESS_VERSION will be tried in sequence in an attempt to reconstruct the address in the signed message. If any of these hashes yield the correct address, the verification procedure stops, and it fails if all of the above methods fail to reproduce the address in the signed message.In the signing procedure, the only modification is the insertion of the segwit address in place of the legacy address in the signed message. Ali plans to add a Python example for the signing and verification process, which can be translated to C++ without even minor interface/implementation difficulties. However, Bitcoin Core does not currently support verifying the message as its UX makes it look possible, but in effect, segwit features never got implemented to that depth in Core. Peter (Coinkite Inc) suggests that a "defacto" BIP is needed, and Core should be updated to support it.
Updated on: 2023-08-02T07:03:29.248557+00:00