[Draft] BIP322 Implementation#240
[Draft] BIP322 Implementation#240rajarshimaitra wants to merge 2 commits intorust-bitcoin:masterfrom
Conversation
This PR implements a BIP322 generic message signer with Bitcoin Scripts.
sanket1729
left a comment
There was a problem hiding this comment.
Did not review the test. I think we should first focus on the BIP322Validtor struct which should only have msg, sig, and scriipt_pubkey.
Then, we can use the interpreter to automatically infer the descriptor. Look at from_txdata function.
The last step is correct where we interpret the descriptor.
Let us try to fix the above in this iteration.
Next, we can focus on extending to height and age and using satisfy API for signing logic.
src/bip322.rs
Outdated
There was a problem hiding this comment.
We cannot use crate:: because that will cause rustc 1.29 to fail.
src/bip322.rs
Outdated
There was a problem hiding this comment.
I think we should use const instead of static.
There was a problem hiding this comment.
It would be great if we have a test similar to https://github.com/rust-bitcoin/rust-bitcoin/pull/259/files to verify the value is computed correctly
src/bip322.rs
Outdated
There was a problem hiding this comment.
A more expressive doc comment
| ); | ||
|
|
||
| /// BIP322 Error types | ||
| #[derive(Debug)] |
There was a problem hiding this comment.
Would be great to derive all possible things that we can derive.
There was a problem hiding this comment.
There's not much to drive here as InterpreterError only derives debug.
rust-miniscript/src/interpreter/error.rs
Lines 20 to 21 in 86a63d8
src/bip322.rs
Outdated
There was a problem hiding this comment.
I think we should consume the message instead of the new allocation.
src/bip322.rs
Outdated
There was a problem hiding this comment.
I don't like that the addr variable for the descriptor. See detailed comment later for the suggestion of BIP322Validator struct
There was a problem hiding this comment.
renaming addr to mesage_challenge.
Message challenge can be two things. Either descriptor or a Script structure. Throughout the logic currently, we are simply using descriptor.script_pubkey() to derive the message challenge script. We can as well use a script_pubkey directly here as no descriptor specific functionality is used anywhere. But I think it's better to keep the descriptor here to make the API easier for complex challenge scripts. Otherwise, lib users need to construct the script. Also, we can use the descriptor in the future if such functionality is required.
Will update if that's not acceptable for other reasons.
|
|
||
| // create and return final transaction | ||
| Transaction { | ||
| version: 0, |
There was a problem hiding this comment.
I have made a comment to BIP322 to make this always 2 and it was positively received. I think we should keep it always 2.
src/bip322.rs
Outdated
There was a problem hiding this comment.
This should take a satisfier as an argument and should call satisfy to fill the witness and script sig.
There was a problem hiding this comment.
This should also take in the age and height as arguments instead of hard coded zeeros
There was a problem hiding this comment.
Changing to_sign to empty_to_sign.
The purpose of this function is to create an empty to_sign transaction template, which then can be filled with the correct signature depending upon the BIP322Signature types. Which is currently happening inside the validate() function here.
Lines 180 to 211 in c740598
Here we are mutating the empty to_sign transaction with corresponding signatures. Which can be done with a satisfier too. But because a Bip322Signature::Full type signature will contain the entire to_sign transaction itself (which I think will be most of the cases, the other two cases are rather simplistic and more specific so can be hardcoded easily), using a separate satisfier to create the same to_sign feels like more roundabout than necessary.
Bip322Signer probably needs to use a satisfier in some way, but we can flesh that detail out later.
For age and height, I think it's better to provide these values in the validator structure itself. Though I am not sure if I have applied these values correctly in the empty_to_spend creation, please check.
|
|
||
| /// Validate a BIP322 Signature against the message and challenge script | ||
| /// This will require a BIP322Signature inside the structure | ||
| pub fn validate(&self) -> Result<bool, BIP322Error> { |
There was a problem hiding this comment.
We should reproduce the errors states from the BIP. This should return Result<(T, S), BIP322Error> where BIP322Error should either be Inconclusive(..) or Invalid(..)
There was a problem hiding this comment.
Is it possible to somehow derive these error types from the IterpreterErrors?
Also if I understand it right, neither to_spend nor to_sign transactions are supposed to be mined. They are not validated against the chain. So what the purpose of T and S here and how the validator is supposed to validate Time and Age of an unmined transaction? Also, what does it mean to have a signature against a message only valid "after x time"? These are not transactions, but simple generic messages.
|
Updated with changes. This is ready for the next review. |
Ref #159
This is a draft implementation of the BIP322 generic message signer using Bitcoin scripts.
There are a lot of rough edges to iron out. Looking for generic approach comments. The approach might be completely wrong, as it only reflects my own understanding after reading the BIP.
So far the signer can only validate
messageandmessage_challengegiven thesignature(of type Legacy/Simple/Full).A simple test case for these three types of signature validation included.
Looking for comments to figure out the rest of the required details.