MIME-Version: 1.0
References: <CAHUJnBBFsS597ZRdAtwONMAz1r7gQbrXULzdNtEVxOPENx+tDg@mail.gmail.com>
 <CAGpPWDYvvtCJLsr1SqghugfntnmnKw+GOtufp07d8sN-5vKa0w@mail.gmail.com>
 <CAHUJnBAfnmfs2nY3HFRhzNL6ztpZT3dgqe5wCxuO3qpk0OsgRg@mail.gmail.com>
 <CAGpPWDabAbY3nS-1QATrzLj+O4dxfs4Fo0EuYFftNdjw_gwRPw@mail.gmail.com>
 <CAHUJnBAFV6qFDjYkO_ByfDOp1rwz4S1xQc9hSJj5Jpsb7DdVwQ@mail.gmail.com>
 <YeoY12X1skxA8Lcy@petertodd.org>
In-Reply-To: <YeoY12X1skxA8Lcy@petertodd.org>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Fri, 21 Jan 2022 11:32:27 -0600
Message-ID: <CAGpPWDYOJFkOdzkoq6XMB0Z9SEEP4nmdmcZDEZckWQL+BzPOZw@mail.gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary="000000000000af9c3605d61b012a"
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 Bram Cohen <bram@chia.net>
Subject: Re: [bitcoin-dev] Covenants and capabilities in the UTXO model
Precedence: list

--000000000000af9c3605d61b012a
Content-Type: text/plain; charset="UTF-8"

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

--000000000000af9c3605d61b012a
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>&gt; Bitcoin doesn&#39;t have a strong single concept=
 of a &#39;parent&#39;</div><div><br></div><div>I&#39;m using the term &quo=
t;parent&quot; loosely in context=C2=A0here to mean a relationship where an=
 input has constraints applied to an output (or outputs).</div><div><br></d=
iv>&gt;=C2=A0=C2=A0

verify the secure hash chain from its parent to itself so that it knows wha=
t the parent looked like<br><div><br></div><div>I guess I just don&#39;t un=
derstand why you would want to do it this way. If you send to an address th=
at 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 crea=
ting such a child as invalid unless the child matches the covenant in the p=
arent.=C2=A0</div><div><br></div><div>&gt; &quot;you can only point back so=
 far&quot; leads to transactions becoming invalid, which is something we=
9;ve always strictly avoided because it can result in huge problems during =
reorgs</div><div><br></div><div>I&#39;m surprised to hear you say that. I h=
ave tried to learn why valid transactions that can become invalid is seen a=
s such a problem. I&#39;ve been unsuccessful in finding much information ab=
out this. I tried to document the full extent of my understanding in <a hre=
f=3D"https://github.com/fresheneesz/bip-efficient-bitcoin-vaults/blob/main/=
bbv/bip-beforeblockverify.md#reorg-safety">my proposal here</a>=C2=A0where =
I actually have a quote from you where you said you don&#39;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?</div></div><br><div clas=
s=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Jan 20, 202=
2 at 8:22 PM Peter Todd &lt;<a href=3D"mailto:pete@petertodd.org">pete@pete=
rtodd.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=
=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding=
-left:1ex">On Thu, Jan 20, 2022 at 11:23:30AM -0800, Bram Cohen via bitcoin=
-dev wrote:<br>
&gt; &gt; Nodes currently aren&#39;t required to keep around the whole bloc=
kchain, but<br>
&gt; &gt; your proposal sounds like it would require them to. I think this =
could be<br>
&gt; &gt; pretty detrimental to future scalability. Monero, for example, ha=
s a<br>
&gt; &gt; situation where its UTXO set is the whole blockchain because you =
can&#39;t<br>
&gt; &gt; generally know what has been spent and what hasn&#39;t been. Allo=
wing<br>
&gt; &gt; references to old blocks would pull in all this old block data in=
to the<br>
&gt; &gt; UTXO set. So unless you&#39;re very careful about how or when you=
 can reference<br>
&gt; &gt; old blocks, this could cause issues.<br>
&gt; &gt;<br>
&gt; <br>
&gt; Don&#39;t full nodes by definition have to have the whole chain? This =
does make<br>
&gt; pruned nodes difficult, but it could also have rules like you can only=
<br>
&gt; point back so far.<br>
<br>
&quot;you can only point back so far&quot; leads to transactions becoming i=
nvalid, which<br>
is something we&#39;ve always strictly avoided because it can result in hug=
e<br>
problems during reorgs with transactions being unable to be included in a n=
ew<br>
change. That&#39;s exactly why transaction expiry proposals have been shot =
down<br>
over and over again.<br>
<br>
-- <br>
<a href=3D"https://petertodd.org" rel=3D"noreferrer" target=3D"_blank">http=
s://petertodd.org</a> &#39;peter&#39;[:-1]@<a href=3D"http://petertodd.org"=
 rel=3D"noreferrer" target=3D"_blank">petertodd.org</a><br>
</blockquote></div>

--000000000000af9c3605d61b012a--