From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id A2B5EC002F for ; 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 ; 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 ; 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 ; Fri, 21 Jan 2022 17:32:46 +0000 (UTC) Received: by mail-ej1-x631.google.com with SMTP id ka4so2011420ejc.11 for ; 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: In-Reply-To: From: Billy Tetrud Date: Fri, 21 Jan 2022 11:32:27 -0600 Message-ID: To: Peter Todd Content-Type: multipart/alternative; boundary="000000000000af9c3605d61b012a" X-Mailman-Approved-At: Fri, 21 Jan 2022 17:52:57 +0000 Cc: Bitcoin Protocol Discussion , Bram Cohen 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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 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
> Bitcoin doesn't have a strong single concept= of a 'parent'

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

>=C2=A0=C2=A0 verify the secure hash chain from its parent to itself so that it knows wha= t the parent looked like

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

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

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 my proposal here=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?

On Thu, Jan 20, 202= 2 at 8:22 PM Peter Todd <pete@pete= rtodd.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 bloc= kchain, but
> > your proposal sounds like it would require them to. I think this = could be
> > pretty detrimental to future scalability. Monero, for example, ha= s 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. Allo= wing
> > references to old blocks would pull in all this old block data in= to 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 i= nvalid, which
is something we've always strictly avoided because it can result in hug= e
problems during reorgs with transactions being unable to be included in a n= ew
change. That's exactly why transaction expiry proposals have been shot = down
over and over again.

--
http= s://petertodd.org 'peter'[:-1]@petertodd.org
--000000000000af9c3605d61b012a--