Bram Cohen [ARCHIVE] on Nostr: 📅 Original date posted:2022-01-21 📝 Original message:On Fri, Jan 21, 2022 at ...
📅 Original date posted:2022-01-21
📝 Original message:On Fri, Jan 21, 2022 at 9:32 AM Billy Tetrud <billy.tetrud at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220121/84c724d7/attachment.html>;
📝 Original message:On Fri, Jan 21, 2022 at 9:32 AM Billy Tetrud <billy.tetrud at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220121/84c724d7/attachment.html>;