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

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

[Bram Cohen]

[-- Attachment #1: Type: text/plain, Size: 3382 bytes --]

There are a few different approaches to adding covenants and capabilities
to the UTXO model with varying tradeoffs. It turns out that it can be done
while making very few but not quite zero compromises to practices Bitcoin
has been following so far.

First, the good news: Full support for both capabilities and covenants can
be added without changing the UTXO model whatsoever by adding some more
programmatic capabilities to the language and doing some programmatic
tricks. Since scriptpubkeys/scriptsigs continue to run ephemerally at
validation time full turing completeness is much less dangerous than people
fear. The main thing missing from what's expressed in transactions
themselves is a coherent notion of a single parent of each output instead
of the all-inputs-lead-to-all-outputs approach of transactions currently.
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.

Now for the controversial stuff. 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. Currently
Bitcoin has a strong policy that deciding which transactions to let into a
block for maximum fee is a strictly linear optimization problem and while
it's possible to keep things mostly that way making it completely strict is
unlikely to workable. About as close as you can get is to make it so that
each block can reference code snippets in previous blocks for
deduplication, so at least the optimization is linear for each block by
itself.

Having covenants and capabilities at all is controversial in and of itself.
With covenants the main issue is whether they're opt-in or opt-out. 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. But 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 main issue which people have raised with capabilities is that if you
were to have colored coins whose value was substantially greater than the
chain they were tokenized on then that could potentially create a business
model for attacking the underlying chain. While this is a real concern
tokenized assets have been out for a while now and have never come close to
causing this to happen, so maybe people aren't so worried about it now.

Given all the above caveats it turns out one weird trick is all you need to
support general purpose capabilities: for a UTXO to have a capability its
scriptpubkey asserts that its parent must either be the originator of that
capability or also conform to the same parent-asserting format. More
complex functionality such as supporting on-chain verifiable colored coins
can also be done but it follows the same pattern: Capabilities are
implemented as backwards pointing covenants.

If you'd like to see a fleshed out implementation of these ideas (albeit in
a slightly different model) there's quite a bit of stuff on chialisp.com

[-- Attachment #2: Type: text/html, Size: 3637 bytes --]

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

[Billy Tetrud]

[-- Attachment #1: Type: text/plain, Size: 8112 bytes --]

>  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.

> The main thing missing from what's expressed in transactions themselves
is a coherent notion of a single parent of each output instead of the
all-inputs-lead-to-all-outputs approach of transactions currently.

I'm curious to hear more about specifically what you mean by this. I think
there are covenant proposals that do that. TLUV has the concept of
specifying which output should have a script that's "modified" in a
particular way. CTV basically specifies a specific output set. My own
OP_CONSTRAINDESTINATION
<https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/cd/bip-constraindestination.md>
also specifies what outputs the value of the input is transferred to. Is
this what you mean?

> 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?

> 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.

We could also imagine a more dynamic approach, where nodes keep an index of
scripts or script snippets in some way, and keep around ones that it sees
most often. I'm not sure how this would work, since a script can contain a
lot of unique values and there's no clear way to split a script into
pieces. Perhaps script segments could be committed to the chain and nodes
could attempt to only store and reuse these paid-for segments, maybe only
the X most paid-for scripts (the scripts committed with the largest fee,
potentially across multiple explicit standalone commitments). However, this
dynamic approach would also have some scalability benefits, tho it would be
a bit more chaotic. Any node transmitting transactions would only need to
send the script segments when the node they're transmitting to requests
them. However, the extra script references also take up space, and so if
the ratio of how often the node has a script segment to how often they
don't is bad enough, this could a net negative scalability wise.

> 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.



On Fri, Dec 31, 2021 at 6:41 PM Bram Cohen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> There are a few different approaches to adding covenants and capabilities
> to the UTXO model with varying tradeoffs. It turns out that it can be done
> while making very few but not quite zero compromises to practices Bitcoin
> has been following so far.
>
> First, the good news: Full support for both capabilities and covenants can
> be added without changing the UTXO model whatsoever by adding some more
> programmatic capabilities to the language and doing some programmatic
> tricks. Since scriptpubkeys/scriptsigs continue to run ephemerally at
> validation time full turing completeness is much less dangerous than people
> fear. The main thing missing from what's expressed in transactions
> themselves is a coherent notion of a single parent of each output instead
> of the all-inputs-lead-to-all-outputs approach of transactions currently.
> 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.
>
> Now for the controversial stuff. 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. Currently
> Bitcoin has a strong policy that deciding which transactions to let into a
> block for maximum fee is a strictly linear optimization problem and while
> it's possible to keep things mostly that way making it completely strict is
> unlikely to workable. About as close as you can get is to make it so that
> each block can reference code snippets in previous blocks for
> deduplication, so at least the optimization is linear for each block by
> itself.
>
> Having covenants and capabilities at all is controversial in and of
> itself. With covenants the main issue is whether they're opt-in or opt-out.
> 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. But 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 main issue which people have raised with capabilities is that if you
> were to have colored coins whose value was substantially greater than the
> chain they were tokenized on then that could potentially create a business
> model for attacking the underlying chain. While this is a real concern
> tokenized assets have been out for a while now and have never come close to
> causing this to happen, so maybe people aren't so worried about it now.
>
> Given all the above caveats it turns out one weird trick is all you need
> to support general purpose capabilities: for a UTXO to have a capability
> its scriptpubkey asserts that its parent must either be the originator of
> that capability or also conform to the same parent-asserting format. More
> complex functionality such as supporting on-chain verifiable colored coins
> can also be done but it follows the same pattern: Capabilities are
> implemented as backwards pointing covenants.
>
> If you'd like to see a fleshed out implementation of these ideas (albeit
> in a slightly different model) there's quite a bit of stuff on
> chialisp.com
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 9216 bytes --]

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

