Of course size limits would not be a problem if we had op_checktemplateverify. So why are size limits a problem for covenants on Bitcoin without a soft fork?

Lamport SignaturesLamport Signatures

All of this on the heels of the development of Lamport Signatures being done in Bitcoin script which (among many other things) allows for spends of P2SH and P2WSH outputs to be quantum resistant

The Bitcoin OpTech newsletter about Lamport Signatures can be found here: https://bitcoinops.org/en/newsletters/2024/05/08/

Covenants without a Soft ForkCovenants without a Soft Fork

Andrew Poelstra (a director, at Blockstream Research) commented in the mailing list:

Another reason this is useful is that if you have a Lamport signature on
the stack which is composed of SIZE values, all of which are small
enough to be manipulated with the numeric script opcodes, then you can
do covenants in Script.

(Sadly(?), I think none of this works in the context of the 201-opcode
limit...and absent BitVM challenge-response tricks it's unlikely you can
do much in the context of the 4MWu block size limit..), but IMO it's a
pretty big deal that size limits are now the only reason that Bitcoin
doesn't have covenants.)

source: https://mailing-list.bitcoindevs.xyz/bitcoindev/ZjD-dMMGxoGNgzIg@camus/

But then, there you have it. BitVM might be the final piece of the puzzle

I will remind you why I care about covenants, CTV, LNHance etc. Its because of the possibility of LNSymmetry/Eltoo (in spite of the trade off of removing the anti-deterrence mechanism of justice transactions) and for Timeout Trees, specifically timout trees created by a multi-party channel "Pleb LSP"

Also, you can't do LNSymmetry with covenants alone, its just when you add op_checksigfromstack (CSFS) that you can.

365 sats \ 1 reply \ @k00b 8 May 2024

When we say "size" we're talking about the opcode size limits?

108 sats \ 0 replies \ @nerd2ninja OP 8 May 2024

Both opcode size limit (if you don't use taproot) and block size if you do use taproot.

Andrew Poelstra later clarifies

Aside from limits on transaction size, post-Taproot script can verify a
trace of any program execution, as long as the individual elements it is
operating on fit into 4-byte CScriptNums. You can therefore implement
SHA2, ECDSA, etc., and reconstruct the pattern of SIZE elements by
feeding in transaction data. Which of course can then be arbitrarily
constrained.

Probably actually doing this would take more than 4 megs of script and
you would need to use some sort of BitVM tricks and the whole thing
might not work. But this was my point in saying that "only the script
limits are stopping us from having covenants".

And pre-Taproot we have only 201 opcodes so of course this is all
totally out of the question :) but plausibly we could make a copy of the
Lamport signature in a Taproot output and then use non-equivocation
slashing conditions to somehow make things work.

You can read the whole thread here: https://groups.google.com/g/bitcoindev/c/mR53go5gHIk/m/csQn7IdEAgAJ?pli=1