Make bind_psbt function use SIMPs, not mock outputs, for adding inputs about sapio HOT 6 OPEN

I'd imagine this would be a SIMP "attachable at" the transaction template?

from sapio.

i think it could be a couple different areas, with different meanings...

e.g., at the Object --> all descendants should be emulated thus
at the guard --> this term in this guard should be emulated thus
at the template --> this template should be emulated thus

Maybe the guard is the best place for it?

from sapio.

What if we created an arm of Clause that has a dyn Emulated or something to that effect?

I'm less excited about locating it within the Object or Template I think on second thought. The reason being that the only benefit I can imagine is smaller resident memory. If we have that problem we can do the optimization later. Conceptually it belongs at the guard as best I can tell.

from sapio.

We can't modify Clause easily, since it's upstream rust-miniscript.

further, dyn Emulated can't go into the Clause AST since the miniscript policy needs to be able to parse from a script (kinda...).

from sapio.

Got it, maybe we need a different data structure at the guard level that does a pass translating a hypothetical dyn Emulated into a combination of SIMPs and Polcy fragments. I guess for now we can just do what we were going to do in the output of that pass now and then worry about a more unified and ergonomic approach later.

The reason I say this is that it would be preferred for users to not have to think about where exactly their intents get wired up into the technology stack. I'm imagining here that the ideal ergonomic interface for users is to have some single predicate language to express guards, and if the compiler is configured to handle certain predicates with emulation then it does the SIMP insertion itself.

It occurs to me, though, that this ticket isn't about the CTV emulation and so maybe I've taken this ticket off track. Can you elaborate on the connection between "emulated thus" and "SIMPs ... for adding inputs"

from sapio.

No i think i took it off the rails, this should be in the other SIMP issue I think I got my wires crossed on emulation API v.s. inputs.

for this issue, you should probably use SIMPAttachableAt

for the other issue, the reason we don't want to just use some sort of dyn Emulated stuff is we want the contract to be able to declaratively specify any presigned txns it should be getting before proceeding from any source (including cached from last run), and those can't be deeply embedded in some AST. We can move this discussion to that ticket tho.

from sapio.