What is the current thinking on how new jets for Simplicity would be soft forked into Bitcoin (in a speculative future where Simplicity was already itself soft forked into Bitcoin)? What would happen if a miner mined a block with a new jet with a lower resource cost?
This question was asked by sanket1729 on IRC and has been paraphrased.
This was discussed by Russell O'Connor, the author of Simplicity on IRC. The following has been paraphrased, any errors are my own.
Jets would be written in Simplicity so that everyone agrees on the functionality of the jet. While jet functionality could be specified in any language, Simplicity is an obvious candidate specification language.
In v0 Simplicity it won't be possible to soft fork in new jets. You would need a new encoding scheme to support the new soft forked jets.
For later versions of Simplicity the current plan would be to incorporate the resource cost into the jet "name". There would be a certain kind of malleability where anyone can spend a UTXO by providing a proof (a branch) that there is a commitment to an unknown discounted jet. Old nodes would be presented with such a proof and new nodes would require a proper program. It is not clear what would go into the block's witness Merkle root at this point.
This plan would require new (as yet undesigned) P2P support rather than just using OP_SUCCESS. Peers would negotiate which version of the set of jets that they know about and the Simplicity fragments they know about. Hence you wouldn't necessarily need to (re)transmit common Simplicity functions that your peers already know about.
What prevents miners from maliciously mining an unknown discounted jet to DoS the network as peers would now need the entire program?
There is no encoding for new jets. Discounted jets are explicitly encoded. Illegal encodings cannot be legal because there is no way to validate that a program you cannot decode matches the commitment Merkle root.
Under this scheme miners can't mine an unknown jet. In order to do so they have to either prove that there is an output that is committed to such an unknown jet, and if no one has any commitments then they cannot be used, or they have to provide an encoding of a program that uses a new discounted jet, but my encoding scheme has no such encodings.
Unless a "this is an unknown jet with identity root" was added to the encoding scheme it would never be acceptable to have old nodes operate on discounted jets by running the undiscounted Simplicity code. The option was "I see an unknown discounted jet I ignore the entire script and just succeed". While that works well for Bitcoin script, it is problematic in the presence of disconnect / delegation and it could be a problem for Bitcoin Script too if it ever had direct delegation. If Bitcoin Script had OP_EVAL, and then you try to OP_EVAL something with an OP_SUCCESS in it what do you do? Hence the current plan is to require a new Tapleaf version or Simplicity version to change jets.