Introspection about elements-miniscript HOT 8 OPEN

For the time being in our descriptor parser, we are introducing a custom asm fragment that let user to load arbitrary opcodes so we can mix them with current fragments.

I know that this is useless since makes impossible to analyze etc.. but we only want a way to share these opcodes in a formal way, and use descriptor/miniscript when possible already.

Be careful with this! It's not only the asm fragment itself that is "impossible to analyze" but the entire Miniscript that contains it. But this is likely a reasonable way to proceed for research & development.

With Simplicity we will be able to provide asm in the main library since Simplicity's type system can be leveraged to prevent arbitrary code inside one fragment from messing up code in other fragments, without requiring we have a fixed curated set of fragments.

from elements-miniscript.

DO you have an idea if this fits the purpose of Miniscript

Yes -- well, Elements Miniscript at least. Naturally we can't support this in the "real" Miniscript until Bitcoin has some form of introspection ability.

if yes, what could be a timeline,

My hope was "already" but our upstream re-architecture for Taproot took much longer than expected. Let's say "2 months".

especially for an initial agreement on the spec?

That will take longer. Initially we'll just stick some new fragments in to solve practical problems that Blockstream and other Liquid developers are trying to solve. It will take some iteration before we're confident that we've gotten the right set of fragments and that we've implemented them optimally.

We are implementing in other languages descriptors/miniscript for Elements, so would be cool to work in parallel as soon there could be consensus

I think your best bet is to keep up with the current state of this library, provide feedback, yell at us if we change things in ways that break your applications, etc. If you actually deploy something in production using a certain set of fragments we will be careful not to break things after that.

from elements-miniscript.

My current need is giving a way to users to load complex script types into Marina Wallet, so it can track balances and spend them if solvable/can sign so to speak.

There is no way to express with current fragments things like CSFS, CAT, new arithmetic opcodes or introspection ones. I understand it will come, so will keep an eye.

For the time being in our descriptor parser, we are introducing a custom asm fragment that let user to load arbitrary opcodes so we can mix them with current fragments.

I know that this is useless since makes impossible to analyze etc.. but we only want a way to share these opcodes in a formal way, and use descriptor/miniscript when possible already.

eltr( <internalPubKey>, { asm( <'hello'> <'🌎'> OP_CAT OP_SHA256 <alicePubKey> OP_CHECKSIGFROMSTACK) }

If you actually deploy something in production using a certain set of fragments we will be careful not to break things after that.

Will try to write here the synthetic asset smart contract and propose some new fragments for new opcodes so maybe we can make some early thoughts.

from elements-miniscript.

"impossible to analyze" but the entire Miniscript that contains it

Yep! Totally understood. User will know this is a very reckless feature and they need to be 100% sure of the asm code they are loading.

The idea is just to have a way to share opcodes at runtime for script path spends and implicitly tell the type of address shall be generated. We only parse the descriptor, detect the top level fragment and if a CHECKSIG op is there with a pubkey, the wallet will fill it with his own. So in the end we are NOT using Miniscript at all.

As soon all the new opcodes will be mapped to Miniscript, will likely drop this asm fragment and maybe at that point use this library directly (maybe compiled to WASM to run in the browser if you will provide bindings)

from elements-miniscript.

Have you looked at the Extensions in the library? If you want to create any new fragments. You can do it downstream by implementing the Extension trait.

However, in this case, you are responsible for making sure that the fragment can be parsed unambiguously by the miniscript parser.

from elements-miniscript.

That looks interesting.
Not that much experience in Rust tho, would wait for the reference implementations and examples eheh :)

We pretty close to finish our TypeScript descriptor parser btw, we added asm fragment as temporary solution and we made sure is valid only inside TREE of a eltr descriptor, new opcodes must be used in tapscripts anyway. Will drop it as soon new fragments are there and/or with extension trait.

from elements-miniscript.

Hello @tiero, introspection support with arithmetic operations is now supported. See https://github.com/ElementsProject/elements-miniscript/blob/master/doc/extension_spec.md for details. Still awaiting #28 to be merged

from elements-miniscript.

Amazing @sanket1729

We plan to add support to our ionio-lang.org compiler for these elements-miniscript fragments, to allow to parse miniscript and compile to opcodes, generating an Ionio Artifact JSON in the process, so SDK(s) and libraries can easily spend taproot output scripts.

from elements-miniscript.