BIP 322 draft design and improvement thread

[NotATether]

This is a thread for coordinating and discussing improvements for the BIP322 draft and problems that need to be addressed inside the draft. There is an active "issue" (technically speaking. But I view that as more of a "list all problems" thread) on Github where the BIP designers are trying to iron out all the creases inside the draft. Let's give them a helping hand, shall we?

Since my signing message reference manual BIP "proposal" has been rejected on the grounds that more work should be done on BIP322 to make it final (Interested viewers can read the full discussion here), I have done two things, besides locking the other thread:

- I created this page https://en.bitcoin.it/wiki/Signed_Message and salvaged the bulk of the algorithms there (all these years, and nobody thought about creating this page? NO wonder why we have divergent signing implementations. But that's not the point).

- I am redirecting efforts to BIP322, by opening threads like this for example.


This thread should be used as the mailing-list analogue for discussion about BIP322, a draft BIP that is supposed to make universal signed messages.

In other words, talking about BIP322, and shower thoughts about how to improve or simply it are welcome here (BIP322 suffers from only one problem and it's that the document is quite difficult for people getting on the initiative to understand, when you compare it to e.g. BIP340, or how I wrote my BIP).

Do not derail this thread with off-topic arguments. Proposals made here will be relayed to the mailing list. I am not self-moderating this thread, but if this thread gets derailed, I will lock it, and open a new, self-moderaded thread.
EDIT 2020-08-09: This is not the place to talk about why XXX proposal is better than BIP322, or vice versa, either.


The questions we should be asking ourselves are:

1. What exactly does BIP322 give us to solve the "proof of sent-transaction" problem
2. How is all this going to be implemented without excessive classes and libs (code bloat).

Well for 1, we see that we have "Legacy" aka. equivalent to the legacy signing format - why don't they support BIP137 in this area since it was finalized years ago? Anyway, the second format "Simple" appears to be the one that solves the bulk of the problems with message signing (the last one, "Full", is something I expect to be used only by mad computer scientists toying around with transactions because it lets you customize all the tx fields).

That leaves us with 2. On paper, it looks simple enough - provided a step-by-step guide for deriving them is created - but I am not sure how one is supposed to implement "Full (proof of funds)". It needs a UTXO set, something that is not trivial to get without the address of a full node (unless the software is a full node itself!)

How should we cope with such situations such as the one above? Should other wallets shave off the parts they can't implement without access to a full node?

[1714897786]

1714897786

[1714897786]

1714897786

[NotATether]

The Github issue where everybody is reviewing BIP322

Notes:
One thing is certain - its ubitiquous use will not become a reality unless standalone script interpreters are made and maintained.

[garlonicon]

BIP322 suffers from only one problem and it's that the document is quite difficult for people getting on the initiative to understand, when you compare it to e.g. BIP340, or how I wrote my BIP

You can solve it quite easily: for each address type, there is only one thing that needs to be changed: the signed message. So, you can just define it for each address type as "<constant><addressData><constant>", then hash it, and that's all, everything else will be the same. So, you can prepare all things like transaction version, output, locktime, and all of that, to finally get it as some constants, and some script-encoded addresses inside. Then, your format will be fully BIP-322 compatible, and will allow extending it in the future, just by adding implementation for signing any scripts. For now, you can just treat any unknown script types as "unsupported" in your BIP.

[NotATether]

@garlonicon:

It's not about my BIP anymore, it's about trying to make BIP322 as simple as possible for people to implement.

Is it true that people will only need to make a hash of the "transaction" in the signing part? I can't seem to find any cryptographic validation that is being done in the verifying part, for example in ECDSA we create r,s values corresponding to a public key, but with this transaction-based signature method, I only see that fields are being verified to have sane data. Is there not at least a check that the transaction hashes to something correct [and is then distributed with the sig, otherwise it would be malleable]?

[garlonicon]

1. What exactly does BIP322 give us to solve the "proof of sent-transaction" problem

What is "proof of sent-transaction" problem? You can always make "<messageHash> OP_DROP <pubkey> OP_CHECKSIG" output, and prepare a signature for that. Checking if any such thing is connected with real, on-chain coins, is up to the recipient of such signature. Also, you can have just "<pubkey> OP_CHECKSIG", and your R-value of your signature could be converted to a Taproot address, and then you can provide "OP_RETURN <anything>" TapScript for such key. I wonder what this "proof of sent-transaction" is about: is it about providing OP_CHECKDATASIG functionality?

2. How is all this going to be implemented without excessive classes and libs (code bloat).

By specifying the script for each address type, and then by concatenating it with some BIP-defined constants, and hashing the result. From your BIP perspective, you don't have to describe that "there is transaction version equal to zero". You can say "just concatenate this data", and redirect people to BIP-322 to learn more, why those constants were picked.

why don't they support BIP137 in this area since it was finalized years ago?

Because it cannot be easily extended to signing any script.

It needs a UTXO set, something that is not trivial to get without the address of a full node (unless the software is a full node itself!)

It doesn't. The recipient is responsible for checking if some UTXO is spent or not. So, that recipient could have full node, could use SPV node, could check it in some block explorer, or could skip that at all, if the only purpose is to know, if someone can "control" a given key. For many people, checking that "I love pancakes." message matches some public key, is sufficient. So, it is possible to create a standard, where basic verification can be performed entirely offline, and when the recipient could get more advanced verification by being online, or by providing more information, for example "I want to verify it offline, and I want to assume that <txid:vout> is a valid output". Another thing is that storing the whole chain is not needed, you can limit it to knowing only transactions, then it would be possible to support SIGHASH_PREVOUT_SOMETHING in the future.

How should we cope with such situations such as the one above? Should other wallets shave off the parts they can't implement without access to a full node?

Exactly. If you are offline, and you sign a multisig transaction, you can get a valid signature, and also you can get a boolean value saying that it is incomplete. The same could be here: you could get more detailed verification than yes/no. You can get "valid signature", "valid UTXO", "valid something else", etc., it could depend, how many things you want to verify, it could be decided by the recipient, and the program could return "more information needed" when something is missing, or could return "unsupported script type" if something is not implemented.

Is it true that people will only need to make a hash of the "transaction" in the signing part?

Yes.

Is there not at least a check that the transaction hashes to something correct [and is then distributed with the sig, otherwise it would be malleable]?

Yes, it is checked that the z-value really hashes to the computed data, otherwise it would be unsafe from ECDSA point of view, because for every public key, it is possible to compute random <z,r,s> tuple. But you can force Bitcoin Core to sign any transaction, so it could be possible to also force it to verify any transaction. If you have a pruned node that has some "<txid:vout>" in its database, then Bitcoin Core thinks it is 100% trusted data. The same with signatures: you can have some full node, and then be absolutely sure that your transaction corresponds to some existing UTXOs. But you don't have to, you can decide, how many things you want to verify.

[pooya87]

It's not about my BIP anymore, it's about trying to make BIP322 as simple as possible for people to implement.

That's impossible in my opinion because BIP322 and any similar proposal requires a lot of script related code that majority of tools don't have. For example Electrum as one of the most popular SPV clients doesn't really support scripts (it has a minimal implementation of it). Implementing the script interpreter (even small parts of it like OP_IF) is also difficult since the interpreter is not fully documented and it is a large amount of code.

[achow101]

Is it true that people will only need to make a hash of the "transaction" in the signing part? I can't seem to find any cryptographic validation that is being done in the verifying part, for example in ECDSA we create r,s values corresponding to a public key, but with this transaction-based signature method, I only see that fields are being verified to have sane data. Is there not at least a check that the transaction hashes to something correct [and is then distributed with the sig, otherwise it would be malleable]?

No.

Signing with BIP 322 is signing a transaction except that the transaction contains explicitly invalid inputs so that it cannot be used as a real transction. It is not a signature in the cryptographic sense because just signatures themselves are incompatible with the vast majority of Bitcoin scripts. Rather it requires the entire witness in order to validate the script, which may or may not include signatures, depending on the script. Verifiers must execute the script in order to determine whether the "signature" is valid. It is more than just checking data in fields. Bitcoin operates with a scripting system, so any proof method that wants to allow message "signing" for arbitrary scripts must have a script interpreter.

The aforementioned scripts often contain cryptographic signatures because signatures prevent Bitcoin from being taken when making actual Bitcoin transactions.

[garlonicon]

That's impossible in my opinion because BIP322 and any similar proposal requires a lot of script related code that majority of tools don't have.

But we could get there incrementally. For example, validating P2PKH in BIP-322-compatible way is just a matter of getting some address, putting "76a914<address>88ac" in some field, and then it is only about hashing and concatenating some constants. So, for each Bitcoin-Message-based signature, it can be converted into BIP-322-compatible signature, and it would require only concatenating some constants, and hashing different things, but as long as some implementation allows concatenation and hashing, no more things are needed, and other cases could be handled as "not implemented", and then added later.

So, I think we should start with some BIP-322-compatible signatures, and then extend them incrementally.

[aliashraf]

OP,

In BIP322 discussions in Github, Greg Maxwell argues:

On a high level, it seems to me that the purpose of the BIP is not entirely clear. At the moment, it is only for signing messages but includes the entire scripting system. [...] Does the BIP implicitly assume that a scriptPubKey contains exactly one pubkey?

I think this isn't the best way to think about this facility. Bitcoin transactions are not signed with ECDSA. They are signed with a digital signature system called "Bitcoin Script". Bitcoin Script happens to have ECDSA embedded in it-- like ECDSA has field multiplication embedded in it. A bitcoin message signing thing can be seen as just a sign-stuff-using-script.

Unfortunately, this is not correct as there is no such a digital signature scheme in the world, Maxwell is just inventing it. I don't want to dig it too much, asking why anybody should make such an attempt, it would be very interesting topic per se, but for the purpose of this discussion, it is very important to understand what this "sign by script" thing is saying: it claims kinda superiority, being more pure and generalized than conventional ES systems. From this, one should be able to understand BIP322, how it changed the course to become what it is now, what it wants to do, and why it is not implemented.

What is it?
BIP322 in its latest form and after the Maxwell's comment, wants to implement the illusive bitcoin script digital signature, How? Andrew described it above thread: A fake bitcoin transaction is generated and signed that follows a specific convention, in this txn, one outpoint of a real txn (unspent or spent in the blockchain or not even published yet) is virtually 'spent' hence the signer proves that he is the one who 'can do it'.

What is the use-case?
Well, in the same comment,  Maxwell suggests:

Why would someone want to sign messages using script? In practice usually for dumb reasons for proving control or tying metadata to addresses that used to control funds, currently currently control funds, or will control funds in the future. For these latter three things, nothing less than Bitcoin Script would work-- no amount of "sniff scripts yank keys out" would actually get the right behaviour.

For the "currently control funds" case it would be very useful if the system actually can check the existence of the funds (e.g. specifying txouts and checking them). For the "previously controlled funds" it would be very useful if the system could check that (SPV proofs for the outputs? kinda big ).

But for the "will control funds in the future" case there is basically no special behaviour needed/possible except signing with the same digital signature system which will eventually be used.

So I think this would mostly be useful for this last case. But that last case might better by serve by dry-signing an actual transaction with a dummy input/locktime, since doing that actually verifies your ability to sign for transaction like things.

For CSV, CLTV... probably the right way to do that is have them go in as non-locked (max sequence) by default but allow specifying other values for these fields as some kind of argument tagged onto the end of the address.

IOW, if you want to prove that you have unlocked, are able to unlock, will be able to unlock a script you should use bitcoin script.

But how correct this idea of use cases is? Well, not much.

Foremost, signing with bitcoin addresses is not limited to what Maxwell enlists, actually what he probably considers as a dumb reason, is the mainstream: we sign messages to prove authenticity while bragging with our bitcoin identity, the funds that are bound/have been bound to the address are not relevant in 99% cases what he considers as being dumb!

Even when funds are important, there is no reason to over generalize the case, the traditional sniffing out an address from the script is how you should deal with the problem as long as the script is standard, and both signing and verification can be trivially done using templates and placeholders, etc.
What about more sophisticated scripts?  
It is where you need to use your engineering skill: rip it out from the problem domain! Ignore it as a legitimate use-case, ask people, not to ask such 'dumb' things!  
Why? To avoid going down the rabbit hole and to be practical enough for the solution to be actually implemented and used, in the real world, I need to
emphasis.

[pooya87]

That's impossible in my opinion because BIP322 and any similar proposal requires a lot of script related code that majority of tools don't have.

But we could get there incrementally. For example, validating P2PKH in BIP-322-compatible way is just a matter of getting some address, putting "76a914<address>88ac" in some field, and then it is only about hashing and concatenating some constants. So, for each Bitcoin-Message-based signature, it can be converted into BIP-322-compatible signature, and it would require only concatenating some constants, and hashing different things, but as long as some implementation allows concatenation and hashing, no more things are needed, and other cases could be handled as "not implemented", and then added later.

So, I think we should start with some BIP-322-compatible signatures, and then extend them incrementally.

But with doing that we'd be back at the beginning with what BIP137 already offers and almost all wallets already have an implementation for. Besides what you suggests sounds like requiring some hard coded values which means it will be a dirty code that won't be scalable which is the opposite of what we want in any new algorithm in my opinion.

[garlonicon]

Well, if we want to get it in a backward-compatible way, then OP_CHECKDATASIG is the way to go. But if we want to avoid introducing another opcode, then we could just use "<signature> <pubkey> OP_CHECKSIG", and always assume that OP_CHECKSIG will be checked with "Bitcoin Message" as z-value. But as the whole point is to make a signature without moving on-chain coins, I think even introducing OP_CHECKDATASIG is not a problem in this case, and can be beneficial, because then it would guarantee that such signed transaction will be invalid on-chain. For example, we could use "<signature> <message> <optional OP_SHA256 or OP_HASH256> <pubkey> OP_RESERVED", and then treat OP_RESERVED as OP_CHECKDATASIG, it will guarantee that it will be invalid if used on-chain, and will nicely remain valid, when not executed, and when it would be skipped by "OP_0 OP_IF ... OP_ENDIF".

[NotATether]

Signing with BIP 322 is signing a transaction except that the transaction contains explicitly invalid inputs so that it cannot be used as a real transction. It is not a signature in the cryptographic sense because just signatures themselves are incompatible with the vast majority of Bitcoin scripts. Rather it requires the entire witness in order to validate the script, which may or may not include signatures, depending on the script. Verifiers must execute the script in order to determine whether the "signature" is valid. It is more than just checking data in fields. Bitcoin operates with a scripting system, so any proof method that wants to allow message "signing" for arbitrary scripts must have a script interpreter.

So, now things are clear to me (at least for the the "to_spend" transaction) - we can now distribute two fields of message and that particularly-constructed transaction.

The worms then, seem to be coming from the "to_sign" transaction, because it is one that has the "to_spend" transaction input (which itself has an invalid transaction input), so the transaction verifier needs to be custom here.

[garlonicon]

The worms then, seem to be coming from the "to_sign" transaction, because it is one that has the "to_spend" transaction input (which itself has an invalid transaction input), so the transaction verifier needs to be custom here.

Yes. We need two transactions, because coins should be first created, and then spent. It is possible to handle everything in a single transaction, but then, it is hard to expand it in the future. For example, if you have SIGHASH_ALL, then everything is signed, including some invalid transaction input, so that would be safe in a single transaction. But if you have SIGHASH_ANYONECANPAY, then only one input is signed, and by doing that, your signature would be valid on-chain, even if you would have some invalid transaction input attached somewhere. For that reason, to provide full functionality, it is needed to use two transactions.

Also, using both of them makes it easier to extend this scheme in the future, if SIGHASH_PREVOUT_SOMETHING will be introduced, and if it will modify signed <txid:vout>, then knowing the previous transaction is needed to correctly prepare the message to sign. It is wise to control how coins are created, because then this scheme could be even more expanded, for example it could be recursive, then some signature will be valid only if someone else made a valid BIP-322 signature. Or, it could be possible to make it network-dependent, for example this to_sign transaction could be more expanded, and require N valid inputs, then it is possible to make a valid signature, only if N people agreed to create coins to sign.

[NotATether]

Also, using both of them makes it easier to extend this scheme in the future, if SIGHASH_PREVOUT_SOMETHING will be introduced, and if it will modify signed <txid:vout>, then knowing the previous transaction is needed to correctly prepare the message to sign. It is wise to control how coins are created, because then this scheme could be even more expanded, for example it could be recursive, then some signature will be valid only if someone else made a valid BIP-322 signature. Or, it could be possible to make it network-dependent, for example this to_sign transaction could be more expanded, and require N valid inputs, then it is possible to make a valid signature, only if N people agreed to create coins to sign.

So, the transaction-based signed messages are very powerful in that regard. But with great power comes with great complexity, and often times people will simply want to create a transaction-based signed message from whatever address they are using. (Simple accomplishes this already. I was going to ask why Legacy didn't include BIP137 signatures, but now I have my answer.)

* <code>message_signature</code> in <code>to_sign</code> is set to the provided simple signature.

What is this? The full signed transaction or just the scriptSig?

[garlonicon]

What is this? The full signed transaction or just the scriptSig?

I think it is just the scriptSig, because the full signed transaction can be constructed from other data. It is always created in the same way, so if you change for example transaction version, it will be considered invalid by BIP-322.

But with great power comes with great complexity, and often times people will simply want to create a transaction-based signed message from whatever address they are using.

For that reason I think you could start with concatenating constants. You don't need the full script to create "76a914<address>88ac", you don't need to know, what does it mean 0x76. You don't have to know it is OP_DUP. Many fields are constant, you can concatenate them first, and expand your implementation later. And I think it is better to start with some BIP-322-compatible placeholders like 0x76 than pick your own format, and then think hard how to expand it. If you start from Bitcoin Message and expand it, you will end up in a situation, where you will get Bitcoin Message compatibility, but the whole BIP will be more complex than BIP-322 if you will expand it step-by-step to cover signing scripts. So, making it a subset of BIP-322 is easier if you consider future expansion.

[NotATether]

For that reason I think you could start with concatenating constants. You don't need the full script to create "76a914<address>88ac", you don't need to know, what does it mean 0x76. You don't have to know it is OP_DUP. Many fields are constant, you can concatenate them first, and expand your implementation later. And I think it is better to start with some BIP-322-compatible placeholders like 0x76 than pick your own format, and then think hard how to expand it. If you start from Bitcoin Message and expand it, you will end up in a situation, where you will get Bitcoin Message compatibility, but the whole BIP will be more complex than BIP-322 if you will expand it step-by-step to cover signing scripts. So, making it a subset of BIP-322 is easier if you consider future expansion.

I think the best way to start with this is to write a small BIP322 signing and verifying program, and then a full-scale script interpreter can come later. It's going to be subject to change since it's still a draft, but we get the advantage of getting a peer-reviewed (C++) library.

[aliashraf]

"signing" for arbitrary scripts

This looks to me as being totally absurd, a byproduct of trolling. Who suggested it in the first place?  

According to the latest version of  BIP322, a twin of bitcoin script interpreter, verifies that a stupid, fake txn is supplied with appropriate witness data for unlocking its first input, which is a real outpoint of a real transaction, a message is supposed to be signed in this process, hence, 'tied' to the said outpoint. So, what this 'tying' implies?!  Nothing! It has has no meaning without examining the witness data more closely by an intelligent app/human being, interested in questions like what follows:
Is there any actual signature? How many signers? Are the signers, if any, the sole entities able to unlock the outpoint under consideration? If No, are they primarily supposed to be the normal destination, or they are relevant because of a backup branch in the script?
Without specific answers to such questions, the 'tie' established by "script signing" is worthless, bears no information, applies to no real use-case.

Oppositely and in a sharp contrast, for our, plain, old, (troll-frree) message signing, a verifier is absolutely convinced that an explicit, pseudonymous owner of a given outpoint has signed a message. Period.
You can't feed it a P2SH address, obviously, but when it accepts an input, it works fine, producing a meaningful result, unlike BIP322 scheme which fails to do it in any case, even with P2KH addresses! You have to check the address to be P2KH intelligently.
Believe it or not, your fancy BIP322 verifier should give you heads-ups, for your security when using it:

Warning:
This message is signed using a P2SH script, to understand what it means to be signed by the specific script behind this address,  you need to examine the script personally or using an AI powered application!

Warning:
This message was signed by a P2KH standard script, you are so lucky because you are able to understand what is the relation between the outpoint and the signed message, congratulations!


For our plain old message signing buddy, no further intelligent assistance is required.
Either a signed message is generated, and you can happily rely on it, or there is no confusing, meaningless signed message at all!  Though a  hypothetical extension to it is feasible, even necessary (Once upon a time, it was OP's agenda, but he eventually preferred not to stand by it, why should he? you want to have a BIP, don't you? Is it rational to mess with BIG guys?),  for supporting other opcodes, especially P2SH,P2WSH, ... are acceptable as long as the script behind them follows a standardized template that allows the same sharp semantics to be implied by signing a message.

It would be the only true generalization which complies with a software engineering design pattern that prunes wild trees of imagination, restricts supported features and utilities to be coherent and consistent, unlike BIP322 which is nothing more than a subjective generalization that fails to meet basic requirements.

Off-Topic

Disclaimer:
Annoying content, avoid reading if you are not in the mood.

Trolling, was a start but the reason (this derailed version of) BIP322 and specially the absurd sign-by-script slogan, got traction, was elitism which takes a while to be thoroughly assessed and analyzed for a dedicated group of researchers including social-psychiatrists, software engineers/architects, and other experts with background in studying micro-cultures. I'd happily accept a $$$$$$ grant for assembling and leading a team for such research, BTW.

A preliminary insight:
In a micro-culture, people mostly follow memes, no questions asked, no brain activity, kinda resembling dementia. Unlike patterns which are followed consciously and intelligently, for memes it is all about unconsciousness and ignorance:  something that is said carelessly, e.g., in an act of trolling, is found to be pleasant, ensuring, funny, ... then it is relayed and resonated to become a meme:

Bitcoin script is an electronic signature! (Good! Pleasant! We are using a superior technology!)

We actually sign by script when we use ESDSA to sign messages with bitcoin keys! (Pleasant! Ensuring! We are so much talented, we do abstractions and generalizations like nobody else in the planet!)

Let's go wild: sign/verify everything using our beautiful script interpreter! (Ensuring! Funny, We are exceptional coders! We will have so much fun writing (stupid) super codes that cover everything forever!)

Nonsense, crazy illusions, insulting 'others', claiming superiority, blah, blah. (Funny! As much as it strengthens our brotherhood, we enjoy it!)

[achow101]

This looks to me as being totally absurd, a byproduct of trolling. Who suggested it in the first place?  

Several people, actually. And no, it is not trolling, because it's useful.

According to the latest version of  BIP322, a twin of bitcoin script interpreter

Not a twin or separate implementation, rather it is the script interpreter. The implementation in Bitcoin Core uses the actual script interpreter used for actual script verification.

verifies that a stupid, fake txn is supplied with appropriate witness data for unlocking its first input, which is a real outpoint of a real transaction, a message is supposed to be signed in this process, hence, 'tied' to the said outpoint. So, what this 'tying' implies?!  Nothing! It has has no meaning without examining the witness data more closely by an intelligent app/human being, interested in questions like what follows:
Is there any actual signature? How many signers? Are the signers, if any, the sole entities able to unlock the outpoint under consideration? If No, are they primarily supposed to be the normal destination, or they are relevant because of a backup branch in the script?
Without specific answers to such questions, the 'tie' established by "script signing" is worthless, bears no information, applies to no real use-case.

That's true of the old message signing method too.

In the original message signing, you get a pubkey out at the end, not an address, a pubkey. An intelligent app/human must convert that pubkey into an address and compare it against the address that they were given. Depending on your verification software, you may have to do this comparison manually, Or the software might do it for you.

Furthermore, there are actually 3 addresses an ECDSA pubkey can become, so how do you know which the signer intends? Neither the original message signing nor it's extension in BIP 137 can guarantee that the address you are given is actually the address that the signer intended to sign with. The signature does not cover the component that indicates the address type, so how do you know that the signature and address weren't modified in flight to be one of the other address types? You can't be sure that the signer actually is capable of comprehending segwit, or that they know the redeemScript for p2sh wrapped segwit. The signature leaves a ton of ambiguity there and no amount of intelligent app/human can resolve that. So actually, it doesn't "work fine" at all.

Not all cases require inspection of the script either. One of the main use cases I've seen for message signing is to prove that a person has the ability to spend coins sent to the address. It doesn't matter which branch is used in the script to prove that because any branch can spend the coins. If you do want to determine that a particular branch was used, then yes, you do need to inspect the script. However tools like Miniscript make this much easier to do as it can lift script into a more human readable form, along with interpreting the witness to determine which branch was taken.

You can't feed it a P2SH address, obviously, but when it accepts an input, it works fine, producing a meaningful result, unlike BIP322 scheme which fails to do it in any case, even with P2KH addresses! You have to check the address to be P2KH intelligently.

You seem to have gotten BIP 322 and original message signing mixed up here. In original message signing, you have to figure out the address from the pubkey and compare it to what you are given. In BIP 322, it just fails if the address provided is wrong.

In BIP 322, you don't provide the first to_spend transaction that would contain the output script. Rather you give the address, and the to_spend transaction is computed from that, with the output script being filled in from the address. When script verification is run, it needs the output script in order to work, and the wrong script means that the whole thing will fail. No intelligence required on the user. No need to check the address separately from the verification algorithm described in the BIP. This is, in fact, a more meaningful result for just P2KH addresses than the original message signing. It guarantees that the signer signed with that address because script verification requires signing the output script.

[garlonicon]

This looks to me as being totally absurd, a byproduct of trolling. Who suggested it in the first place?

You can check the author of BIP-322: "Karl-Johan Alm <karljohan-alm@garage.co.jp>".

You can ignore BIP-322, and focus on Bitcoin Message instead. Then, you will notice, why it is incomplete:
1) It is defined only for P2PKH legacy addresses. If you have any other public key, you have to convert it into legacy format first, and then validate it.
2) It is limited only to legacy ECDSA signatures. You cannot easily make it compatible with Schnorr signatures and Taproot addresses. In practice, handling Taproot at all is hard inside Bitcoin Message, because P2TR is a combination of pay-to-public-key and pay-to-script. You can limit it into public keys, but even then you have to invent a new version or something to distinguish between legacy ECDSA signatures and Schnorr signatures.
3) It cannot be used to validate outputs produced by the Lightning Network. If something is timelocked, then Bitcoin Message cannot handle it properly. You need to define another version for handling HTLCs, and nothing else.
4) It cannot be used to validate signatures for a combination of some public key and some preimage. If you have "OP_SHA256 <hash> OP_EQUALVERIFY <pubkey> OP_CHECKSIG", then it is spendable by providing "<signature> <message>" in the input.
5) Each and every new script will require modifying Bitcoin Message to handle it separately.

