It seems like this latest proposal by Jeremy Rubin would be a way of enabling complicated constructions in wallets using key tweaks rather than Bitcoin script. I think the basic version of this is that if you can give different parties keys that are related to each other, you can mimic the effect of keys that only work under certain conditions -- which is what covenants are.
Bitcoin already leverages x-only key tweaking (for example, Taproot internal to output key derivation). Exposing a minimal, consensus-enforced version of "add a generator multiple to this key" inside tapscript:
- Enables script-level key evolutions (e.g., variable dependent authorized keys) without full signature verification at each step.
- Supports scriptless-script patterns where spending conditions are realized by transforming keys rather than revealing preimages.
- Allows compact covenant-like constructions where authorization is carried by key lineage, while keeping semantics narrowly scoped.
The operation mirrors the Taproot tweak used by BIP340 signers and enables simple, verifiable key modifications inside script without revealing private keys or relying on hash locks.
There haven't been any replies to Rubin on the Mailing List yet, and only a little bit of conversation on Github. I'm interested to see what people who are more knowledgeable about this than I have to say.
As a side note (and at the risk of stating the obvious): I wonder if why it seems so difficult to build consensus around a softfork that upgrades bitcoin script is because there are so many options?