Can "hal-simplicity simplicity pset" autodetect more transaction parameters?

[schoen]

I just published some documentation about this tool at

https://docs.simplicity-lang.org/documentation/toolchain

This adds more detail in comparison to the CLI help, so hopefully it will be helpful to users (or maybe even to LLMs learning to help users accomplish tasks with Simplicity).

One thing I noticed when revisiting the hal-simplicity simplicity pset subcommands is how much we have to repeat different parameters such as the CMR, asset ID, scriptPubKey, etc., when updating the PSET. I seem to remember that @apoelstra thought that at least some of these could actually be extracted from details of the transaction or elsewhere in the PSET itself, although I realize that a conceptual challenge is that the underlying UTXO that we are requesting to spend merely assertedly exists and hal-simplicity doesn't actually download and analyze the UTXO in order to confirm that everything matches or exists. So some parameters may simply be inherently unavailable.

Anyway, it would be nice to streamline some of the PSET building in some way so that users don't have to provide quite as many parameters and don't have to repeat them quite as many times.

A more controversial version (which might be considered a kind of layering violation) would be to have some option to actually literally make a network connection and download the UTXO (or extract it from a local elementsd instance) and analyze it it order to find all the relevant parameters. So if I say I want to spend a6394634574d7b20b7f8ae312c579a7d2316ff493882ef4f74af3ac7a15e1e6c:0 then maybe the tool could literally go get a copy of it and find out all the details that are actually in that UTXO, as an alternative to looking them up with other tools and then transferring them into hal-simplicity simplicity pset. Again, maybe a layering violation in some sense.

[apoelstra]

We would need to extend PSET to include any fields that we want to add.

download the UTXO

All a UTXO has is a Taproot output. It won't provide any more information than we have.

[schoen]

I think the biggest practical example of what I'm thinking of might be the -i argument to hal-simplicity simplicity pset update-input. In the bash demo scripts this looks like -i "$HEX:$ASSET:$VALUE". If hal-simplicity actually had the underlying prior transaction, couldn't it extract the -i parameters from that prior transaction? Isn't that what we're doing ourselves when we ourselves manually or programmatically copy those details from elements-cli or the Esplora API?

[apoelstra]

Ah, yes, -i could be replaced by an API call.