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