Topic: BIP 322 draft design and improvement thread (Read 830 times)

No he isn't. In fact all the important technical stuff is being discussed in this pull request: https://github.com/bitcoin/bips/pull/1347 and on the bitcoin-dev mailing list.

Admittedly the proposal hasn't had much talk since around 2022.


I actually don't have his email address, or at least, I don't remember if I ever used email to contact him (It was mainly by Github). But you should be able to get an audience if you post this on the mailing list now that it's moved to Google Groups.

Indeed.

On one side, I gonna talk with 2 Bitcoin developpers in May about this use-case. Maybe will they talk further about it.

On the other side, I thought Kallewoof was following this BIP322 thread. If he does not, sending this use-case in an e-mail is a good idea.
Would you like to do it, considering your started this bitcointalk post? If not, I gonna send him an message this week. (Just so you know: I don't have his e-mail.)

We are going to need to do a lot of advocating if we are to get any BIP merged into the Bitcoin protocol at this point. Nowadays the only things that are merged are stuff that gets many months of deliberations on the mailing list, and also it's going to need a working implementation and nobody can work that the way Kalle (the author) can.

I suggest sending your BIP322 use case as an email to him and that should generate at least some attention to the practical use of BIP322.

Hello guys,

In the past few weeks, I spent a few hours researching a way to sign a message with a multi-sig wallet. After a lot of tests, I discovered the Bitcoin #322 Proposal.


    
As a Bitcoin association, whose goal is to educate people about Bitcoin in our city, we enable everyone to become a member of our association for a few thousands sats per year. To do so, we use Swiss Bitcoin Pay.
It's an app' which enables us (and shops too) to export easily our accounting if needed. We also onboard merchants with this app', 'cause it's UX friendly, very easy to use too, self-custodial; and the accounting part is very usefull in lots of countries.


The problem is that we use a multi-sig wallet, as some other associations and companies.
However, as I previously said, it's currently impossible to sign a message with a multi-sig wallet, 'cause BIP 322 hadn't been pushed for a few months / years.

It also means that we can't prove that we own an address by signing a message with our multi-sig wallet; which is an information asked in some regulated countries (in Switzerland for example). It's not a KYC thing, just a "proof of addresses ownership".


Not being able to sign a message with a multi-sig wallet is also a lack in our Bitcoin ecosystem, and I hope it gonna change in the next few weeks / months.

    

Atm, I only spent a couple of hours learning about how Bitcoin signatures work.
My only discovery is that the ECDSA function is neither linear, nor commutative. If it was, the solution would have been very easy to implement.
Got a couple ideas, but I need to go further in my researches and understanding of ECDSA.


To sum up: if this thread (and BIP) was forgotten, please make it live again. We need that in our ecosystem.

Bumping this as I got word that the BIP322 man himself (kalle) is lurking around, so collaborations on the design and implementation should be possible right now.  

Yes, you can easily hide public keys that their exposure is not strictly necessary with MAST:
For 1 of n signatures, unlike legacy Bitcoin script, you will have n identical leafs such as OP_CHECKSIG for each pubkey.

To spend the P2TR outpoint, or for what you are interested in (proving to be relevant), holders of each key should include log₂n - 1  hashes (Merkle path) and only their own public key, besides the signature as witness.

Yeah, like I said, this is a good idea and I will study how P2TR spending works. I just had a dive into BIP341 this morning, and there's a lot of stuff to go over in there.

I just have one question about Taproot branches:

When you're making a witness stack, the public keys for the other cosigners don't need to be on the stack? [that's really the only way I see the keys being hidden, unless I'm missing something here.]

Just use P2TR and reveal one of N TapScript branches, then all other public keys will remain hidden. Also, if you have 1-of-N, then you have two cases:
1) you don't care who signed the message
2) you want to know, who did it
In the first case, people could spend by key. In the second case, people could also spend by key, but include a commitment in R-value of their signature, then it would be possible to check, who signed that. Unless you want to force that, then you can force people to spend by script, and place N-of-N key to allow spending by key if all people will agree.

Alright, so maybe I won't need proxy signatures at all. Besides, that's going to take us dangerously close to altcoin-frontier. Here I have a not-so-private way of creating a signature delegations using only constructs already defined in the protocol. Not so private, because it uses multisig - all public keys are revealed. I was hoping that something like MuSig or key aggregation would help with this but its still a draft.

It is extremely simple and doesn't require any additional transactions:

