path: root/f5/ac3a98e26e0c733be832500567164b0063742c

Return-Path: <fresheneesz@gmail.com>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
 by lists.linuxfoundation.org (Postfix) with ESMTP id A2B5EC002F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 21 Jan 2022 17:32:47 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp3.osuosl.org (Postfix) with ESMTP id 8844560FAF
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 21 Jan 2022 17:32:47 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp3.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp3.osuosl.org ([127.0.0.1])
 by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id Nu8rJ3iKGOcG
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 21 Jan 2022 17:32:46 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ej1-x631.google.com (mail-ej1-x631.google.com
 [IPv6:2a00:1450:4864:20::631])
 by smtp3.osuosl.org (Postfix) with ESMTPS id 53F2C60FA3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 21 Jan 2022 17:32:46 +0000 (UTC)
Received: by mail-ej1-x631.google.com with SMTP id ka4so2011420ejc.11
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 21 Jan 2022 09:32:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=ddHqjEGokz3tJu99t2uVn84TbVqPUTQbJuQH9MDNSzE=;
 b=YV0jMhSgygUJPymwu93lxGOXGDIdJ9pKouI8u3ayhnF03k4qiBgZlXVGSKNbUEduLZ
 XZ4pLlcC3yWT0hdcTnNMT8Tlp/C5NZOuC05qYmM8ItrJjo9uca3CgXuRoNIUbBsFzniV
 QXKvaBjXKiIrTuizPbfU8gjXJAIx3SiO8EEN20mT2BzS0aL3r0X4ZXXcvPNOBTGDyEi9
 /LkR/8HVsOquqJ4cG4Wp0UCk+t4hJKy/CsaFNy4qINHvb1n1kGuJPVieBzG/hhRkv0Vj
 XuUpq7An9PS06SpcW0NfHUMyQVhAYRhuJNZqBmkiA659MGC1K5onHT2vp6R6sA7Oo4Sj
 lknQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=ddHqjEGokz3tJu99t2uVn84TbVqPUTQbJuQH9MDNSzE=;
 b=YQIbDLopocn3MwwIn/VSicSd6N3P+CtRZfapYiyrbQT2gl2Dln577PzkVisgJrYDX+
 jgDO9Zo+/oumRUMYODMcpURoTXfvrROHi04F19+lYBkQBD5/TTHUIk4ou7aLliSjWi7R
 N0AxBUa/W9Q2mDZj2qnxE8YNeAY8fGUURExR0PLfVW0MJWnCvxj/WxIHp9fhQDnZGYcD
 1SINUdmGGLKjygTUzcATaNbwYSRrt2/bsz28HEQ/I+Z8uU+5V6Vo79DC3WBDd1B0nDFI
 mXpYXVWLtAXbzIsgsYRGrPaiDWgGdzY84JUq8/6jft0NsfFjpD6wBFLMstQzQxjqMjZx
 g5Uw==
X-Gm-Message-State: AOAM530bIIiWD91EZusK+GjLqhY3cmrYZJQyJWMY1FElTb/6guNiwlVM
 EOh7DT0FnLvrnWIBVP3+Jd3li2uS7GEy1ZhPjhQCNIYrK0U=
X-Google-Smtp-Source: ABdhPJw2eNrBy/QqnMkJ+IXvXlVWndZFX8ojm64KKzP9dZp4qJTqVug1kbmiX506ySTx8Agf4fJalTxdMX0yQ8e7UkM=
X-Received: by 2002:a17:906:2bcf:: with SMTP id
 n15mr3907445ejg.184.1642786364298; 
 Fri, 21 Jan 2022 09:32:44 -0800 (PST)
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"
X-Mailman-Approved-At: Fri, 21 Jan 2022 17:52:57 +0000
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
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Fri, 21 Jan 2022 17:32:47 -0000

--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&#3=
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--