<oembed><type>rich</type><version>1.0</version><author_name>npub1xq96jnxfzrdq4zgre20yqjrjsd29vcw8ymypl4v59cg6q6p66cts8q2u5f</author_name><author_url>https://nostr.ae/npub1xq96jnxfzrdq4zgre20yqjrjsd29vcw8ymypl4v59cg6q6p66cts8q2u5f</author_url><provider_name>njump</provider_name><provider_url>https://nostr.ae</provider_url><html>📅 Original date posted:2022-08-04&#xA;📝 Original message:Hi,&#xA;&#xA;I have created a new BIP, called notatether-signedmessage. It can be viewed at https://github.com/ZenulAbidin/bips/blob/master/bip-notatether-signedmessage.mediawiki.&#xA;&#xA;For those who want a quick summary, it defines a step-by-step process for signing and verifying messages from legacy, native/nested segwit, and taproot addresses. It does not define a new signature format itself, except in the case of Taproot. For those addresses, I have defined a signature format that has 1 byte header/recID, 64 bytes signature, and 32 bytes x coordinate of a public key. This is required to run the BIP340 Schnorr verify algorithm using only the signature - and the header byte is added for backwards compatibility. Otherwise, it completely integrates BIP137 signatures.&#xA;&#xA;I am planning to move that format to its own BIP as soon as possible, in lieu that it is unacceptable to define formats in an Informational BIP.&#xA;&#xA;Please leave your comments in this mailing list. CC&#39;ing BIP editors.&#xA;&#xA;- Ali</html></oembed>