So, it is all about expanding Bitcoin Message. It can handle legacy ECDSA signatures, and pretty much nothing else. So if you made any kind of Bitcoin contract by using Script, then Bitcoin Message cannot handle it properly. On the other hand, if there would be another soft-fork, that would define Segwit addresses for version two, then BIP-322 can be easily extended to cover that. But when it comes to Bitcoin Message, it is very limited, and you will endlessly reach the same problem every time, when you will see any new kind of Script.

Edit: Also, it is hard to make sidechains without things like BIP-322: you have to interpret the Script, in other case you will end up in a chain, where you can move coins in, only if you move them to some public-key-based-address first. So, depositing coins from Lightning Network to the sidechain is impossible if you cannot handle 2-of-2 multisig correctly.

[aliashraf]

According to the latest version of  BIP322, a twin of bitcoin script interpreter

Not a twin or separate implementation, rather it is the script interpreter. The implementation in Bitcoin Core uses the actual script interpreter used for actual script verification.

It is just true for Bitcoin Core, how is it supposed to be implemented by third party wallets and services, or maybe it is never going to happen, right?

verifies that a stupid, fake txn is supplied with appropriate witness data for unlocking its first input, which is a real outpoint of a real transaction, a message is supposed to be signed in this process, hence, 'tied' to the said outpoint. So, what this 'tying' implies?!  Nothing! It has has no meaning without examining the witness data more closely by an intelligent app/human being, interested in questions like what follows:
Is there any actual signature? How many signers? Are the signers, if any, the sole entities able to unlock the outpoint under consideration? If No, are they primarily supposed to be the normal destination, or they are relevant because of a backup branch in the script?
Without specific answers to such questions, the 'tie' established by "script signing" is worthless, bears no information, applies to no real use-case.

