elementsproject / elements-miniscript Goto Github PK

So, to handle the existing checksigs we have the user pass in a closure. There were two reasons for this

• To check normal signatures you need to compute a sighash, which is hard to do from the interpreter
• I wanted to be able to interpret miniscripts without checking the signatrues, since this is really expensive and doesn't give you much value if you're checking things that are in the chain anyway

I have a couple thoughts about how we could handle this here

• Not check the signature and offer no way to do so (this seems like a bad idea)
• Make the user pass a second closure in for this (ughh)
• Adapt the existing closure to take a message hash (ugly, doesn't really match the existing closure signature)
• Replace the existing closure with an optional secp context argument (but then how can we compute the sighash for normal checksigs?)
• Require our signatures to have R = P = 1, and then we can verify the signature with :P

None of these are really clean, but I'm leaning toward adding a second closure to the API.

Originally posted by @apoelstra in https://github.com/sanket1729/elements-miniscript/pull/4#discussion_r584986887

The hyperlink on your READ.ME has a typo https://docs.rs/elemnents-miniscript leads me to a dead page

Using an xprv as a "view" descriptor blinding key does not provide any benefit wrt to using a single "view" key.
The "view" key is tweaked with the script pubkey so it's not reused.
And using an xprv derived from the wallet seed is not compatible with HWWs,
since they don't export private keys.
So it makes sense to use 32 byte private key as "view" descriptor blinding key.

However this seems not to be supported by the current implementation.

use elements_miniscript::descriptor::checksum::desc_checksum;
use elements_miniscript::{ConfidentialDescriptor, DefiniteDescriptorKey, DescriptorPublicKey, Error};
let descriptor_blinding_key = "9c8e4f05c7711a98c838be228bcb84924d4570ca53f35fa1c793e58841d47023";

let xpub = "tpubDD7tXK8KeQ3YY83yWq755fHY2JW8Ha8Q765tknUM5rSvjPcGWfUppDFMpQ1ScziKfW3ZNtZvAD7M3u7bSs7HofjTD3KP3YxPK7X6hwV8Rk2";
let desc = format!("ct({},elwpkh({}))", descriptor_blinding_key, xpub);
let desc = format!("{}#{}", desc, desc_checksum(&desc).unwrap());

let expected_err = Error::Unexpected("Error while parsing xkey.".into());
let err = ConfidentialDescriptor::<DefiniteDescriptorKey>::from_str(&desc).unwrap_err();
assert_eq!(err, expected_err);
let err = ConfidentialDescriptor::<DescriptorPublicKey>::from_str(&desc).unwrap_err();
assert_eq!(err, expected_err);

Adding this to miniscript/mod.rs results in a panic.

    #[test]
    fn test_regression_29() {
        let _ = Descriptor::<String>::from_str("eltr(,thresh(1,spk_eq(,00)))");
    }

assertion failed: self.mall.non_malleable || self.corr.input != Input::Zero', /store/home/apoelstra/code/ElementsProject/elements-miniscript/fuzzing/src/miniscript/types/mod.rs:556:9

Are we sure elements miniscript is also safe from MinimalIF bug?
https://github.com/rust-bitcoin/rust-miniscript/blob/master/doc/security_report_2022_04_20.md

Display impl

has "el" prepended but the FromStr impl seems to not have it

Those have small differences but they are basically the same thing,
which one should be used by downstream libraries?

Is this comment referring to this fixed bug ? BlockstreamResearch/rust-secp256k1-zkp#55

cc @sanket1729

We would be interested in an extension of this library to allow expressing a spending condition that looks like this:

• Require message and signature on message with respect to oracle_pk.
• Require decomposed message to meet some conditions e.g. first half is > fixed value; and second half is <= than a different fixed value.

This could look something like oracle(pk,gt(100),lte(50)). Obviously at this stage there are many questions to answer such as, how to divide the message, how many and what conditions can be checked etc. This is just a very basic idea.

The bigger questions are:

• Do you have any plans to introduce a feature like this into the library?
• Would you accept a contribution to the library that adds a feature like this?

Here's an example of the kind of Elements script behaviour we would like to be able to express using this library.

Just wanted to report that in a downstream lib elements-miniscript is the biggest contributor in binary size, maybe because it uses a lot of generics:

$ cargo bloat --release --crates
 File  .text     Size Crate
 9.6%  29.9%   1.9MiB elements_miniscript
 6.7%  21.0%   1.3MiB wollet
 4.2%  12.9% 833.4KiB std
 1.9%   6.0% 388.4KiB elements
 1.8%   5.7% 365.4KiB serde_cbor
 1.6%   5.1% 328.8KiB [Unknown]
 1.3%   4.1% 266.4KiB rustls
 0.9%   2.9% 185.3KiB ring
 0.7%   2.1% 138.5KiB electrum_client
 0.4%   1.2%  78.0KiB simplicity
 0.3%   1.0%  65.9KiB serde_json
 0.3%   1.0%  64.2KiB bitcoin_hashes
 0.3%   0.8%  53.0KiB signer
 0.2%   0.7%  43.7KiB bitcoin
 0.1%   0.4%  26.9KiB uniffi_core
 0.1%   0.4%  26.1KiB secp256k1_sys
 0.1%   0.4%  25.0KiB miniscript
 0.1%   0.4%  24.7KiB ks_bindings
 0.1%   0.3%  19.3KiB secp256k1_zkp_sys
 0.1%   0.3%  17.2KiB bip39
 0.6%   2.0% 129.8KiB And 41 more crates. Use -n N to show more.
32.2% 100.0%   6.3MiB .text section size, the file size is 19.6MiB

$ cargo bloat --release -n 10
 File  .text    Size               Crate Name
 0.2%   0.7% 45.6KiB elements_miniscript elements_miniscript::miniscript::decode::parse
 0.2%   0.7% 44.7KiB elements_miniscript elements_miniscript::miniscript::decode::parse
 0.2%   0.7% 44.7KiB elements_miniscript elements_miniscript::miniscript::decode::parse
 0.2%   0.7% 44.2KiB elements_miniscript elements_miniscript::miniscript::decode::parse
 0.2%   0.7% 43.2KiB elements_miniscript elements_miniscript::miniscript::decode::parse
 0.2%   0.7% 43.2KiB elements_miniscript elements_miniscript::miniscript::decode::parse
 0.2%   0.7% 42.7KiB elements_miniscript elements_miniscript::miniscript::decode::parse
 0.2%   0.5% 32.4KiB              wollet wollet::clients::BlockchainBackend::full_scan
 0.2%   0.5% 32.2KiB elements_miniscript elements_miniscript::descriptor::csfs_cov::cov::Le...
 0.1%   0.4% 22.9KiB            elements <elements::transaction::Transaction as elements::e...
29.8%  92.4%  5.8MiB                     And 11982 smaller methods. Use -n N to show more.
32.2% 100.0%  6.3MiB                     .text section size, the file size is 19.6MiB

Displa

has "el" prepended but the FromStr impl seems to not have it

Rather than returning a String this should really use the alternate flag on a Formatter, for efficiency reasons. But regardless of efficiency, currently this function just calls Debug instead of Display which does not do the right thing. In particular the "no checksum" output wraps public keys in PublicKey(...).

cc rust-bitcoin/rust-miniscript#477

Firstly, we are really benefiting from your library in our project, so thanks for that!

After introducing the git dependency we are no longer able to release to crates.io. Do you know when you will be releasing elements-miniscript to crates.io?

I find very useful for developers to have a way to make use of new fragments that maps to the new introspection opcodes, very useful for making covenants.

DO you have an idea if this fits the purpose of Miniscript and, if yes, what could be a timeline, especially for an initial agreement on the spec? We are implementing in other languages descriptors/miniscript for Elements, so would be cool to work in parallel as soon there could be consensus