- Replace the message challenge of "to_spend" with a 1-of-N standard P2WPKH multisig. N is the number of people you want to be able to create the signature, and their respective pubkeys are included in the script.
-- In this way the possible delegatees are fixed at signature creation time and cannot be extended by creating more transactions.
- Replace the challenge solution in "to_sign" (it's the input that spends the output we made in "to_spend") with a witness stack containing: n ... 1 0
-- The signature is generated as if it were for a real P2WPKH-multisig transaction. [the zero at the end is due to a bug in OP_CHECKMULTISIG that pops an extra element].

appendix - don't mix up this delegation and Full with UTXOs together - it increases the numebr of permutations that implementations have to verify.

Pros:

- No recursive transactions.
- Faketoshi cannot forge a signature that verifies successfully - he does not know any of the private keys in the multisig.
- The Address field is not used when delegating, so the engine can actually print which (compressed) public key it is signed against - i.e. the address verification is provable, as opposed to reactive Legacy signatures.
-- Additionally, they will all be Segwit Bech32 addresses so it can just derive and print the corresponding bc1 address instead.
- There is no opcode or new algorithm introduced, so no soft-fork is required.

Cons:

- Everyone knows the public keys of the delegators, so there is no privacy.

---

I am satisfied with this - barring any other complaints about BIP322, do you guys think this scheme is simpler than the one I made yesterday?

It was a more general complaint regarding OP's extreme practicism (as I see it) not any specific topic. OP doesn't like questioning BIP322, feeling an obligation to implement it in a rush.

As for sidechains, well I'm a fan as long as they are not deviated from basics, for instance I wouldn't contribute to RSk because they have adopted Turing completeness which is inherently vulnerable, for instance check what is happening with Ethereum: only 2 or 3, besides Vitalik's Foundation, are in charge. Just check what the rock star says:

It is what happens when you have Turing completeness and smart contracts full-blown, corporates decide everything, the decide who is allowed to fork or not to fork. The hilarious point about the situation with Ethereum is the fact that Vitalik and the gang are forking, not the other side!

It is what I believe in bitcoin to be colonized as its side chain, almost the exact same bitcoin, I mean.

It is based on vjudeu's idea: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-February/019988.html
And he later also wrote more posts about that.

Why? Bitcoin is so resistant to changes that sidechains should be introduced by no-forks, because they won't be accepted as a soft-fork. And this proposal is also a no-fork, so you can think about it in the same category as HD wallets and similar BIPs. Bitcoin is so resistant to changes that hard-forks are practically impossible to introduce, soft-forks are very hard to introduce, and you complain that Bitcoin is "defenseless"? The strongest defense is just sticking with what we have and rejecting any new proposals. And you know that people can always do that, and it will only escalate, so more no-forks will be needed to change anything.

I feel, that while this scenario is entirely possible (provided that the adversiary somehow finds people who are willing to code and think*), we are doing a disservice to bitcoin by not making an effort to standardize parts.

*In the age of social media and tiktok, such people are rare - divide the number of posters in Dev&Tech discussion over the week, by the number of Bitcointalk users online within the last week - you get the idea.

---

This whole endeavor would've been unnecessary had my BIP just been numbered by luke-jr in the first place, but he didn't, and this is not the thread for me to rant about that. Decisions are decisions, and if the standardization for some part can only be done in a specific way, then I will push in that direction in the name of change (which I feel is infinitely more useful than me making a hundred posts in this thread).

I'm operating as a lone wolf - certainly, almost nobody else on this forum has the technical compretence to even do anything about these drafts (judging by the number of users who replied to this topic in the last 2 weeks). Sure, this implies you have to trust me not to fuck standards up, but I know, that I can definitely trust myself not to screw up, and to me that's all that really matters.

Sure, if delegation is not needed in the first place, somebody on the mailing list can speak up, and that'll be the end of it. But so far the mailing list has been almost radio silence for the past week except for myself. So I, an independent guy unaffiliated with the BIP, have no idea if any of the TODOs are still valid.

So this is the game plan now:

- in the case of delegation, I look up @garlonicon's idea. If that doesn't work out, I've already found a well-known cryptography construct called proxy signatures (Brave search link, only because google's was too long and DuckDuckGo has the search query in the POST data - ignore all results about HTTP proxies) that solves all these problems without supporting ugly recursion, so I make a BIP around that.
-- It will primarily be used by BIP322 if the author(s) can come at a decision about it.

