BIP-0322: clarify motivation/purpose, add prefix, clarify Proof of Funds format, describe PSBT based signing#2141
BIP-0322: clarify motivation/purpose, add prefix, clarify Proof of Funds format, describe PSBT based signing#2141guggero wants to merge 13 commits intobitcoin:masterfrom
Conversation
jonatack
added
Proposed BIP modification
|
Thank you @guggero for picking this up.
@kallewoof thoughts? (If helpful, see BIP3 here for details about the Deputy role.) |
| == Changelog == | ||
|
|
||
| * '''1.0.0''' (202?-??-??): | ||
| ** Mark Final |
There was a problem hiding this comment.
Per BIP3, statuses are now one of Draft | Complete | Deployed | Closed.
The BIP status doesn't appear to be updated from Draft in this PR.
There was a problem hiding this comment.
Right, added the change from Draft -> Complete now in the last commit and fixed the changelog.
murchandamus
left a comment
murchandamus
left a comment
There was a problem hiding this comment.
Partial review of the first three commits.
| == Changelog == | ||
|
|
||
| * '''1.0.0''' (202?-??-??): | ||
| ** Mark Final |
There was a problem hiding this comment.
In commit "BIP-0322: add tentative changelog"
Final is a loaded term in context of the BIPs process. It used to refer to the status that we now call Deployed. Perhaps you could clarify whether you intend to move the BIP to Complete ("all planned work is done, and you are recommending it for adoption") or to Deployed ("all of the above, and at least one project is using it in production on mainnet"). This Changelog entry would then best be paired with the corresponding status change.
There was a problem hiding this comment.
Yeah, you're right, changed to Complete.
|
|
||
| The current message signing standard only works for P2PKH (1...) invoice addresses. We propose to extend and generalize the standard by using a Bitcoin Script based approach. This ensures that any coins, no matter what script they are controlled by, can in-principle be signed for. 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). | ||
|
|
||
| The Proof-of-Funds variant allows demonstrating control of a set of UTXOs. The list of UTXOs may or may not be related to the address being signed (the address is optional in the Proof-of-Funds variant). But in any case, the UTXO list does not aim to prove completeness (e.g. it does NOT mean: "these are all UTXOs that exist for an address") nor that they are unspent (e.g. a validator must consult the blockchain to verify that). |
There was a problem hiding this comment.
“The list of UTXOs may or may not be related to the address being signed”
What “address” is this referring to? I thought BIP 322 message signing works by essentially creating a “fake” transaction where the list of inputs demonstrates control of UTXOs by providing valid inputs for the corresponding output scripts. I’m confused by the singular address vs UTXO list in this line.
There was a problem hiding this comment.
The address is the pkScript you spend in the to_spend transaction, also called the message_challenge in the BIP. In the simple and full case, that's the single UTXO you spend with the fake transaction. In the proof of funds case, you can add more UTXOs, but those don't have to be related to the address. I clarified this in the latest update.
| 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.) | ||
|
|
||
| Ultimately no message signing protocol can actually prove control of funds, both because a signature is obsolete as soon as it is created, and because the possessor of a secret key may be willing to sign messages on others' behalf even if it would not sign actual transactions. No signmessage protocol can fix these limitations. | ||
| Ultimately no message signing protocol can actually prove control of funds, both because a signature is obsolete as soon as it is created, and because the possessor of a secret key may be willing to sign messages on others' behalf even if it would not sign actual transactions. No message signing protocol can fix these limitations. |
There was a problem hiding this comment.
Could you please generally limit the length of any lines you add? Whitespace in the Mediawiki sourcecode doesn’t affect the rendering of the document, but GitHub stops highlighting the changed words after certain lengths:
It is easier to parse what changed across commits when the text is composed of shorter lines, and it is also easier to provide suggestions in review comments. I would suggest a maximum text-width of 100 characters for the initial additions, and would request that diffs are minimized afterwards (i.e., when updating any line, allow for slightly shorter or longer lines over rebreaking or otherwise affecting untouched lines; for longer additions prefer inserting another line over changing linebreak of the following lines).
E.g., in the example below instead of moving "procedures" to the next line to make the first line adhere to the original length limit, which would make the diff appear bigger than it is, it’s kept in the same line to minimize the diff.
Basically, please treat the document’s text like code! 🤓
Please Note that I’m not requesting that you reformat the entire existing document. Should you decide to do that, please make it a separate commit.
There was a problem hiding this comment.
Hmm, yeah, I also don't like long lines. I remembered mediawiki being really weird when it comes to lists, so I didn't change the line length initially (I also try to match the code style of any project I contribute to).
But shorter lines makes it much easier to work with text, I agree. So I added a commit at the beginning that does some formatting.
IMO the deeply nested lists don't become easier to read with this. So I opted for just keeping the long lines there for now. Let me know if you think it's worth changing those.
The alternative of course would be to move over to markdown completely. Which I'm not sure is a documented process?
Sounds good to me! |
This re-formats the document for easier editing and diff viewing. Wiki syntax is weird for lists and line wraps break them. Simple lists were changed to <ul> or <ol> tags but complex lists remain as they are to not bloat the diff too much.
This fixes small inconsistencies or incomplete definitions based on previous, already merged changes.
This addresses two discussion items: - The list of UTXOs should not be interpreted as a "proof that no other UTXOs for an address exist". - The BIP only addresses "signer receives funds with the address" and not "signer sent a previous transaction" use case.
guggero
force-pushed
the
bip-0322-finalization
branch
2 times, most recently
from
f3ffd34 to
7809e72
Compare
|
I updated the prefixes to be fixed-size ( @murchandamus I don't really understand the failing CI check... Am I supposed to change the background color of the row in the README? |
|
I've implemented the proposed changes (prefix, Proof of Funds format) in the |
Since the term "signature" can be pretty overloaded dependin on the context, we clarify what it actually means in this BIP.
This commit proposes a fix for the problem that an offline verifier previously was not able to even verify the witness stack of additional inputs. By providing the full finalized PSBT, a verifier has all the input data necessary to run the script through the validation engine. We require the PSBT to be finalized to make sure it contains the final script witness or final script sig but no extra potentially privacy-sensitive fields. The Non-Witness and Witness UTXO fields are explicitly allowed for finalized PSBTs, which makes the format perfect for the use case.
This commit proposes a new PSBT input field type for transporting the message to be signed to different signers in a multisig signing use case.
This commit updates the test vectors to reflect all the changes in the previous commits and also introduces new test vectors for the Proof of Funds variant.
guggero
force-pushed
the
bip-0322-finalization
branch
from
d9d4bf3 to
1ee1a21
Compare
murchandamus
left a comment
murchandamus
left a comment
There was a problem hiding this comment.
Finished my first pass. I think it’s great that you want to pick up this proposal and bring it up to speed. Strong concept ACK. You also seem to have buy-in from @kallewoof, which is great.
Given the age of the proposal and the breaking change, I would heartily recommend that you write to the mailing list about the changes you are proposing in this PR.
| To support backward compatibility with implementations of this BIP before it was finalized, a | ||
| verifier might assume the ''simple' variant in the absence of a prefix. |
There was a problem hiding this comment.
This sounds like it warrants a Changelog entry. Could you please record the breaking change there?
You can find guidance about that in BIP3 here: https://github.com/bitcoin/bips/blob/master/bip-0003.md#changelog-section-and-version-header
| Comments-Summary: No comments yet. | ||
| Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0322 |
There was a problem hiding this comment.
I took a look at the comments wiki page. It just contains a couple questions and a link to this Bitcoin Talk discussion: https://bitcointalk.org/index.php?topic=5408898.l0.
I did not read the discussion, but if you find it interesting, you could add it as an entry to the "Discussion" header. You would then be free to drop the Comments headers as they are not required per BIP3 and the page doesn’t seem useful to me for this BIP.
| | Karl-Johan Alm | ||
| | Specification | ||
| | Draft | ||
| | Complete |
There was a problem hiding this comment.
You also need to update the background color in line 1075 (above) to
|- style="background-color: #cfffcf"
There was a problem hiding this comment.
To clarify, that’s the cause of the CI failure.
| | Generic Signed Message | ||
| | <tt>PSBT_IN_GENERIC_SIGNED_MESSAGE = 0x21</tt> | ||
| | [[bip-0322.mediawiki|322]] | ||
| |- |
There was a problem hiding this comment.
cc: @achow101, no action required, just wanted to make you aware of this overlap with PSBTs, in case you had thoughts on PSBTs being used for Generic Message Signing.
| == Changelog == | ||
|
|
||
| * '''1.0.0''' (2026-04-15): | ||
| ** Mark Complete | ||
| * '''0.0.1''' (2018-09-10): | ||
| ** Proposed as draft |
There was a problem hiding this comment.
BIP322 has been out there for nigh a decade and I think there are some implementations of it in production. From what I understand this update includes a breaking change to the format. While it was in Draft status and changes should still be expected, this may come as a surprise due to the age of the proposal. Therefore, I would request that you clearly document the breaking change in the Changelog and write to the mailing list about this update to BIP322.
There was a problem hiding this comment.
When you start versioning the document per a Changelog section, please also add the Version header to the preamble!
murchandamus
left a comment
murchandamus
left a comment
There was a problem hiding this comment.
Oh one more observation:
| <ol> | ||
| <li> | ||
| They construct <code>to_spend</code> and <code>to_sign</code> as specified above, using the | ||
| scriptPubKey of ''A'' for <code>message_challenge</code> and tagged hash of ''m'' as | ||
| <code>message_hash</code>. | ||
| </li> | ||
| <li> | ||
| Optionally, they may set nLockTime of <code>to_sign</code> or nSequence of its first input. | ||
| </li> | ||
| <li> | ||
| Optionally, they may add any additional inputs to <code>to_sign</code> that they wish to prove | ||
| control of. | ||
| </li> | ||
| <li> | ||
| They satisfy <code>to_sign</code> as they would any other transaction. | ||
| </li> | ||
| </ol> |
There was a problem hiding this comment.
Thanks for changing the formatting to shorter lines!
I am not sure what you mean about Mediawiki having issues with lists, I wasn’t aware, but if it helps, I wouldn’t have minded longer lines in lists. The HTML list syntax (…<ol><li>…) strikes me as more visual clutter in the source code compared to the Mediawiki syntax. It looks fine in the rendered document, though, so no need to change it again.
murchandamus
added
PR Author action required
murchandamus
added
the
BIP Update by Owner
4 participants
This PR is an attempt to push this PR forward, hopefully closer to a
Completestate.If it helps the process and @kallewoof agrees, I'm volunteering to be named as a deputy for this BIP.
The PR addresses the following discussion items:
TODO (will follow up with these items soon):
btcdpull request to reflect above changes, update test vectors in this PR (prefix and Proof of Funds implementation)@murchandamus I went through the different discussions you linked and also both Bitcoin Core PRs and tried to extract all discussion items that I felt were not yet addressed.
If anyone feels like a previous discussion item is missing here and not yet addressed by my changes, please comment below!