BIP 322: Explain various signature intents, add TODOs #1347

luke-jr · 2022-07-25T22:14:02Z

Improves what is already in the spec, and adds TODOs for things I think need to be addressed.

achow101 · 2022-07-28T21:02:30Z

bip-0322.mediawiki

+This signature proves only that the message is signed by someone who owns the specified (in nValue) amount of bitcoins.
+It does not prove anything about the transactions or recipients thereof when the UTXOs were created;
+it does not prove control or ownership of the specific UTXOs;


Lines 111 and 113 seem contradictory.

Since the signature is over specific UTXOs, if the signature proves that the signer owns the specified amount, that implies that the signer owns those UTXOs, or at least has the ability to spend them as they have to provide valid scriptSigs and witnesses. If the signature does not prove that the signer has the ability to spend those specific UTXOs, then I don't see how the signature proves that they own the specified amount of Bitcoin.

eg, MtGox should produce these signatures for their users, while still keeping funds mingled in separate hot/cold wallets. The hot UTXOs might be spent by any unrelated user, but in the meantime serve as proof of an available sum for another user. Two separate users might have proofs for different actual balances yet technically sign using the same UTXO(s).

Should it say that the signature proves control over the UTXOs, but does not prove ownership or unique control?

It doesn't prove control over the UTXOs, though, that's the point. It shows (perhaps not proves absolutely) ownership.

I consider myself pretty knowledgeable, and you've been saying this for many years (about signmessage), and to be honest I've never fully understood what you mean.

My understanding is that signing a message (or a transaction) proves control over a UTXO, with the following caveats:

it may not have been you who did the signing (e.g. you are a Gox user and Gox did the sig)

it may not have been recent (Gox did it 10 years ago and since then has run into some trouble ... although I suppose you could include a recent headline and/or a challerger-provided nonce to help with this)

even if it's recent, it is obsolete as soon as it's created (ok, you signed 1 second ago but your signing device caught fire at the same time)

it may not indicate unique control (Gox may be signing with the same UTXOs for multiple users)

