I've been thinking about this as well.

A useful way to look at it IMHO is to see a hash as the analogue of a public key, and the preimage as the analogue of a signature.

That would suggest adding two fields to PSBT:

* A request for the preimage of a given hash (similar to the pubkey/path field currently)

* A revealed preimage for a given hash (similar to the partial signature field currently).

The workflow would in this case would be:

* An updater recognizes an output/script as being one that requires a preimage, and adds a preimage request field to the input (along with pubkey fields for all involved keys).

* A "signer" who knows the preimage sees the request field, verifies he's willing to divulge the secret, and adds a preimage field (along with any signatures he may be able to create).

* A finalizer who is compatible with the type of hashlock script combines all signatures and preimages into a final scriptSig/witness stack.

An obvious difficulty is having updaters and finalizers which are compatible with all possible variations of hashlocks and other scripts.

That's one approach to reducing the complexity of the finalizer: adding information about the composition of the scriptSig to the PSBT itself. However, I don't think that approach scales very well (you'd need new fields for all kinds of new script constructions). In particular, dealing with multiple possible satisfactions may complicate things, especially when the number of combinations is intractable.

I've been working on another approach that doesn't involve changes to PSBT, but instead uses an easily-parsable subset of script (which includes and/or/threshold/pubkey/locktimes/hashlocks). I hope to publish something soon about it.

Cheers,

-- 

Pieter