> while in the coin set model each puzzle (scriptpubkey) gets run and either assert fails or returns a list of extra conditions it has, possibly including timelocks and creating new coins, paying fees, and other things.
Does this mean it basically gets recursive covenants?
Or is a condition in this list of conditions written a more restrictive language which itself cannot return a list of conditions?
The conditions language is extremely restrictive but does allow for recursive covenants through the route of specifying output scriptpubkeys/puzzles, which Bitcoin already sort of in principle supports except that Bitcoin script's ability to generate and parse transactions isn't quite up to the task.
> A lot of this is because there's a hook for doing compression at the consensus layer which isn't being used aggressively yet. That one has the downside that the combined cost of transactions can add up very nonlinearly, but when you have constantly repeated bits of large boilerplate it gets close and there isn't much of an alternative. That said even with that form of compression maxxed out it's likely that gzip could still do some compression but that would be better done in the database and in wire protocol formats rather than changing the format which is hashed at the consensus layer.
How different is this from "jets" as proposed in Simplicity?
My vague impression is that Simplicity jets are meant to be for things like Sha3 rather than shared library code. It might be that the way to use it would be to implement CLVM opcodes be a bunch of Simplicity jets. Whether that would be making the CLVM irrelevant or going through a pointless bit of theatre to be based on Simplicity under the hood I don't know.
The compression hook is that in each block instead of there being a list of puzzle reveals and solutions there's a generator written in CLVM which outputs that list, and it can be passed the generators of old blocks from which it can pull out code snippits.