it may not indicate general-purpose signing ability (maybe your hardware wallet will only sign messages, or only sign BIP322 provably-invalid transactions, etc., and won't actually sign real transactions)

Does this match your understanding? The word "ownership" feels nebulous to me and I'm not sure what you mean by it.

Whether or not the script has been satisfied is meaningful. How that is tied to a claim is meaning constructed outside the Bitcoin blockchain, by the parties that choose to use BIP322-signatures. Unlike txs stored in the blockchain, these signatures don't prevent double spending their associated claims.

Some people may agree that the ability to satisfy the script at one moment is still valuable, because they know the constraints of their L2 problem domain.

ALL of this is outside the blockchain.

If a signature doesn't indicate a purpose, then the parties can't agree on a purpose, because one of them probably won't be able to produce a signature at all.

Other metadata used to indicate the purpose can wrap the signature.

One approach to this, with well defined structure for wrapping signatures, is the W3C Verifiable Credential Data Model, which is very specific about what a claim is: https://www.w3.org/TR/vc-data-model/#claims

You can't even produce the signature until this purpose is defined...

None of this is new. Signatures go like this:

protocol indicating purpose, perhaps just words --- begin signature --- signature(protocol indicating purpose, perhaps just words)

In the case of the example I offered, the protocol indicating purpose is quite sophisticated. I belive it's a compelling example that allows you no room to try to derail BIP322 on the grounds that all that meaning needs to be defined inside BIP322.

P.S. This argument has moved beyond the proposed patch that started these replies, which I'm not arguing for or against, so I'll move on.

kallewoof

Minor nits.

kallewoof · 2022-07-28T07:09:32Z

bip-0322.mediawiki


 Additionally, the current message signature format uses ECDSA signatures which do not commit to the public key, meaning that they do not actually prove knowledge of any secret keys. (Indeed, valid signatures can be tweaked by 3rd parties to become valid signatures on certain related keys.)

+There appears to also be a desire to prove funds availability.


Why is this sentence needed?

Motivation for a new message signing standard that does something the current one does not.

Maybe something less ambiguous like "Proving fund availability is a also a useful feature with practical use cases."

kallewoof · 2022-08-01T05:59:23Z

bip-0322.mediawiki

@@ -43,6 +53,8 @@ A ''simple'' signature consists of a witness stack, consensus encoded as a vecto

 and then proceed as they would for a full signature.

+It also only can prove the message is signed by the intended recipient of the given invoice address, and cannot prove any control of bitcoins or having had sent any transactions.


Suggested change

It also only can prove the message is signed by the intended recipient of the given invoice address, and cannot prove any control of bitcoins or having had sent any transactions.

Furthermore, it can only prove the message is signed by the intended recipient of the given invoice address, and cannot prove any control of bitcoins or having had sent any transactions.

kallewoof · 2022-08-02T03:16:01Z

Adding a bunch of TODO entries to a BIP doesn't seem very constructive, and will only confuse everyone. Instead of adding TODOs, perhaps add a section at the bottom with "Future work" which lists what follow up BIPs could potentially address. I think BIP-322 on its own adds value, even if it is not addressing every single corner case in the galaxy right now.

Rspigler · 2022-08-02T23:10:16Z

BIP 332 definitely adds value, as it is needed for BIP 129 (legacy format accepted).

luke-jr · 2022-08-03T00:53:20Z

bip-0322.mediawiki

+This signature, as-is, only proves a message is signed by the intended recipient of the given invoice address which creates the <code>message_challenge</code> script.
+It does not prove any control of bitcoins or having had sent any transactions.
+
+TODO: How does this interact with as-of-yet-unspecified "Silent Transactions"?


This isn't "future work", but a matter of compatibility, which BIPs should address.

luke-jr · 2022-08-03T00:53:57Z

bip-0322.mediawiki

+
+TODO: How does this interact with as-of-yet-unspecified "Silent Transactions"?
+
+TODO: Some invalid opcode to allow only in various proof types?


This seems like it should be too trivial to put off as "future work". IMO.

@luke-jr Here's a solution at least for the Silent Transactions. Since they can't decide which address formats they will use for it (there is a lot of to-and-fro between taproot and segwit), and all such address formats can be represented in the Simple format anyway, just write in this BIP that Silent Transactions can use the Simple format to sign their messages, and the scriptPubKey/scriptSig/Witness will all be the same.

[Why do we need an invalid opcode to redefine in the first place, I thought invalid opcodes in the script are supposed to make the verifier return an inconclusive status.]

Making an invalid opcode valid would be useful to provide a separate Tapscript that is valid only for signing messages, but not actual spending.

If someone wants to hide the specific allocation of outgoing value among tapscript outputs, then it would already be possible to create a branch that spends the UTXO to an OP_RETURN. Since BIP322-signature-txs cannot be spent, there's no downside to signing that branch.

Note that we can also redefine the meaning of OP_CHECKSIG in the context of message signing and verifying to hash the virtual transaction that is derived from the message i.e. to_spend. Bitcointalk source

luke-jr · 2022-08-03T00:55:01Z

bip-0322.mediawiki

+
+TODO: Some invalid opcode to allow only in various proof types?
+
+TODO: A way for the initial signer to delegate to another scriptPubKey; needed for better privacy and CoinJoin/Lightning compatibility


Putting this off to a future standard would compromise the privacy benefits.

luke-jr · 2022-08-03T00:58:55Z

Adding a bunch of TODO entries to a BIP doesn't seem very constructive, and will only confuse everyone. Instead of adding TODOs, perhaps add a section at the bottom with "Future work" which lists what follow up BIPs could potentially address.

A couple of them could be moved, but most of them are really things I think the BIP should address upfront before being complete.

I think BIP-322 on its own adds value, even if it is not addressing every single corner case in the galaxy right now.

I'm not sure it does. Nobody seems to have any interest in using current signed messages for what they actually prove. Every attempt I see to sign messages, appear to have something in mind that currently isn't supported by signed messages. Even this historical exceptions were conceptually broken (Eligius revolved around address reuse, while #Bitcoin-OTC used it exclusively for secp256k1 authentication and not actual Bitcoin at all)

luke-jr · 2022-08-03T01:25:39Z

BIP 332 definitely adds value, as it is needed for BIP 129 (legacy format accepted).

Glancing at BIP 129, it's not obvious what it's even trying to use BIP 332 for...? :/

Rspigler · 2022-08-08T01:53:37Z

Glancing at BIP 129, it's not obvious what it's even trying to use BIP 332 for...? :/

It allows you to authenticate the key record according to the xpub or key of the signer

ZenulAbidin · 2022-08-09T12:40:38Z

In the Simple section:

A ''simple'' signature consists of a witness stack, consensus encoded as a vector of vectors of bytes, and base64-encoded.

I think it should be made more clear exactly what data is going to be placed in the witness stack.

I know that it's the solution to some BIP325 challenge, but as I, and perhaps a lot of other people, am not really sure how that works, it should be made more explicit what needs to be placed on the witness stack to constitute a valid proof.

rxgrant · 2022-08-10T22:57:27Z

I think BIP-322 on its own adds value, even if it is not addressing every single corner case in the galaxy right now.

I'm not sure it does. Nobody seems to have any interest in using current signed messages for what they actually prove.

It's a foothold for L2 value.

rxgrant · 2022-08-11T09:35:52Z

I think BIP-322 on its own adds value, even if it is not addressing every single corner case in the galaxy right now.

I'm not sure it does.

I apologize for mixing issues in threads above. I realized that I've largely been responding to this statement. I think having a way to show that a UTXO's script can be satisfied is obviously valuable.

luke-jr · 2022-08-11T18:53:52Z

I apologize for mixing issues in threads above. I realized that I've largely been responding to this statement. I think having a way to show that a UTXO's script can be satisfied is obviously valuable.

As-is, this spec cannot show that (at least not if you care about who can satisfy it, or in what context).

ZenulAbidin · 2022-08-12T04:16:42Z

It's actually not even necessary to change the behavior of OP_CHECKSIG in this context. It will already hash all inputs, outputs etc. so these can be used in message signatures as-is meaning no revision is necessary except for some new sentences in the BIP that say:

<in Rationale>
Because `to_sign` is created using the transaction ID that is hashed from `to_spend`, the message signature is cryptographically unique and an additional verification beyond reconstructing `to_spend` and validating all fields is not required.

<in Specification>
The message signature must not be placed on the witness stack. Only data for the solution of the scriptPubKey should be placed on the witness stack.

Regarding satisfying UTXO scripts: Why don't we just add the relevant UTXO as a vin in to_sign? Then it's bundled with the proof that the address is under the signing party's control, to indicate the UTXO is also under their control as well.

murchandamus · 2024-04-26T20:33:29Z

Is this PR still being worked on?

ProfEduStream · 2024-05-02T14:47:49Z

Hey,

As a Bitcoin association, we're currently facing an issue because we're unable to sign an address with our multi-sig wallet.
After conducting some research, I came across BIP322 in this thread: https://bitcointalk.org/index.php?topic=5408898.msg63891940#msg63891940.

Explanation:

As a Bitcoin association, we offer membership to everyone for a few thousand sats per year. To facilitate this process, we utilize "Swiss Bitcoin Pay". It's an application that allows us to easily manage our accounting. Additionally, we onboard merchants with this app because of its user-friendly interface and self-custodial capabilities, making it very convenient. The accounting features are also highly beneficial.

To utilize this application in a self-custodial manner, users need to paste a Bitcoin address on the "Swiss Bitcoin Pay" dashboard and then sign a message with this address. This serves as a "Proof-of-Ownership" and is a legal requirement in some regulated countries. "Swiss Bitcoin Pay" is not the only application that requires signing a message as a "Proof-of-Ownership". Peach, a non-KYC P2P Bitcoin application, is another example.

Given our goal to decentralize our treasury, we naturally opt for a multi-sig wallet, similar to many companies. However, as you know, it's currently impossible to sign a message with a multi-sig wallet.

Conclusion:

I'm unsure why BIP322 hasn't been pushed or addressed in the past few months/years, but I want to highlight its necessity.
Additionally, I hope that this comment sheds light on a deficiency in our Bitcoin ecosystem, and I trust that further improvements will be made to enable people to sign a message with a multi-sig wallet.

I'm available to assist if needed @kallewoof.
@ProfEduStream

murchandamus · 2024-05-03T02:28:54Z

Hi @ProfEduStream, thanks for reaching out. This pull request is proposing some changes to BIP322. Comments in this PR should focus on providing feedback to this proposed change.

BIP322 is already merged, but as far as I am aware has not been deployed in any software. I do not know the reasons but work on it seems to have stopped. I would suggest that you reach out to the bitcoin developer mailing list if you would like to find out more or make an attempt to restart progress.

BIP 322: Explain various signature intents, add TODOs

b6b0126

luke-jr added the Proposed BIP modification label Jul 25, 2022

luke-jr assigned kallewoof Jul 25, 2022

luke-jr mentioned this pull request Jul 28, 2022

BIP-322 basic support bitcoin/bitcoin#24058

Closed

achow101 reviewed Jul 28, 2022

View reviewed changes

kallewoof reviewed Aug 1, 2022

View reviewed changes

luke-jr commented Aug 3, 2022

View reviewed changes

murchandamus added the PR Author action required Needs updates, has unaddressed review comments, or is otherwise waiting for PR author label May 8, 2024


		Additionally, the current message signature format uses ECDSA signatures which do not commit to the public key, meaning that they do not actually prove knowledge of any secret keys. (Indeed, valid signatures can be tweaked by 3rd parties to become valid signatures on certain related keys.)

		There appears to also be a desire to prove funds availability.

		@@ -43,6 +53,8 @@ A ''simple'' signature consists of a witness stack, consensus encoded as a vecto

		and then proceed as they would for a full signature.

		It also only can prove the message is signed by the intended recipient of the given invoice address, and cannot prove any control of bitcoins or having had sent any transactions.

	It also only can prove the message is signed by the intended recipient of the given invoice address, and cannot prove any control of bitcoins or having had sent any transactions.
	Furthermore, it can only prove the message is signed by the intended recipient of the given invoice address, and cannot prove any control of bitcoins or having had sent any transactions.


		TODO: How does this interact with as-of-yet-unspecified "Silent Transactions"?

		TODO: Some invalid opcode to allow only in various proof types?


		TODO: Some invalid opcode to allow only in various proof types?

		TODO: A way for the initial signer to delegate to another scriptPubKey; needed for better privacy and CoinJoin/Lightning compatibility

BIP 322: Explain various signature intents, add TODOs #1347

Are you sure you want to change the base?

BIP 322: Explain various signature intents, add TODOs #1347

Conversation

luke-jr commented Jul 25, 2022

achow101 Jul 28, 2022 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rxgrant Aug 11, 2022 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kallewoof left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

kallewoof commented Aug 2, 2022 • edited

Rspigler commented Aug 2, 2022

Choose a reason for hiding this comment

Choose a reason for hiding this comment

ZenulAbidin Aug 9, 2022 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

rxgrant Aug 10, 2022 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

luke-jr commented Aug 3, 2022

luke-jr commented Aug 3, 2022

Rspigler commented Aug 8, 2022

ZenulAbidin commented Aug 9, 2022

rxgrant commented Aug 10, 2022

rxgrant commented Aug 11, 2022

luke-jr commented Aug 11, 2022

ZenulAbidin commented Aug 12, 2022 • edited

murchandamus commented Apr 26, 2024

ProfEduStream commented May 2, 2024 • edited

murchandamus commented May 3, 2024

achow101 Jul 28, 2022 •

edited

rxgrant Aug 11, 2022 •

edited

kallewoof commented Aug 2, 2022 •

edited

ZenulAbidin Aug 9, 2022 •

edited

rxgrant Aug 10, 2022 •

edited

ZenulAbidin commented Aug 12, 2022 •

edited

ProfEduStream commented May 2, 2024 •

edited