Miniscript fragment to check conditions on signed message about elements-miniscript HOT 9 CLOSED

Would you accept a contribution to the library that adds a feature like this?

Yes, we are open to add new fragments to miniscript.

There are a couple of things that we need to make sure:

1. The mapping for script <-> miniscript is not disturbed in any way. Bitcoin scripts should be able to translate to miniscript without any ambiguity.
2. The fragment should not unnecessarily constraint the design space for future extensions.

It would be much simpler and justifiable for us to integrate this as a single fragment oracle_<some_name>(pk,num1,num2) which would expand to the corresponding complete script which includes the OP_LTE, OP_CAT, OP_CSFS etc.

I think having support for general fragments like lte and gt is more tricky. Fundamentally, Miniscript is not meant to represent computation results, but rather constraints the inputs must satisfy. So, at first glance, I am against having general le or ge type fragments because they don't directly represent a spending condition like ver_eq, after, or outputs_pref.

from elements-miniscript.

@apoelstra @thomaseizinger what do you think? I think this should work, but don't really know what might go wrong without actually implementing it

We've moved on to a different approach (DLC style oracles) and hence at least from our perspective, there is no more immediate need for this feature. I am happy to keep this open in case someone else comes along with a similar usecase :)

from elements-miniscript.

If you need this in the future for any other project, #13 introduces an Extension trait that can be implemented downstream to support it as a miniscript leaf fragment.

As long the fragment reads inputs from stack top(and does not touch anything apart from it's inputs), and be parsed from script without any ambiguity, all guarantees of miniscript should hold.

from elements-miniscript.

It would be much simpler and justifiable for us to integrate this as a single fragment oracle_<some_name>(pk,num1,num2)

It's very good to know that you're open to adding a more specific fragment, because it should be easier to design and develop.

I think having support for general fragments like lte and gt is more tricky. Fundamentally, Miniscript is not meant to represent computation results, but rather constraints the inputs must satisfy. So, at first glance, I am against having general le or ge type fragments because they don't directly represent a spending condition like ver_eq, after, or outputs_pref.

This does make sense. In the example, le and ge would only be valid in the context of the oracle fragment, but I'm not sure how one would do this or if it's even a good idea.

Overall, I think it makes sense to first create something concrete such as a new fragment that defines a very specific spending condition using OP_CSFS and an oracle signature, and maybe in the future evolve it into something more general.

from elements-miniscript.

At the moment, we are hacking together normal Bitcoin script with miniscript to achieve this functionality. It is still very early stage for the kind of functionality that we are building. Hence, trying to come up with a more abstract design that fits into miniscript but also solves our problem is very hard at the moment.

Would it worthwhile to explore a design around miniscript plugins? A plugin could define its own fragment name, a mapping to script, a function for satisfaction and whatever else is necessary.

That way, we could experiment with different fragment designs outside of the miniscript library itself and potentially incorporate them back in if a design proves useful.

Miniscript could place constraints on the kinds of scripts a plugin can return to make sure some invariants are not violated (i.e. modifying the stack in some wild way)

from elements-miniscript.

A bit more context on our problem:

At the moment, we are building non-custodial loans on top of Liquid and for this, we need to account for liquidation of collateral in the event of a price drop. The message from the oracle contains timestamp and price. This boils down to the requirement of:

1. Checking for the correct price: Liquidation is only allowed if price drops below a certain value.
2. Checking for the correct time: Liquidation is only allowed if the signed price is the current price, i.e. not a price from 100 days ago. In particular, signed prices from before the contract creation are not allowed.

The way we are solving this at the moment is that the oracle signs the hash of two concatenated LE- encoded integers (price and time). This message is then re-constructed on the stack and checked using OP_GREATERTHAN / OP_LESSTHAN against values hardcoded in the contract script.

We've chosen this approach over DLCs because it scales better (no storing of 1000s of encrypted signatures). We are also aware of the privacy implications and hope that we can fix this partially using tapscript in the future through optimistic privacy using cooperative spending transactions.

Where does miniscript come into this? Well, at the moment, we are hacking together miniscript and regular OP codes to make this work. It would be nice if miniscript would allow us to express these spending conditions somehow.

The hard part here is that the comparison against the oracle's message is not just a simple equality check. In other words, it is not sufficient to say: "If the oracle signs this message, spending should be allowed." Instead, we want to allow for further checks on these spending conditions like GT and LT in our case. I would assume that - for anything to be included in miniscript - we would need to figure out a more general approach here but I don't yet know, what that could look like. Any input is highly appreciated :)

from elements-miniscript.

@sanket1729 suppose we had a fragment like assert_geq(X, 100) which would leave X on the stack if it were >= 100, and otherwise fail the script.

I'm not sure this fits into any of the Miniscript types but I think it does fit into the Miniscript model.

from elements-miniscript.

Sorry for the delayed response. I was busy with implementing new opcodes for elements that will deployed to liquid soon. This may be of interest to your project. https://github.com/ElementsProject/elements/blob/master/doc/tapscript_opcodes.md

Miniscript could place constraints on the kinds of scripts a plugin can return to make sure some invariants are not violated (i.e. modifying the stack in some wild way)

I think this is the way to go, though I don't know what is the best rustic way to do this. Ideally, there would be a trait like Extension with required methods and we can extend it. Right now, for any extension we need to add an enum to Terminal.

This commit adds an OutputsPref (which I believe you are using in your covenant script). b47a455 .

Here is a suggestion for how we might implement plugins for Elements-miniscript.

• Change enum Terminal to take another generic Ext bounded by Extension trait.
• The extension trait has all methods specified here: b47a455.

@apoelstra @thomaseizinger what do you think? I think this should work, but don't really know what might go wrong without actually implementing it

This way anyone can add extensions to elements-miniscript. We would need to document the trait Extension properly to ensure that implementors do not alter the properties of miniscript.

from elements-miniscript.

yeah, I think I will attempt a more modular design so that anyone can extend miniscript by implementation a trait downstream. We also have a need for more miniscript extensions to elements-miniscript

from elements-miniscript.