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

yalla shoot

Well, it is used in Signet. If you compare, what is signed in Signet blocks, and what message is signed by this BIP, then you will note, that they are similar.

My conclusion is, that if you start a new regtest node, mine some coins on the desired outputs, and then ask someone, to sign specifically those outputs, then you will get roughly the same outcome, as you can get from this BIP, but easier, and with already working implementation.

Is BIP-322 a failure case? Is it unfinished and isn't there any conclusion?

(https://github.com/bitcoin/bips/pull/1347#issuecomment-2092033174).

There is "simple" variant (taggedHash "BIP0322-signed-message") implemented in Sparrow: https://github.com/sparrowwallet/drongo/blob/f8f50c0dd907fac674ea363443b96772b6a0b658/src/main/java/com/sparrowwallet/drongo/crypto/Bip322.java#L18
and
https://github.com/ACken2/bip322-js
and
https://docs.rs/bip322/0.0.7/bip322/.
Anywhere else?

(I haven't verified if the implementations above are compatible).

I am grateful to aliashraf for thoughtful analysis and suggestions.

In general, if you can sign a message with a single key, then you can do so with multiple keys, just by including multiple signatures. For example:
And then, you can say that both keys were used to sign the message "Hello World". But I think, using regtest transactions may be a better idea, because it provides more context into what is actually signed. Because in the classical "Bitcoin Message", you have to make sure, that signed data cannot be manipulated, and are for example committed to the public key. Because in other cases, you may also have valid signatures, created from unknown keys:

Thanks for your response. I've been requested in the Github BIP 322 thread to forward this to the mailing list. I've taken care of it.


If you have any information or bitcointalk post about it, please let me know. Currently, I haven't found any way to sign a message with a n-of-m multi-sig (n != m).

[EDIT]
Here is the discussion on the Bitcoin mailing list: https://groups.google.com/g/bitcoindev/c/RCi1Exs0ZvQ

@vjudeu: I think some example is worth sharing:



This is our coinbase transaction for the first block. It will be identical for those commands above, only block headers may be different, but it doesn't matter in our use case:
We import some kind of descriptor, which we want to use. For example, this is 2-of-2 multisig with the first two public keys, with well-known private keys:
Then, we can get our destination address for that descriptor:
Now, we can send those coins into that output:
This is sufficient as our "to_spend" transaction. But we can add something more, and put for example some OP_RETURN, and describe here the purpose of our signature, include SHA-256 of some message to be signed, or do anything else. For example, if we want to sign an empty message, then we can do it like that:
And then, when we decode it, we can check, if we are satisfied with our "to_spend" transaction or not:
We are almost there. The first transaction is something, which is ready to be broadcasted, because it spends some input with OP_TRUE, so we don't have to sign it (but we can pick a different coinbase script, to have well-separated networks, if we need it). The second one is something, which can be signed as usual:
So, we got it. Now, we mine a new block with both transactions to see, if they will be included or not:
And then, we can get our block:
Voila. This is our signature. For the recipient, we have to share only the first, and the last command. Which means, that if you want to verify a signature, then all you have to do, is to execute those two commands in some empty regtest network:
As you can see, the hash of the block will be different each time, mainly because of timestamps. But: if you explore the contents of the block, then it contains exactly the same "to_spend" and "to_sign" transactions. And if you import your multisig descriptor, you will see your "to_spend" transaction in the GUI (if you want to also see "to_sign" transaction, then you have to add some additional output, which will contain one of the keys from your wallet).
So, as you can see, you can create some transactions, which are similar to BIP-322, even if slightly different, if you just use regtest for that purpose. And I think it should meet most of your requirements, as long as BIP-322 is not finished.

I guess you can send it now. Messages in the mailing list are published with a delay, because they are reviewed, and accepted by humans. Which means, that even if you send it now, then don't be surprised, if it will be published tomorrow, or three days later. It is normal. Some people are surprised, and think, that "hey, they censored my message", but very often it is not the case, and the message is later published.

It is possible, but tedious. If you can sign some message with a single key, then you can do it with multiple keys, just by providing N signatures. Unless you deploy N-of-N multisig, wrapped in Taproot address, then a single signature is sufficient.

The reason is quite simple: writing code is hard. It requires time and knowledge. And if you have an Open Source world, then people spend their free time, usually without any reward, and they implement things, as they see fit. So, if that was not yet urgently needed by anyone, or if those who needed it, used simple workarounds like "just produce N classical Bitcoin Messages for each public key separately", then just nobody was determined enough, to finish it.

Also note, that there are some workarounds, which are close to BIP-322, but have just slightly different format. For example: you can run regtest, mine 101 blocks, move the coinbase reward from the first block into the output with the same script (this is your "to_spend" transaction), and then spend it (this is your "to_sign" transaction). Then, you share those two transactions, and if your recipient will have the same regtest setup, with the same 101 initial blocks, it can simply send raw transactions, mine a new block, and see, if it is valid or not.

Hey,

I just wanted to let you know that I commented this thread on Github: https://github.com/bitcoin/bips/pull/1347#issuecomment-2090701376

If there's no response the next few weeks, I will send an e-mail to the Google Group mailing list about our use-case.

@ProfEduStream

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.

Even better: we have OP_PUBKEY and OP_PUBKEYHASH. They make scripts automatically invalid when occured, so they behave as OP_RESERVED, but they are just named. So, "OP_PUBKEY OP_CHECKSIG" and "OP_DUP OP_HASH160 OP_PUBKEYHASH OP_EQUALVERIFY OP_CHECKSIG" could be used to mark transaction as invalid, and turn on backward-compatible verification at the same time.

Exactly. And if we want to make it somehow compatible with "Bitcoin Message", then OP_PUBKEYHASH could represent P2PKH addresses, and OP_PUBKEY could be used to check P2PKs. Then, it can be safely combined with other opcodes, because it would behave exactly as OP_RESERVED, and will mark transaction as invalid when used on-chain, but will be accepted when skipped.

At any rate, it means that besides TODOs, all we have to change in the BIP is specify that "The behavior of OP_CHECKSIG and related opcodes is changed when verifying proofs to hash `to_spend` instead of a real transaction" or words to that effect (apologies if I missed something in this correction).


As far as I know, gmaxwell did not help with the BIP322 design, so why do you keep bringing him up here?

Reading through your post, it looks that there is no template matching, it is verification without interpreter. The fake BIP322 transation is to be verified! A client without the interpreter! People have hell of a job to support it, don't they? Very few are invited to this party, I suppose.

It is not the way you design software, seriously. It is just contingent dependency, we need the message to be signed explicitly, otherwise we are dependent on this verifier.  Now, check a real template based solution and compare the elegance and beauty:
We have three parties: the signer, the verifier and the consumer.

The signer:
 already knows which address should be used, it signs a message with keys for the address, then it attaches the address the script behind it (if any).

The verifier:
First and foremost, checks whether signature is correct per se. If passed, the message is authenticated, but it continues checking if the signer has included supplementary, bitcoin blockchain related info, if so, it compares the address received directly or extracted from the supplied script (template based), comparing it with the keys used, if passed, the address reference is attached to the message.

The consumer module:
Has a signed message with public keys disclosed and a reference to a bitcoin address for profiling purposes and as a metadata.

Such a signed message is independent of bitcoin-like clients/modules, standing on its foot, it is self-contained.

Note that we have a total different scenario here with what Greg Maxwell has proposed:
Here the signed message is the core data, relation with bitcoin is metadata. Greg has put it upside-down because in the real world, we focus on the message. If this up-side down world has an excuse to exist, who am I to oppose, what I'm insisting on is to do it separately and in its own application domain (being a very narrow domain, I suppose).

P.S.
Note how downward compatible and inclusive is the scheme I suggested, with just standard Digital signature libraries, very simple applications can communicate (just ignoring the bitcoin address related meta data) with each other as well as with much more sophisticated applications.

Also note that there is no need to reject the upside-down world, it can exist and do whatever it is  supposed to do.

NO! I think you misunderstand what "template matching" means here. This isn't jamming some other signature format into a BIP 322 signature. There's no "template friendly message" to create, and no signing again.

In this context, template matching occurs against the output script for which the BIP 322 signature signs for. This output script is produced by the address provided, as addresses encode output scripts. A template matching verifier would simply look at the address, see if that address type is one that it understands. Because standard scripts have fixed witness structures, the verifier can look at the scriptSig and witness to see if those match the template, then extract the components that it expects, and verifies that those are correct. This also generalizes to things that don't have addresses, such as Lightning HTLCs, as the script has a fixed structure and so the witnesses will also have a fixed structure.

For example, a template verifier for P2PKH would be given a P2PKH address. It understands P2PKH addresses and knows that it should expect a scriptSig that begins with a byte between 0x07 and 0x49, followed by however many bytes that number was, followed by a byte that is either 0x21 or 0x41, followed by however many bytes that number is. It knows that the first of those is an ECDSA signature, and the second is a public key. It knows that it should check that the public key's hash160 should match the one encoded in the provided address. It knows that the signature, pubkey, and the sighash of the current transaction, should validate using ECDSA. It can do all of this, because the programmer hard coded these things in. If anything doesn't match, it just immediately says the signature is invalid. If it gets an address it doesn't know, it tells the user that verification is inconclusive because it doesn't know that address type.

Template matching is literally just the inverse of signing. It's just that instead of putting things into a scriptSig or witness, it's pulling data out. This technique works for any set of scripts where the opcodes remain in (relatively) fixed positions, the only things that differentiate them are preimages and pubkeys.

Really?  
Just because we have scripts that USE Digital Signature schemes, then we have a Programmable Digital Signature system? Are you kidding or what?
Before rushing to the keyboard, always do your homework: Google it! Programmable Digital Signature System.

Done? As I said, and you quoted, there is no such thing in the world, Right?

As for your show-off with what you've learned about the way interpreter is implemented in bitcoin client:

Please note: We are comparing message signing using templates with this job done using the interpreter, the latter, according to BIP32 is done by putting the message in a virtual/invalid transaction and signing this transaction, these two are incompatible, so, no, they don't reach to an agreement. The only way for this to happen is the ugly dependent way, I briefly described.

For sure, if it holds any water, it would be poisonous, imo.

NO! It will be incompatible with ALL BIP322 generated signatures and vice versa, They belong to two different worlds and only with lots of dependencies and ugly stuff can agree upon a message being signed: you need to generate and sign a template friendly message then put this message in BIP322 virtual txn then again sign it!! lots of other ugly details here.

The question is: why should they communicate ever? One being a conventional message signing algorithm, the other being a special proof-of-authority "thing".

In my view, it is a too long shot which ends in a total miss-fire. There is no reasonable way for circumventing the versioning requirements when you add features, trust me, it will never happen, there is no general solution for all the problems. Soft-forks do not happen in bitcoin on a daily basis, it is not a "project", like what Etherem is, so, it'd be easy to add new templates ever few years or so.

With all due respect, Peter, you need to re-think this approach. You are free to implement your script version and promote it as whatever you wish.
I'm serious, it is useful, but as far as it is not introduced as a signing mechanism, hence "postponing" the development and implementation of a standardized template based (universal) signing system.

The interpreter based system you suggest is good and useful, but in its own domain and universe, for its own (future?) applications.

Wrong. You can always send your coins to " OP_DROP OP_CHECKSIG" and spend them, then it will be quite similar to OP_CHECKDATASIG, the difference will be just in the format of the message: in "Bitcoin Message" you have this famous prefix, here you would have transaction data as your prefix. So, the different message will be signed, but the whole functionality will be the same. Or you could have " OP_CHECKSIG" and use different sighashes that would take your message from the stack instead. There are many options.

Quote

No problem, as super devs you are entitled to do inventions, but as an observer I have all the rights to review and to resist.

Good luck banning "OP_SHA256 OP_EQUALVERIFY OP_CHECKSIG" from the script, and all other variants of that.

Quote

Why should anybody do it?

Because you cannot stop people from implementing it on their own. Having it standardized would mean that their signatures will at least be compatible with some BIP. Now we have a situation, where different wallets implement their own ways of handling signatures, so there is a choice between getting it standardized or not. You cannot stop it, because it is not something that has to go through some kind of soft-fork, it is purely informational no-fork, trying to resist is like trying to stop HD wallets.

Also note that we have almost-BIP-322-compatible network called signet, and note that it can be hijacked to serve the same purpose: the recipient could set some signet challenge, and wait for a valid signed block. The only catch in hijacking the signet is that mining is needed to make a valid signature. But one simple change, and you can get fully working script verifier, if you set the difficulty to the same value as in regtest.

Quote

Then how is it possible to have both, template based and interpreter based implementations in one world?

Guess what, P2SH is template-based and interpreter-based: you have some template, some fixed opcodes here and there, and it works. It is fully compatible with other nodes, because just more data are pushed into the stack, and old nodes simply check if the hash of the script is correct, but upgraded nodes actually execute the script. And here it could be similar: some nodes could know how to handle transactions, and other nodes could simply require some magic bytes in some format, and then perform signature checking on some hashed data, and report everything non-standard as "not implemented".

Quote

First and foremost, stop scrambling the terminology, I know, we all know, Greg is genius, you are genius, ..., no doubts, but we are all humans, sometimes we go too far.

So, go on, and propose some BIP to get rid of the entire Script, and go back to P2PK-only-world. Or make a sidechain for that, and put your coins there. Because as long as we have Script, and as long as it gets more and more complex, there will be use cases for signing different outputs. Unless you want to tell someone that "You have your coins on P2SH/P2WSH/P2TR? Too bad, please move to P2PKH, and sign it, then I will verify it".

It's okay if you don't feel this terminology is warranted. Do you disagree it is useful abstraction?


A template-matching based verifier will only be compatible with a subset of potential BIP322 signatures, reporting "inconclusive" for others. That's the price for not having a full script interpreter.

But even if *all* implementations use just template-matching based verification, this approach still has the advantage of defining a single format that is compatible with *all* potential future extensions that correspond to script features. Because addresses are encodings of scripts, and what we're signing for is the ability to spend outputs sent to a certain address, using script for the message signing too is just the obvious match in my view.


I believe it is entirely uninteresting to work on any kind of message signing system that is restricted to a subset of what script can do. That is postponing another inevitable future problem again, when that subset no longer suffices.

No!
It is just an invention, a bad one: Programmable digital signature. There was no such thing in the world before you guys made it up, right? No problem, as super devs you are entitled to do inventions, but as an observer I have all the rights to review and to resist.

What happened now? Bitcoin script is a digital signature with transactions as their messages, then it evolved to a general pupose one for arbitrary messages? So, there are two consecutive inventions : first we invent programmable DS, and immediately we go all-in to make it even more general purpose? Fantastic but absurd, isn't it?
Or maybe BIP322 is just hijacking (taking) your invention, landing it where it was not supposed to land (through a transposition).  

I understand how it feels, getting high by doing abstractions and generalizations, but it needs to pass some review and criticisn. I'm afraid the vague and loose terminology is a bad sign.

Bitcoin scripting system is not a digital signature scheme, it may use this technology (we have signature free scripts, don't we?). Using a technology doesn't make a system identical with that technology.

However, why should anybody do it? Ruining an established terminology.
What's the catch? Proof-of -ownership or something? Why should it be considered an act of signing? Why don't we simply open a BIP for this one with an appropriate terminology? It is not "message signing" per se, it is "virtual transacting", whatever.

Then how is it possible to have both, template based and interpreter based implementations in one world?
Above thread, I've already discussed it, for now let's check just one issue (there are more, believe me):

For a p2sh where the script is well-formed and can be supported by both, either the message produced by interpreter friendly style is not compatible with template based verification and fails, or it is compatible.
For compatibility, you should
1- Prepare and sign a message template based.
2- Put the signed message in the virtual txn.
3- Supply witness data, using your signature again!
4- Every time check the verifier and supply properly either the virtual txn or the message.

The last step is necessary unless you IMPOSE dependencies on template based wallets.

Ugly & Disgusting.

My Suggestions: (I want to be constructive)

1- First and foremost, stop scrambling the terminology, I know, we all know, Greg is genius, you are genius, ..., no doubts, but we are all humans, sometimes we go too far.

2- Ripping this sign-by-script concept off from BIP322, let it focus on true signing with support for references to standard txns (with well-formed scripts).

3- Make another BIP Just for proof-by-interpretation thing. Find a proper label.

Do not mix signing-with-ref-to-txo and proof-by-interpretation/whatever.
[/list]

The Bitcoin script system *is* a (programmable) digital signature scheme on its own, which achow101 is referring to as "script signatures". This digital signature scheme is distinct from the ECDSA/Schnorr signature algorithms available in Bitcoin script (but builds upon it).

• The "public keys" of this digital signature scheme are the scriptPubKeys in transaction outputs.
• The "messages" of this scheme are the spending transactions, excluding witness data.
• The "signatures" of this scheme are the scriptSigs and witnesses in transaction inputs.

It's a programmable signature scheme in that it supports more complex assertions than "a single party with key X agrees"; e.g. it can express agreement of multiple parties (using e.g. a P2SH scriptPubKey with a redeemscript that requires signatures with multiple keys). The actual script semantics are more-or-less irrelevant for this. It just suffices to express the kinds of assertions we care about.

BIP322 is taking this script signature system, and transposing it to a different context: messages that aren't transactions. Everything else remains the same: the scriptPubKeys remain the "public keys" verified against (=addresses), the "signatures" remain scriptSigs/witnesses (but now embedded in a BIP322 signature encoding, rather than being placed in a transaction). However, the "messages" are replaced with a virtual transaction derived from the message being signed, rather than any real transaction. This permits reusing all the script logic a signer and/or verifier may have (however complex or simplistic that may be) for transactions to be immediately applied to messages.

No new opcodes are needed or involved - the only thing that changes is that in BIP322 context, OP_CHECKSIG (and friends) don't compute a sighash from a spending transaction, but from a virtual transaction that is derived from the message being signed. If you want to BIP322-sign for "I have the ability to spend funds sent to address X" with message M, all you need to do is demonstrate your ability to "spend" funds sent to X, using a virtual transaction that commits to M. If you have the capacity (in terms of access to private keys, and in terms of having signing algorithms for it) to do that for the script corresponding to X (whether that's a simple single-key constructor, or something far more complicated) for real transactions, you also have the ability to do that for this BIP322 virtual transaction.

I don't understand any of the concerns brought up here. AFAICT, the only thing necessary to move BIP322 forward is finalizing the last details of the specification, and implementing it (which may mean bring the Bitcoin Core implementation up-to-date, if BIP changes are made, and/or implementations for other software, which may be template based).

I understood the whole script up to OP_CHECKSIG.

From my understanding, OP_CHECKSIG will compute the hash of all the inputs, outputs and script combined together.

For simple and full proof, we can simply compute such signature by hand and place it on the stack for the purposes of equality comparison.

But in the case of legacy proofs, which are supposed to be backward-compatible with the ECDSA (r,s) signatures, it would result in a different signature from when computing r,s from the private key.

This raises an interesting question: P2PKH message signing as it is now won't be removed out of backward compatibility concern, so does the legacy proof simply imply doing the standard ECDSA signing while skipping the entire script interpreter and tx format?

No new opcodes are needed. Just use "OP_DUP OP_HASH160

OP_EQUALVERIFY OP_SWAP OP_SHA256 OP_EQUALVERIFY OP_CHECKSIG", and then check two things:
1) is " " valid for this transaction, according to BIP-322
2) is " " valid for a given "Bitcoin Message"
Then, you can hash "Bitcoin Message" and check the second case in your software, and also consider such signature valid. By making the above script "standard", you can expand verification, just in the same way as P2SH was introduced.