And then I leave the problem alone, since everything is solved - no need for opcodes, Merkle Branches or any of that weird stuff in the other TODOs.




Yes, I know about resistance to no-coiners. But in this parliament, there is no seat for them, since the community never elected them here in the first place. Therefore, all of their criticisms and attacks are irrelevant to us. There's a seat for you, there's a seat for me, seats for some of these other guys here, seats for mailing list posters, etc. because the community wants us (collectively) to discuss and find solutions for these matters.

Ultimately, nobody has execution power over BIPs that they did not author. I'm not an exception. I can't "force" anybody to include my suggestions in their own BIPs.

@NotATether

Wandering in the woods is beyond any Bitcoiner. We are not hired by anybody, there is no obligation to follow TODO assignments by BIPs just because they've got some stupid number.
More importantly, your approach compromises the very first line of resistance for Bitcoin: dev resistance.

I can imagine an attack like this:
1- The adversary recruits an army of average programmers, sending them to Bitcointalk, Reddit, the mailing list, GitHub, so forth.

2- The shills are rewarded based on the credit they grind in communities they are active.

3- They earn credit by minor contributions they make, while they enjoy free technical/editorial support for their contributions, to follow adversary's strategy.

4- It takes some time, but eventually they manage to penetrate and start pushing weird ideas and BIPs, providing the necessary foundation for adversary's main project, which has been lurking in the shadows for the right moment to become public.

I have no trust in anybody to be comfortable with just following the orders, I do my own research, I have my own vision, IDGAF.

What makes me upset about your style is not its conformance with the above adversarial scenario, I don't go that far. No, you are not hired by a penetrator, but what you are doing is bad for the resistance, it makes us to look weak and irrelevant, leaving bitcoin defenseless. With all the hypes and threats, it is the worst time for us to be distracted by BIPs and TODOs.

Again: Keep it low and slow, that's the tempo.

I didn't previously know about this - I will research this more and see how to design a alias scheme around this.


Well yeah, I obviously wasn't intending to introduce GPG anywhere, that was just a reference to make it easier for others to see the problem. Encryption is not needed anyway - it was the signing capabilities of GPG that I was comparing.


I can, I just didn't research P2TR thoroughly enough to use it for anything. But the potential is there.

This problem was solved by commitments and by multiplying public keys by private keys: if you have a commitment, then one person doing regular Bitcoin transaction, could tweak R-value of the signature, to attach N Taproot-based commitments. Then, people could take that R-value, and try to match Taproot-spending-script to this public key. If it matches, then this commitment is valid.

When it comes to encryption, no GPG is needed, you can stay in ECDSA, Alice can calculate alicePrivKey*bobPubKey, Bob can calculate bobPrivKey*alicePubKey, and they both can reach a shared public key, and then symmetrically encrypt things with AES-256.

Why not P2TR? I think in all new stuff you can safely assume that Taproot is present, active, and somehow implemented, at least to cover spend-by-key.

I am not an expert in the various use-cases I stated for this, so I will make no attempt to reply to any of that.


No, this was in older revisions of BIP322 as a TODO, one of the unaddressed "edge cases" if you want to call it that.


Yeah well if I don't do something about it (read: write specifications for dealing with it, write code that uses it, maybe tell Blockchain Commons that there are people who are actually interested in helping out with their BIP322 efforts), then nobody's going to do anything about related problems.

Because everyone has this kind of attitude that "If nobody replies to my proposals, that must mean they are garbage" - which is wrong because perhaps it's a good idea but the decision-makers for that particular proposal haven't seen it yet  (It is worth mentioning that I have no clue if Kalle has seen a single one of my mailing list or Github comments). It's thankless work, because for all the pitchforks thrown in your general direction, you get virtually no credit at all - but I'm not here for credit, I'm here for progress and advancement of Bitcoin. And it's the only reason why I'm still continuing these efforts.

And, if you don't do anything, progress grinds to a halt [and, if this non-activity extends to maintenance, then you don't just have a "maintenance-mode" project, you end up with a completely abandoned project].

In this space, and any other truly open-source space, all the work is decentalized. Take that away and you don't truly have an open-source project anymore - at worst you have some quasi-OSS like Microsoft's and Google's stuff (source code is accessible, but suggestions and final decisions are made behind closed-doors).


Their definition of "delegation" is completely different from the one listed in the BIP (although incidentially, the solutions are both loosely derived from the same mailing list post):

