diff options
| author | Billy Tetrud <billy.tetrud@gmail.com> | 2022-01-21 11:32:27 -0600 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2022-01-21 17:32:47 +0000 |
| commit | 03c5914e82d90711607ae32df43eb7937e8308e7 (patch) | |
| tree | 13e45fa3f64ea02f34f9b846abe8139e2411e49c | |
| parent | c88ee55eb6ed4cef131b33395dc13d351c872083 (diff) | |
| download | pi-bitcoindev-03c5914e82d90711607ae32df43eb7937e8308e7.tar.gz pi-bitcoindev-03c5914e82d90711607ae32df43eb7937e8308e7.zip | |
Re: [bitcoin-dev] Covenants and capabilities in the UTXO model
| -rw-r--r-- | f5/ac3a98e26e0c733be832500567164b0063742c | 231 |
1 files changed, 231 insertions, 0 deletions
diff --git a/f5/ac3a98e26e0c733be832500567164b0063742c b/f5/ac3a98e26e0c733be832500567164b0063742c new file mode 100644 index 000000000..eed9f29e2 --- /dev/null +++ b/f5/ac3a98e26e0c733be832500567164b0063742c @@ -0,0 +1,231 @@ +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>> Bitcoin doesn't have a strong single concept= + of a 'parent'</div><div><br></div><div>I'm using the term &quo= +t;parent" 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>>=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'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>> "you can only point back so= + far" 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'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'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'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 <<a href=3D"mailto:pete@petertodd.org">pete@pete= +rtodd.org</a>> 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> +> > Nodes currently aren't required to keep around the whole bloc= +kchain, but<br> +> > your proposal sounds like it would require them to. I think this = +could be<br> +> > pretty detrimental to future scalability. Monero, for example, ha= +s a<br> +> > situation where its UTXO set is the whole blockchain because you = +can't<br> +> > generally know what has been spent and what hasn't been. Allo= +wing<br> +> > references to old blocks would pull in all this old block data in= +to the<br> +> > UTXO set. So unless you're very careful about how or when you= + can reference<br> +> > old blocks, this could cause issues.<br> +> ><br> +> <br> +> Don't full nodes by definition have to have the whole chain? This = +does make<br> +> pruned nodes difficult, but it could also have rules like you can only= +<br> +> point back so far.<br> +<br> +"you can only point back so far" leads to transactions becoming i= +nvalid, which<br> +is something we'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'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> 'peter'[:-1]@<a href=3D"http://petertodd.org"= + rel=3D"noreferrer" target=3D"_blank">petertodd.org</a><br> +</blockquote></div> + +--000000000000af9c3605d61b012a-- + |