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).