waxwing on Nostr: I wanted to communicate about this idea of Jeremy Rubin, because I'm not sure how ...

I wanted to communicate about this idea of Jeremy Rubin, because I'm not sure how easily people will understand what he's saying:

https://rubin.io/bitcoin/2024/05/29/fed-up-covenants/

An attempt to explain without mathematics: the ability to create an address that can only be spent in one specific transaction (the most basic/pure covenant), but without needing a new op-code or soft fork. How? Basically by taking advantage of a crypto technique called "functional encryption", you can let someone/anyone make a signature to pay out of an address by "decrypting", but the decryption will only work for the single transaction you intend.

There are basically two problems with this apparently magical trick; one small, one big.

The smaller problem: to make this flexible structure needs a trusted setup: you create an initial (bitcoin) private key and an initial encryption key, and they must deleted at the end of the setup, otherwise the mechanism described above won't be safe from anyone who knows those keys.

The bigger problem: generalised functional encryption as described here, i.e. "give a decryption key for the output of a general function f, given the encryption of the input of the function" doesn't really exist as far as I know, except in theory. There are papers from the last decade that develop and extend more limited variants, such as "inner product encryption" which implements the idea for only the function of (take the inner product of the input with a given other value/vector), but (*and I could be wrong here) we are a long way from having it at the level where the function could be "schnorr signature of inputs (private key, transaction hash)" (though JR references ECDSA, it seems way more reasonable to go with Schnorr, since it's a simpler formula).