Published on: 2013-04-14T18:24:34+00:00
Peter Todd and Alan Reiner have discussed the need to add an ASCII-armored format for message signing. This new format will encode the signed message next to the signature, eliminating any ambiguity about what was signed. The primary purpose of this format is to allow users to copy an ASCII-armored block of text into the client app and receive a pop-up window displaying the message along with a valid signature from a specific address. The format to follow for this implementation is RFC2440, section 7 "Cleartext signature framework". In another discussion between Luke-Jr and Peter Todd, Todd suggests extending the functionality of signmessage/verifymessage to support messages signed by multiple keys or P2SH multisig addresses. However, Luke-Jr suggests that HD wallet changes should be figured out first to avoid signing with the same private key twice. He proposes creating a new address format that represents a chain of keys instead of just one key or combination of keys. Todd agrees with this suggestion and mentions that he has an application where multisig signmessage would be useful.In an email exchange on April 14, 2013, Peter Todd suggests extending the signmessage/verifymessage feature to support messages signed by multiple keys or P2SH multisig addresses. However, he emphasizes the importance of figuring out HD wallet changes before making these extensions to ensure privacy and safety. Todd suggests creating a new address format that represents a chain of keys rather than one key or combination of keys to avoid signing with the same private key twice.The current signmessage/verifymessage feature only supports messages signed by a single key. However, it is proposed to extend this feature to support messages signed by multiple keys or P2SH multisig addresses. rpc.cpp:signmessage() returns the output of SignCompact(), which uses a header byte format to mark the signs of the various keys for key recovery. For multisig signmessage signatures, each signature or key can be in the form of sig, compressed key, or uncompressed key. All pubkeys must be provided even if they are not used for a specific signature to reconstruct the P2SH address. The encoding/decoding process for this format is code-intensive but keeps the size to a minimum. The format is backward compatible, and new signatures can be easily distinguished from old ones. In addition, signing incomplete signatures on messages can be handled by converting pubkeys to signatures, and the RPC signmessage command can be extended with an optional "existing signature" option.
Updated on: 2023-08-01T04:39:29.847450+00:00