Subject: Re: [bitcoin-dev] Covenants and capabilities in the UTXO model

From: Bram Cohen <[email-masked]>
Date: Tue, 18 Jan 2022 09:16:25 -0800

On Tue, Jan 18, 2022 at 7:10 AM Billy Tetrud <[email-masked]> wrote:

> >  Since scriptpubkeys/scriptsigs continue to run ephemerally at
> validation time full turing completeness is much less dangerous than people
> fear.
>
> The covenant proposals I've seen that might give bitcoin turing
> completeness require a turing complete process to be stepped such that each
> step is a transaction paid for with a usual fee. This fact I think makes
> the turing completeness a lot less scary. No single transaction would be
> turing complete, while a sequence of them could be. But importantly, each
> transaction has a strictly limited runtime and every script could continue
> to have a calculable number of maximum runtime steps.
>

This flows naturally out of the UTXO model. In ETH you don't know how much
transactions will cost in advance because things don't declare their state
up front, but with all dependencies declared up front execution can be made
completely deterministic.

 > It would also probably be a good idea to add in a bunch of special
purpose opcodes for making coherent statements about transactions since in
Bitcoin they're a very complex and hard to parse format.

>
> What are some examples you're thinking of?
>

What's needed from a programming perspective is the ability to say 'assert
that my parent has a scriptpubkey of X'. That way you can, for example,
have a UTXO which only allows itself to be absorbed by a transaction also
involving a UTXO with a particular capability ('pay to singleton' is a term
for this) and that capability can be enforced by the scriptpubkey asserting
that either its parent is the originator of it or that its parent also has
the same type of scriptpubkey. This allows capabilities to be added without
gunking up on chain state with things other than UTXOs.

>
> > Once you start implementing complex general purpose functionality it
> tends to get very expensive very fast and is likely impractical unless
> there's a way to compress or at least de-duplicate snippets of code which
> are repeated on chain.
>
> I like this idea. If there was a way to dedupe scripts in some way, it
> could save a lot of bandwidth which would help bitcoin scale better. One
> thing we could do is have a specific set of pre-ordained script snippets
> that are given a shorthand that's stored in the software and explicitly
> shouldn't be transmitted long-hand. That would help for very standard
> widespread things. We could even add in a consensus rule where short-handed
> scripts pay for their expanded vbytes, not the vbytes of the compressed
> version. This would mean the incentives wouldn't be changed by this
> approach.
>

One approach is to allow references to old blocks so code snippets can be
pulled out of them. That avoids having to define the 'common sections' up
front. Charging for virtual vbytes unfortunately keeps smart functionality
very expensive and the point is to make it not so expensive.

> > For a payment to someone to come with a rider where they could accept it
> and think their system was working properly for a while until you exercised
> some kind of retroactive veto on new action or even clawback would
> obviously be unacceptable behavior.
>
> I definitely agree. A payment's covenant should be completely knowable to
> the recipient, and recipients shouldn't accept random covenants they
> haven't explicitly accepted on their own.
>
> > for payments to come with covenants but the recipient not even be able
> to parse them unless they're fully buying into that behavior is much more
> reasonable.
>
> The recipient not being able to parse them? Couldn't that result in
> exactly the situation above you said was not acceptable? The recipient must
> be able to know all the possibilities of the covenant or there might be
> some secret retroactive clawback in there waiting to bite them.
>

Not sure what you're saying. If the recipient can't parse a UTXO the
defined behavior should be that they assume it's bricked.