- CoinGeek's is: "Alice allows Bob to spend her UTXO on-chain"
- Mine is: "Alice hides her UTXOs behind an invalid, off-chain output which can sign a BIP322 transaction"

There is a huge difference here. It is indeed foolish, and very risky, to design some protocol that allows other people to spend your money. It would be no better than a smart contract. In fact, their's is a smart contract, whereas I have explicitly stated that my schema is not one.

This "signer delegation" that I'm talking about in previous posts, does not allow a person to spend anything, it hides the original UTXOs from the signature and only allows other people to sign a message on their own behalf.

All this without revealing any private keys to anybody - the delegated has to solve a challenge script to sign the message.


In 99% of real-world cases there is no need for multiple chains of delegations, a single delegation transaction will suffice. Once you read the pesudonym example below, you'd see that the 1% cases would be like "making an alias for an alias for a person" (e.g. suppose Satoshi makes a new nickname).

BIP322 signing has always been P2P, there is no central entity involved.


Again, there is no delegation of authority from one person to another in this scheme. We are merely hiding the address(es) behind some operation that combines them together to make a new address. The TODO says this is for "better CoinJoin and Lightning compatibility" - although it is possibly redundant according to your statements about these two technologies, it has to be introduced in a way that they can make use of BIP322 signed messages if they want to in the future. A third technology could be invented in the future on top of CoinJoin or LN that requires BIP322 signatures for correct operation, that's why.

In this sense, it's not really "delegation" in the traditional sense at all - we're just hiding the original signers' identity behind a pseudonym e.g. "Satoshi Nakamoto".

True this scheme is not perfect - it assumes a trusted public - because anybody can claim the pseudonym i.e. claim to own the delegated address - so in the example for pseudonym this would be solved by introducing a GPG key alongside the pseudonym's posts - I'm working on a similar way to solve that particular problem with this proposal.


Actually, the BIP never mentioned the word "person" in that TODO, so this was merely an assumption that I made, and this never really made any sense until I thought about this problem and realized that it's not attempting to delegate control to different people, but to different aliases.


You almost got it, but the signer attaches the delegation tx to the "to_spend" tx. The Message/Address/Signature tuple contains the witness stack for unlocking the sole output of the "to_delegate" tx.

Currently, only "to_spend" is verified by others because ther is no info to verify the delegation tx. I'm going to admit that this is a problem that needs to be solved, by giving the alias its own keypair i.e. identity (this will mean using P2WPKH instead of P2WSH).


On the web pages of course. Legacy signed messages were never stored in the blockchain anyway.

---

TL;DR

This is not truly "delegation" as other people call it, but the problem of hiding of signer's identity behind a pseudonym, so that he/she cannot be fingerprinted and monitored by spies.

Why did BIP322 call it that, then? I don't know. But this seems to be the meaning that is implied.

Look, I know that you don't like BIP322 because of the way it looks, but by any means, somebody has to make a message signing solution that not only works technically, but has the general consensus of all technical people.

edited for spelling

edit 2: In fact, in light of this, I can simplify the proposal a little bit:

- Instead of a P2WSH output, "to_delegate" creates a single, standard P2WPKH output withits own keypair.
- In a "Full with UTXOs" signed message, the outputs to be proven are already inside the "to_sign" inputs - meaning they are fully included in the signature and can be verified - if any of these inputs want to hide behind an alias, they only have to generate a new keypair. Then make a "to_delegate" transaction which has:
-- an invalid input
-- one or more UTXOs as input
-- a single P2WPKH output with the generated keypair
Which resembles a normal transaction but it's invalid because of the invalid input. This specific tx is not verified as that would be equivalent to "revealing the identity of the alias".

Now "to_sign" transactions can have this alias UTXO as an input instead of all those UTXOs that want to hide their identity.

I do not believe it is possible to fully prove that an entity really is the alias it claims to be: That would be tantamount to the "do you believe XXX is satoshi" problem. So the issue of forgery will always be there, so "delegation" in the form I specified must be restricted to specific use cases where all parties are trustworty (e.g. signatures shared with a limited subset of entities like a CoinJoin, not so sure about what else could benefit from this).

Is there something known as delegation problem or you have figured it out as well?  

