Published on: 2018-09-12T07:56:25+00:00
The proposal to extend the existing sign/verifymessage format in Bitcoin has been updated. The new proposal, called the Generic Signed Message Format, can be found at this link: https://github.com/kallewoof/bips/blob/bip-generic-signmessage/bip-0322.mediawiki. One major aspect of the feedback received was whether proofs should be given as transactions or not. Using the transaction format offers advantages such as compatibility with existing HSMs and easier incorporation into existing software. It also provides forward compatibility with bitcoin extensions like mimblewimble and confidential transactions, as well as compatibility with HSMs regardless of whether a transaction or a message is being signed. However, there are drawbacks to using the transaction format. For example, if a challenger convinces a prover to sign a message that corresponds to an actual transaction, there could be danger. Unupgraded software may also struggle to differentiate between message signing and transaction signing. Additionally, hardware wallets that display the contents of the transaction during signing may experience a less user-friendly experience. HSMs also do not support the transaction format or upgrading, which is intentional.There is some debate over whether an "OP_MESSAGEONLY" opcode should be introduced, but the priority is addressing the aforementioned issues first. The proposal introduces a new structure called SignatureProof, which serves as a simple serializable scriptSig & witnessProgram container. This structure defines two actions: "Sign" and "Verify." It is important to note that this new proposal is not backwards compatible with the legacy signmessage/verifymessage specification. However, it can still be used with legacy addresses (1...) without any problems.The goal of this proposal is to create a more generalized variant of the sign/verifymessage format by relying on the script verification mechanism in Bitcoin itself. By doing so, the format can accommodate various types of addresses beyond just P2PKH (1...) addresses. This would allow for greater flexibility without burdening implementers, who likely already have access to Bitcoin Script interpreters.The Generic Signed Message Format specification provides detailed steps for signing and verifying messages. It also has the potential to handle proof of funds using the message prefix "POF:" followed by a newline-terminated string and a series of hex-encoded transaction ID:vout pairs.It is important to note that the proposal is still in the draft stage, and no comments have been posted yet. The document is licensed under the Creative Commons CC0 1.0 Universal license. At this time, the reference implementation is not available, and this section of the proposal remains to be completed.
Updated on: 2023-08-01T23:53:49.325127+00:00