bips
bips copied to clipboard
bitcoin
BIP 322: Explain various signature intents, add TODOs
Improves what is already in the spec, and adds TODOs for things I think need to be addressed.
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.
BIP 332 definitely adds value, as it is needed for BIP 129 (legacy format accepted).
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)
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...? :/
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
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.
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.
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.
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).
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.
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
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.