I appreciate your commitment but if you don't go with a bit slower and lower tempo, it becomes noisy, and eventually spammy, in the worst sense, as you wrap it behind innocent even formal technical stuff, as if there is a real problem, and you are doing your job, as a dev or something, to deal with it, which is absolutely misleading in its entirety, kinda covert spam.

Google it, "delegation problem", to find out that there is just one bitcoin related reference to such thing, and it is Faketoshi backed, nothing more than a scam advertisement!

Interestingly, still their work is more elegant than yours! They propose a same chain of delegation by signing stupid messages recursively, where it is supposed to convince users of a (centralized) entity that they have some authorization on behalf of the original signer.

No matter how anybody would solve or implement it, the sole fact that one is concerned about delegation of authority, puts her out of the bitcoin circle, why? Because, there was actually a delegation problem, i.e, delegation of control over funds; Bitcoin solved it unlike cryptography that had failed it for decades. Resurrecting it, for suggesting an imaginary cryptographic solution, is nothing other than breaking with bitcoin under its umbrella.

Oh, poof! BIP322  

It is crazy. How this delegation is going to be verified and approved anyway? By attaching the previous stupid txn(s) of BIP322 to the current stupid txn? Otherwise, the poor verifier from where should obtain the first one??? Remember, they are not going to the blockchain, so where are they? In Faketoshi Wright's private DB?
Pure nonsense, it is so anti-bitcoin that makes me truly sick.

"Scamming people by presenting it as a bitcoin development with a covert right to double-spend", answered  CSW while blinking  

Proving liquidity to whom? How?
We have nodes pared with each other in channels, each being fully aware of the balance/liquidity available, there is no way for any third party to be aware of this status unless it is running a sophisticated multi-node attack to monitor the fee circulation and other statistics. Publc channels voluntarily advertise their status through gossip protocol, but it is not provable by any means to anybody.

It is also a non problem.
Modern coinjoin services do not rely on liquid providers, thanks to Schnorr blind signatures, CoinJoin is now fully trustless and private, Wasabi Wallet for instance makes it possible for users to join their txns without relying on a liquidity provider middleman.
[/quote]

Sure, not to mention being useless.

Nice catch. I should probably update the corresponding mailing list entry.


I could've just used OP_RIPEMD160, but I followed the example of P2WPKH-P2SH where the address hash is hashed with SHA256 and RIPEMD160 to create a new, nested address hash, so I prefer to leave it like that.

---

There is actually one flaw I found in this scheme - it's that you can't verify that the message is indeed signed with the UTXOs, because they are not even known.

This stems from a tradeoff where you can't have both the privacy of delegation, and verifiability of the delegation, at the same time.

I'm not sure what to do about this.

[I should probably collect all this info on my website instead of dumping it all on the mailing list]

Just use "OP_HASH160 OP_PUSH OP_EQUAL". This OP_VERIFY is needed only if this part should be concatenated with something else as " OP_VERIFY ". Also note that OP_HASH160 is in practice "OP_SHA256 OP_RIPEMD160", so you could use OP_RIPEMD160 instead of OP_HASH160, and then just push 256-bit hash, reached as SHA-256("something").

OK, I just figured out how to solve the delegation problem.

In BIP322, there is a [planned] provision for some person to delegate signing to another person. That means the second person can do all the signing stuff that the first person could do, and the signature is as if the first person signed it.

What this could be useful for?

- L2/Lightning Network, a channel is just 2-of-2 multisig, so a prospective channel co-creator "delegate" signing to the channel itself, by signing a UTXO inside the multisig - signing along with the other party, creating a dummy output (see below), which can be signed to prove liquidity on behalf of the channel, while keeping the channel itself anonymous.
- CoinJoin, To prove that some CoinJoin coordinator is liquid without violating its anonymity by revealing public keys, the person managing the CoinJoins delegates signing from all UTXOs to be used in the CJ, at once, delegating signing to another dummy output.
- By the same token, Mixers can prove their liquidity without revealing their UTXO set.
- Silent Payments, where the public key is not even known in the first place, the address of a silent payment can delegate signing to another dummy output which only the sender and receiver know about.

So how does this delegation work? It's very simple:

1. All UTXOs that want to delegate signing to a different party must sign a preliminary transaction of this format:
- All input/output amounts are zero.
- input 1 is an invalid input of the kind in BIP322
- the rest of the inputs are the UTXOs wanting to delegate signing to a different party, with valid signatures/witness stacks.
- there is only one output, and it is a P2WSH output with the following script:
OP_PUSH OP_SWAP OP_HASH160 OP_EQUALVERIFY
- And the witness stack that will "spend" the transaction in the "to_spend" tx is simply:

