Message signing and verification is one of the quirks included in Bitcoin clients, although it isn’t used as much, this quirk can help you in different situations like proving the ownership of an address, proving a payment to a real world vendor or like a simple proof of an anonymous identity and avoiding fraud.

Currently this only works with P2PKH addresses (legacy addresses starting with a 1), leaving out a standard way to do it with P2SH or any different type of segwit addresses. Note that there exist some non-standard implementations with limited functionnality.

To allow other users to use this feature, Karl-Johan Alm picked up an old discussion from bitcoin-dev and proposed BIP 322 which could work for any type of address. This is to be done by making it a part of the Bitcoin scripting system, while this isn’t backwards compatible with the original implementation, it can make any address, including legacy ones, able to sign messages.

The basic concept is for an authorized spender(s) for an address to generate scriptSigs and witness data, including their signatures, in the same way they would if they were spending the funds, however instead of signing the spending transaction, they sign their attached message instead (including some predefined extra data to prevent them from being tricked into signing a real transaction). The verifier’s software validates this data the same way it would to determine whether a spending transaction was valid. This would make the message signing facility in Bitcoin as flexible as any Bitcoin script.

Some developers argued that such a feature could be done by making it into a fake transaction. While this has pros like being easier to incorporate and compatible with future bitcoin upgrades, it also comes with risks like tricking someone into signing a transaction instead of a message and older clients not being able to separate messages from transactions.

Either way it goes, this should be a fast BIP to implement, it breaks almost nothing and adds a new feature for segwit addresses.

Read more on the discussion for the BIP PR.