[Bram Cohen]

[-- Attachment #1: Type: text/plain, Size: 4013 bytes --]

On Tue, Jan 18, 2022 at 7:10 AM Billy Tetrud <billy.tetrud@gmail.com> 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.

[-- Attachment #2: Type: text/html, Size: 5160 bytes --]

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

[Billy Tetrud]

[-- Attachment #1: Type: text/plain, Size: 5739 bytes --]

> '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

I'm not sure I fully follow. I usually think about covenants as having the
reverse form, that a parent would assert "my children must have a script of
the form XYZ". Are you saying you want to be able to specify that a UTXO
can only be spent if the resulting outputs of that transaction all share
the same script? I see this page
<https://chialisp.com/docs/puzzles/singletons/> but i don't understand how
those concepts relate to covenants.

>  allow references to old blocks so code snippets can be pulled out of them

Nodes currently aren't required to keep around the whole blockchain, but
your proposal sounds like it would require them to. I think this could be
pretty detrimental to future scalability. Monero, for example, has a
situation where its UTXO set is the whole blockchain because you can't
generally know what has been spent and what hasn't been. Allowing
references to old blocks would pull in all this old block data into the
UTXO set. So unless you're very careful about how or when you can reference
old blocks, this could cause issues.

> If the recipient can't parse a UTXO the defined behavior should be that
they assume it's bricked.

I must have misunderstood you. I think that's the appropriate response: if
you don't know everything about how a UTXO sent "to you" can be spent, you
can't really treat it as yours.


On Tue, Jan 18, 2022 at 11:16 AM Bram Cohen <bram@chia.net> wrote:

> On Tue, Jan 18, 2022 at 7:10 AM Billy Tetrud <billy.tetrud@gmail.com>
> 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.
>

[-- Attachment #2: Type: text/html, Size: 7263 bytes --]

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

[Bram Cohen]

[-- Attachment #1: Type: text/plain, Size: 2366 bytes --]

On Tue, Jan 18, 2022 at 6:25 PM Billy Tetrud <billy.tetrud@gmail.com> wrote:

> > '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
>
> I'm not sure I fully follow. I usually think about covenants as having the
> reverse form, that a parent would assert "my children must have a script of
> the form XYZ". Are you saying you want to be able to specify that a UTXO
> can only be spent if the resulting outputs of that transaction all share
> the same script? I see this page
> <https://chialisp.com/docs/puzzles/singletons/> but i don't understand
> how those concepts relate to covenants.
>

Two concepts here. First of all Bitcoin doesn't have a strong single
concept of a 'parent', it just has transactions where all the parents lead
to all the children. For this sort of trickery to work more information
needs to be added to specify which of the inputs is the parent of each of
the outputs.

Second what in practice happens is that a coin can check what its own id
is, then verify the secure hash chain from its parent to itself so that it
knows what the parent looked like. For a Singleton it can then rely on the
fact that its ancestors enforced that they each only had one child to know
that it's the only descendant. In some sense this is like covenants which
point backwards in time although that information is already there in
principle because of the secure hash chain but hard to parse.


>
> >  allow references to old blocks so code snippets can be pulled out of
> them
>
> Nodes currently aren't required to keep around the whole blockchain, but
> your proposal sounds like it would require them to. I think this could be
> pretty detrimental to future scalability. Monero, for example, has a
> situation where its UTXO set is the whole blockchain because you can't
> generally know what has been spent and what hasn't been. Allowing
> references to old blocks would pull in all this old block data into the
> UTXO set. So unless you're very careful about how or when you can reference
> old blocks, this could cause issues.
>

Don't full nodes by definition have to have the whole chain? This does make
pruned nodes difficult, but it could also have rules like you can only
point back so far.

[-- Attachment #2: Type: text/html, Size: 3332 bytes --]

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

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 1230 bytes --]

On Thu, Jan 20, 2022 at 11:23:30AM -0800, Bram Cohen via bitcoin-dev wrote:
> > Nodes currently aren't required to keep around the whole blockchain, but
> > your proposal sounds like it would require them to. I think this could be
> > pretty detrimental to future scalability. Monero, for example, has a
> > situation where its UTXO set is the whole blockchain because you can't
> > generally know what has been spent and what hasn't been. Allowing
> > references to old blocks would pull in all this old block data into the
> > UTXO set. So unless you're very careful about how or when you can reference
> > old blocks, this could cause issues.
> >
> 
> Don't full nodes by definition have to have the whole chain? This does make
> pruned nodes difficult, but it could also have rules like you can only
> point back so far.

"you can only point back so far" leads to transactions becoming invalid, which
is something we've always strictly avoided because it can result in huge
problems during reorgs with transactions being unable to be included in a new
change. That's exactly why transaction expiry proposals have been shot down
over and over again.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

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

[Billy Tetrud]

[-- Attachment #1: Type: text/plain, Size: 2817 bytes --]

> Bitcoin doesn't have a strong single concept of a 'parent'

I'm using the term "parent" loosely in context here to mean a relationship
where an input has constraints applied to an output (or outputs).

>   verify the secure hash chain from its parent to itself so that it knows
what the parent looked like

I guess I just don't understand why you would want to do it this way. If
you send to an address that has such a reverse-looking script, you could
brick funds that came from the wrong parent. With the reverse mechanism,
the transaction creating the child, you can prevent this from happening by
defining the transaction creating such a child as invalid unless the child
matches the covenant in the parent.

> "you can only point back so far" leads to transactions becoming invalid,
which is something we've always strictly avoided because it can result in
huge problems during reorgs

I'm surprised to hear you say that. I have tried to learn why valid
transactions that can become invalid is seen as such a problem. I've been
unsuccessful in finding much information about this. I tried to document
the full extent of my understanding in my proposal here
<https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/bbv/bip-beforeblockverify.md#reorg-safety>
where
I actually have a quote from you where you said you don't think this is a
valid concern. Did something change your mind? Or did I misinterpret you?
What am I missing from that section I linked to?

On Thu, Jan 20, 2022 at 8:22 PM Peter Todd <pete@petertodd.org> wrote:

> On Thu, Jan 20, 2022 at 11:23:30AM -0800, Bram Cohen via bitcoin-dev wrote:
> > > Nodes currently aren't required to keep around the whole blockchain,
> but
> > > your proposal sounds like it would require them to. I think this could
> be
> > > pretty detrimental to future scalability. Monero, for example, has a
> > > situation where its UTXO set is the whole blockchain because you can't
> > > generally know what has been spent and what hasn't been. Allowing
> > > references to old blocks would pull in all this old block data into the
> > > UTXO set. So unless you're very careful about how or when you can
> reference
> > > old blocks, this could cause issues.
> > >
> >
> > Don't full nodes by definition have to have the whole chain? This does
> make
> > pruned nodes difficult, but it could also have rules like you can only
> > point back so far.
>
> "you can only point back so far" leads to transactions becoming invalid,
> which
> is something we've always strictly avoided because it can result in huge
> problems during reorgs with transactions being unable to be included in a
> new
> change. That's exactly why transaction expiry proposals have been shot down
> over and over again.
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>

[-- Attachment #2: Type: text/html, Size: 3613 bytes --]

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

[Bram Cohen]

[-- Attachment #1: Type: text/plain, Size: 3837 bytes --]

On Fri, Jan 21, 2022 at 9:32 AM Billy Tetrud <billy.tetrud@gmail.com> wrote:

> > Bitcoin doesn't have a strong single concept of a 'parent'
>
> I'm using the term "parent" loosely in context here to mean a relationship
> where an input has constraints applied to an output (or outputs).
>

Yes and I'm using it more specifically to mean a single parent because the
tricks for implementing capabilities I'm talking about don't work if you
don't have a way of talking about 'my parent' as an unambiguously defined
single UTXO.


>
> >   verify the secure hash chain from its parent to itself so that it
> knows what the parent looked like
>
> I guess I just don't understand why you would want to do it this way.
>

The idea here is to optimize for adding as little to the UXTO model as
possible and doing everything with Bitcoin script additions. Some optional
mappings of inputs to outputs in a transaction seem to be necessary but
beyond that the current model can remain unchanged.


> If you send to an address that has such a reverse-looking script, you
> could brick funds that came from the wrong parent. With the reverse
> mechanism, the transaction creating the child, you can prevent this from
> happening by defining the transaction creating such a child as invalid
> unless the child matches the covenant in the parent.
>

If you want to pay to a singleton you don't do it by paying to some
scriptpubkey which represents that singleton, you pay to a scriptpubkey
which says 'I can be spent in any transaction which includes singleton X'
and it does the validation of that other UTXO being the current incarnation
of the singleton using the capabilities validation tricks I mentioned
before.


>
> > "you can only point back so far" leads to transactions becoming invalid,
> which is something we've always strictly avoided because it can result in
> huge problems during reorgs
>
> I'm surprised to hear you say that. I have tried to learn why valid
> transactions that can become invalid is seen as such a problem. I've been
> unsuccessful in finding much information about this. I tried to document
> the full extent of my understanding in my proposal here
> <https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/bbv/bip-beforeblockverify.md#reorg-safety> where
> I actually have a quote from you where you said you don't think this is a
> valid concern. Did something change your mind? Or did I misinterpret you?
> What am I missing from that section I linked to?
>

It can be made so that if it goes past the time when the backpointer works
then the transaction is still valid but its vbytes goes up because the
referenced string needs to be repeated on the chain.

I too am a bit on the fence about whether strict transaction
monotinicity is absolutely necessary. The most plausible violation of it to
add would be some kind of max height/age condition to go with the current
min height/age restrictions. What scares me about that isn't so much the
ability to replay reorgs getting messed up (those can be derailed by double
spends anyway) but that either an intentional DOS or just a spike in
transaction fees could cause a deadline to be passed and something to be
bricked for completely technical reasons having nothing to do with its
intended logic. The same type of functionality can be hacked by having an
allowed spend whose only condition is a min height/age so that if the time
has passed as long as someone isn't asleep at the wheel the transaction
will switch to a new state which disallows whatever it is that was supposed
to be disallowed at that time.

Since there isn't any compelling bit of functionality which needs to
violate monotinicity to be implemented I don't see any need to call for an
end to it as a principle. It certainly makes mempool logic a lot simpler
and more reliable.

[-- Attachment #2: Type: text/html, Size: 5008 bytes --]