- Likewise, the "to_spend" tx has only one input, refering to the txid of the delegating transaction with output point 0 i.e. the UTXO :0. Outputs of "to_spend" remain the same.
-- Contrary to the use of Hash160, we are NOT hashing a public key or script. We are hashing an address hash, implying that we are using addresses.

Do you know why I said "delegating to a different party"? Because it could be a functionally different entity, just like how CEO is diffferent from LLC company even if it has only 1 employee. The "address" here represents a kind of company - it can represent a channel, it can represent a coinjoin, it can represent a silent payment. The channel/CJ/etc. only has to hash the decoded RIPEMD160 of an address, with another SHA256-RIPEMD160, to make an "address" that can be used to sign messages from.

This "address" aka. LLC company can even be encoded with Bech32 to make it look like a real address - obviously don't send any funds directly to that address because they will be lost - and in fact, it *should* be Bech32-encoded when transmitting the Signed Message.

A signed message has these three parts:

Message
Address
Signature

BIP322 specifies the signature is just the raw transaction format of "to_sign". Normally, the address would simply be the address you are signing from, but in the case of delegation, it is desireable for the original addresses to remain anonymous. So since an address must be filled in somewhere, the Bech32 "hash-of-address-hash" created above can be used as a P2WSH address.

Advantages of this scheme:

- The real addresses/UTXOs signing the transaction are only known to each other and whoever is managing the "to_delegate" transaction.
- Only the real signers and the person who is in charge of the P2WSH output can sign the "to_delegate" output and thus sign a message from it (note that they could be the same person).
- There can be an arbitrary number of delegations before the transaction is actually signed (the new person who is in charge of signing, i.e. has the P2WSH output of the "to_delegate" transaction can simply generate another address hash, and delegate to that "address" in another transaction, giving some other person that "address" if they want to)
- Delegated signatures can wrap Full and Full with UTXOs signing formats, so Light clients do not have to directly support those two formats, either for complexity reasons, or because they have no UTXO set.
- And crucially: **There is no on-chain transaction, so the delegation is private and cannot be traced back by the public**.

And there are virtually no disadvantages to this.

I should emphasize that you don't delegate signing to another person, you delegate signing to another party that may just be comprised by one person. I say this because the delegation does not make any new on-chain UTXOs that someone could posess, but it simply creates a hash160 of some address hash that was generated by the delegators, and the hash-of-address-hash does not necessarily have to represent a person, it can also represent a service.

FAQ:

Q: Does this utilize the Full format?
A: Yes.

Q: How to represent the delegation in a signed transaction?
A: Just encode the hash-of-address-hash in Bech32 version 0 and put it in the Address field.

Q: If the delegation is private, then how can the address-hash be known and the transaction signed?
A: The UTXO signers take a random address associated with them and then make the hash160 of that address. Whoever they give this to, can sign a BIP322 transaction.

Q: How can the public verify a delegated BIP322 transaction if the address-hash is private?
A: The hash-of-address-hash is revealed in the Address, not in the Signature. BIP322 states that the signature only contains the "to_sign" transaction, which does not contain the witness stack of "to_spend" that has the hash-of-address-hash (because THAT was already spent in "to_spend") therefore the address hash is Bech32 (version 0) encoded and can be decoded to re-construct "to_spend" transaction and from there "to_sign".

Q: How to differentiate between non-delegated and delegated signatures?
A: You can't. But then again, BIP322 doesn't differentiate between "message signatures from an address" and a signature from a set of UTXOs so it wouldn't be able to identify a delegated transaction anyway.
Rather, a full-blown verification software should present a list-box or a set of radio buttons, that toggles between "Legacy", "Simple", "Full", "Full with UTXOs" and "Full with Delegation" - Each of these controls the content in the Address field - this would already be required to support validating Legacy signatures anyway, which are otherwise incompatible with the transaction-based signing (and this is the workaround BIP322 specifies to support that).

Q: What if the verifier does not have a UTXO set (light clients)?
A: Then present three toggles or radio buttons: "Legacy", "Simple", and "Delegated" - each of these options only require a single encoded address to be specified in the field, and Full, and Full With UTXOs signatures can be wrapped with a delegation to support a single address. Consequentially, these control how the signed transaction is [re]constructed for sign/verify.