That's true of the old message signing method too.
In the original message signing, you get a pubkey out at the end, not an address, a pubkey.

It is not a failure of our old friend, it is part of the specification. Tying transactions to signatures, is a new feature, adding new features is always possible, but specific measures should be taken both in the definition of the requirements and in the design process.
On the other hand, for now, this 'new feature' is suspected to be artificially invented for justifying the "sign-by-script" idea, where, as I've mentioned before, it claims:
Tying a message to a txo as metadata, is the only relevant application of message signing with bitcoin keys.
Which is absolutely wrong:
First and foremost, this so-called 'tying metadata'(!) is not that important, if it is relevant at all, in the context of 'signing'. The common application is, and has always been, proving authenticity, data integrity and non-repudiability of a message, using bitcoin keys with a possible reference to a txo in the blockchain, if the owner finds sych a reference useful. i.e., the main application is using bitcoin as a public key infrastructure. In the concrete world we are living in, (not the abstract world created by the above claim) signed messages are not supposed to be 'metadata' of a txn, signing is not binding anything to any other thing. It is just about authenticity and other characteristics we mentioned above.

One of the main use cases I've seen for message signing is to prove that a person has the ability to spend coins sent to the address. It doesn't matter which branch is used in the script to prove that because any branch can spend the coins.

