BIP 322: Explain various signature intents, add TODOs

luke-jr commented at 10:14 pm on July 25, 2022: member

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

BIP 322: Explain various signature intents, add TODOs b6b0126e2d

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

luke-jr assigned kallewoof on Jul 25, 2022

in bip-0322.mediawiki:29 in b6b0126e2d

25+This ensures that any coins, no matter what script they are controlled by, can in-principle be signed for.
26+For easy interoperability with existing signing hardware, we also define a signature message format which resembles a Bitcoin transaction (except that it contains an invalid input, so it cannot be spent on any real network).
27 
28 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.)
29 
30+There appears to also be a desire to prove funds availability.

kallewoof commented at 7:09 am on July 28, 2022:

Why is this sentence needed?

luke-jr commented at 6:43 am on August 1, 2022:

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

anditto commented at 5:31 am on August 3, 2022:

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

in bip-0322.mediawiki:113 in b6b0126e2d

110 
111 Unlike an ordinary signature, validators of a proof of funds need access to the current UTXO set, to learn that the claimed inputs exist on the blockchain, and to learn their scriptPubKeys.
112 
113+This signature proves only that the message is signed by someone who owns the specified (in nValue) amount of bitcoins.
114+It does not prove anything about the transactions or recipients thereof when the UTXOs were created;
115+it does not prove control or ownership of the specific UTXOs;

achow101 commented at 9:02 pm on July 28, 2022:

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.

luke-jr commented at 7:58 am on July 29, 2022:

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

apoelstra commented at 1:28 pm on July 29, 2022:

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

luke-jr commented at 6:42 am on August 1, 2022:

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

apoelstra commented at 2:17 pm on August 2, 2022:

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.

luke-jr commented at 0:52 am on August 3, 2022:

For signed messages to have any meaning, it needs to indicate an intended purpose. Current signed messages indicate only that the message-signer receives/received what was sent to the address in question. They cannot prove control of a UTXO, because it is expected, by design for a third-party to produce the signature even if the recipient no longer has a claim to the UTXO received, and may never have had control of it in any case.

To prove control of funds, or control of UTXOs (if that indeed has a use case), a signature would need to intend to be usable for that purpose, distinguishable from current signatures, so third-party signing applications could refuse to produce such a signature when it is not valid.

Rspigler commented at 4:08 am on August 3, 2022:

I don’t understand why or since when stated purpose matters for cryptographic signatures

luke-jr commented at 4:53 am on August 3, 2022:

???

Rspigler commented at 0:09 am on August 4, 2022:

I don’t understand your statement “For signed messages to have any meaning, it needs to indicate an intended purpose”, since the mindset of the signer obviously doesn’t affect the signature data

rxgrant commented at 1:24 pm on August 10, 2022:

0The meaning of the signature is not resolved by Bitcoin's blockchain.

luke-jr commented at 8:43 pm on August 10, 2022:

Without a meaning, it’s not practical to implement correctly.

apoelstra commented at 9:40 pm on August 10, 2022:

I don’t think this is true – many things can be implemented correctly even though they have “no meaning” at the implementation layer. GPG signatures would be a close analogy to this (gnupg has no idea what the bytes you’re signing are supposed to indicate, nor what your signature is supposed to mean), but this is also true of e.g. TCP.

In this case BIP322 is designed to represent a transaction, possibly with some extra non-transaction data embedded in it, and to demonstrate the ability to produce such a transaction. This can be mechanically defined and correctly implemented without agreeing on what the resulting transactions are supposed to mean.

rxgrant commented at 10:39 pm on August 10, 2022:

Without a meaning, it’s not practical to implement correctly.

I think the signatures do have meaning, but in the realm of human-mediated concerns, rather than the realm of Bitcoin blockchain transaction ordering.

I don’t think that we can proscribe what people will use the signatures for. It’s still useful to have reliable code that allows these signatures to be checked. This BIP can also warn about the limitations that people will encounter for whatever “L2” meaning they build, since BIP322-signature-double-spend protection won’t be available.

luke-jr commented at 11:17 pm on August 10, 2022:

GPG only works with messages from one person. It doesn’t have a concept of sender, receiver, or funds availability. These things all require distinct proofs, as the person who can produce such a signature may be different people entirely. Without a well-defined meaning at least to this degree, it isn’t possible to use signed messages at all.

rxgrant commented at 11:44 pm on August 10, 2022:

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.

luke-jr commented at 11:55 pm on August 10, 2022:

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.

rxgrant commented at 1:43 am on August 11, 2022:

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

luke-jr commented at 1:58 am on August 11, 2022:

You can’t even produce the signature until this purpose is defined…

rxgrant commented at 9:26 am on August 11, 2022:

None of this is new. Signatures go like this:

0protocol indicating purpose, perhaps just words
1--- begin signature ---
2signature(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.

in bip-0322.mediawiki:56 in b6b0126e2d

52@@ -43,6 +53,8 @@ A ''simple'' signature consists of a witness stack, consensus encoded as a vecto
53 
54 and then proceed as they would for a full signature.
55 
56+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.

kallewoof commented at 5:59 am on August 1, 2022:

0Furthermore, 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 commented at 6:03 am on August 1, 2022: member

Minor nits.

kallewoof commented at 3:16 am on August 2, 2022: member

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 commented at 11:10 pm on August 2, 2022: contributor

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

in bip-0322.mediawiki:94 in b6b0126e2d

87@@ -76,16 +88,33 @@ The <code>to_sign</code> transaction is:
88 
89 A full signature consists of the base64-encoding of the <code>to_sign</code> transaction in standard network serialisation once it has been signed.
90 
91+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.
92+It does not prove any control of bitcoins or having had sent any transactions.
93+
94+TODO: How does this interact with as-of-yet-unspecified "Silent Transactions"?

luke-jr commented at 0:53 am on August 3, 2022:

This isn’t “future work”, but a matter of compatibility, which BIPs should address.

in bip-0322.mediawiki:96 in b6b0126e2d

87@@ -76,16 +88,33 @@ The <code>to_sign</code> transaction is:
88 
89 A full signature consists of the base64-encoding of the <code>to_sign</code> transaction in standard network serialisation once it has been signed.
90 
91+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.
92+It does not prove any control of bitcoins or having had sent any transactions.
93+
94+TODO: How does this interact with as-of-yet-unspecified "Silent Transactions"?
95+
96+TODO: Some invalid opcode to allow only in various proof types?

luke-jr commented at 0:53 am on August 3, 2022:

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

ZenulAbidin commented at 3:46 am on August 9, 2022:

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

luke-jr commented at 8:44 pm on August 10, 2022:

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

rxgrant commented at 10:31 pm on August 10, 2022:

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.

ZenulAbidin commented at 5:46 am on August 11, 2022:

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

in bip-0322.mediawiki:98 in b6b0126e2d

93+
94+TODO: How does this interact with as-of-yet-unspecified "Silent Transactions"?
95+
96+TODO: Some invalid opcode to allow only in various proof types?
97+
98+TODO: A way for the initial signer to delegate to another scriptPubKey; needed for better privacy and CoinJoin/Lightning compatibility

luke-jr commented at 0:55 am on August 3, 2022:

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

luke-jr commented at 0:58 am on August 3, 2022: member

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 commented at 1:25 am on August 3, 2022: member

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 commented at 1:53 am on August 8, 2022: contributor

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 commented at 12:40 pm on August 9, 2022: contributor

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 commented at 10:57 pm on August 10, 2022: none

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 commented at 9:35 am on August 11, 2022: none

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 commented at 6:53 pm on August 11, 2022: member

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 commented at 4:16 am on August 12, 2022: contributor

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:

0<in Rationale>
1Because `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.
2
3<in Specification>
4The 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 commented at 8:33 pm on April 26, 2024: contributor

Is this PR still being worked on?

ProfEduStream commented at 2:47 pm on May 2, 2024: none

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 commented at 2:28 am on May 3, 2024: contributor

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.

murchandamus added the label PR Author action required on May 8, 2024

5twelve approved

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