I have addressed some more TODOs in a mailing list post, which I will quote verbatim:


At this point, the core of the BIP is already done, but such cases need to be addressed as "how can I sign a message from the Lightning Network" and "how can I allow another person to sign a message on my behalf, without giving him/her access to my private keys?"

Side note: I don't think most people here even know what a Merkle branch is, the form that is already used in Taproot, so if I prepared an explanation about this data structure, would it help you guys understand what is being proposed here?

Side note 2: I'm starting to suspect that the witness stack which contains the solution to a "challenge" in the second transaction which the spec calls 'to_sign' just has an ecdsa signature and public key (from bottom-to-top order) in the case of P2[W]{SH|PKH} - I'm not really sure what is pushed on a Taproot address, so I may have to make a guide for that too.

[silent transactions as referred to in the mailing list and Github is the same thing as Silent Payments thread started by @witcher_sense].

@NotATether,
It is called "BIP322 discussion thread", isn't it?

Change its title to "I want to join the club by any means", or lock it, whatever, just don't get mad and angry because it doesn't make sense to stop discussing in a discussion thread. 

Guys can we stop with these arguments that aren't accomplishing anything? The point of this thread is to discuss how to solve the edge cases of BIP322 to bring it to final status:


I dropped the old BIP because luke-jr told me it's better to help finalize BIP322, and I want to make change happen [as opposed to whining about it]. That's the end of the story. This thread is not for rambling about why my BIP was (or shouldn't have been) rejected, open a new thread if you want to discuss that.
Message signing with transactions looks ugly but is the only way to demonstrate proof-of-spendability-from-UTXOs. Let's leave it at that.

---

Anyway, what I did come here to post was that there is apparently a bunch of TODOs for addressing interoperability with various BIPs and proposals that are likewise in draft or maybe not submitted yet - one of them is interoperability with Silent Payments so this is what I have suggested on the Github issue for it (see the second post of this thread):

I purposefully avoided it to stay on the main line which was criticizing the concept, and not the BIP.
As you've brought it up: BIP322 supports both worlds at the same time!
How is it even possible? Is the BIP trying to invent another third universe where paradoxes are considered normal and tolerable?

I got this standard script behind a txo which somehow I'm able to unlock, and I'm trying to tie a message to it,  the problem is I got two different interested parties, one uses Bitcoin Core while the other party has another wallet.
What do I have to do when trying to convince them?
More critically important: When the said parties finish verifying (probably different versions of) my message, the party using the interpreter is convinced about a message being supplied by "somebody" who is able to unluck the txo, but what about the other party? Should they ignore the fact that their wallet already knows the public key(s) that actually was used?

See? Two different messages, two different signing processes, two different verification algorithms, and finally two, radically different application domains. What kind of BIP is it? A derailed BIP!

Yes, it's easy when you see it, but you should look, just look. Essentially, the BIP is trying to get implemented by any means without insisting on any principle or philosophy, I suppose I could forge an arbitrary third world and successfully convince Karl Johan to support it as well!

It's Greg Maxwell, not Luke, I like Luke, even when he goes too far. As for Greg? No ways! I mean, I'm a fan, not comfortable with the polemic but a fan, still, I don't know why I frequently find myself on the opposite side of where Greg stands, what's wrong with him?  

No, it is not optional, the other way is supposed to be optional, you just admitted that Bitcoin Core reference implementation is focused on "tying" stuff. I've already refuted this mix-and-support design policy.

Bitcoin script, has it through employing ES technologies like ECDSA and Schnorr, but script signing? No! It doesn't. It just implies that the script interpreter has passed testing some witness data for unlocking a txo. It is silent about the identity of the party who prepared this data, hence there is no established mechanism for authentication and repudiation unless you/your app would examine the witness data beyond what the interpreter does, e.g., by checking whther the message is signed and if so, is the signature identical with the one used for unlocking? See? It's so ugly!

Did you even read the BIP or are you just spouting nonsense based on the one sentence summary?

Conveniently, the BIP addresses this. Wallets without script interpreters can use template matching and verify the common, standards scripts. If it finds a script that it is unable to verify, then it should return a result of "inconclusive". A template matching verifier can look at the address it is given and understand what data to expect.

So third party wallets and services can implement the common single key, multisig, lightning htlc, etc. scripts and probably get 99% of the signed messages. It's not that hard to figure out.

Where is this being claimed? I don't see that in the BIP text anywhere. And just so you know, if you heard this from luke-jr, not every opinion that luke-jr has is shared by other developers (or anyone else).

And how does BIP 322 fail to do this? You do know that you can sign arbitrary messages, right? You do know that tying to specific UTXOs is an optional feature of BIP 322, not a requirement? Frankly, it sounds like you did not read the BIP at all and are getting your entire understanding of it based on what other people are saying about it, or perhaps you read it and just failed to understand it.

Who said anything about ignoring your message? How does Bitcoin script not have authenticity or non-repudiation?

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?

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.

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.

You can check the author of BIP-322: "Karl-Johan Alm <[email protected]>".

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 OP_EQUALVERIFY OP_CHECKSIG", then it is spendable by providing " " 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.

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

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.

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

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.





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

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.

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.

For that reason I think you could start with concatenating constants. You don't need the full script to create "76a914

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.

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


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

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

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

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.

OP,

In BIP322 discussions in Github, Greg Maxwell argues:
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:
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.

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

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.

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.

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.

What is "proof of sent-transaction" problem? You can always make " OP_DROP 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 " OP_CHECKSIG", and your R-value of your signature could be converted to a Taproot address, and then you can provide "OP_RETURN " TapScript for such key. I wonder what this "proof of sent-transaction" is about: is it about providing OP_CHECKDATASIG functionality?

Quote

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.

Quote

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.

Quote

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

Quote

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.

Quote

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

Yes.

Quote

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

@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]?

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 "", 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.

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.

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?