it is not a use-case, just an imaginary scenario, projected from the solution domain to the problem domain, in an upside-down world. Interestingly, even this "use-case" is not fulfilled by the design:
I provide your application with a utxo reference and a proof bound to some message as being a "sign-by script" BIP322, convincing it, your app. that I'm able to unlock the said utxo, right?
Now what? Your application decides to give me a credit or something, either with respect to or ifnoring the content of my message? Who am I? The one who provided the proof? How this scheme is supposed to resist a simple man-in-the middle attack? What happened to authenticity? What about non-repudiation?
About branches being irrelevant the way you put it:
I'm afraid, you are missing the point; Once you abandon the original meaning of signing a message in favor of "tying metadata to a txo", by using scripts instead of  keys,  you have no choice other than processing/using this metadata, someday, somehow (otherwise it deserves no label other than "absurd"), hence you need to know how viable this metadata is, and how exactly the unlock process has taken place.
The point being that, you have no clue about the script under consideration, you shouldn't have such a clue, the whole scheme falls apart with such a dependency. It is why this scheme never works as a general signing mechanism, it is a dependent, application specific, utility which by no standard is supposed to be called a "signing" mechanism. It has nothing to do with signing per se.

Please stay focused a bit more, it is just the beginning of my criticism:
Even the loose defined concept of "binding metadata to UTXOs" being considered a serious application, it doesn't force us to adopt BIP322!

Engineers would merge it with established ES concept, (making lemonade with the lemon) by applying 3 constraints:

1- Restricting the problem domain to well-formed, standard scripts, either built in or external.

2- Restricting the message to be well-formed in an application specific sense, though.

3- Enforcing general compatibility of the metadata under consideration to be authenticated, non-repudiable, integrated using a supported ES scheme with explicitly distinguished public key(s).

Now, it'd be easy to implement without ruining everything in the name of generalization or abstraction, one should take care of such practices not to go excessively wild, turning to be useless and absurd.