path: root/f8/cfbb41b772d091d66db1ff5bed96b3670f35eb

Return-Path: <bram@chia.net>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id AB8C5C002F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 22 Jan 2022 00:19:22 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id 92C7240143
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 22 Jan 2022 00:19:22 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level: 
X-Spam-Status: No, score=-2.099 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, 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: smtp2.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=chia.net
Received: from smtp2.osuosl.org ([127.0.0.1])
 by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id tRkZQ5ghsyi2
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 22 Jan 2022 00:19:21 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-lf1-x132.google.com (mail-lf1-x132.google.com
 [IPv6:2a00:1450:4864:20::132])
 by smtp2.osuosl.org (Postfix) with ESMTPS id E6535400D1
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 22 Jan 2022 00:19:20 +0000 (UTC)
Received: by mail-lf1-x132.google.com with SMTP id u6so5370464lfm.10
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 21 Jan 2022 16:19:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chia.net; s=google;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=vY3ePCFsY+BOU4LYVtgwAjI1MN3QauY3xxe26ul0MPI=;
 b=OBVFZSDiA8LPzAptmrUPFSzzTjFnvzswlBEi1RzlbItB1j41T6UPbK8Mj/ogWKUYm5
 InGhGWQ8VzvwOOfm4vnNopg5zSkotADTIw4ZniAsD6V6e7D4Do1I9tZeLe14mmOS42d5
 WWO+bh4VZEEuq9NvIhmqjcAv7HKPFt+66qLSij5y3gGEGzMe9s1j7cKa4VjCET1RNtCA
 oMFJdGnafUTsfftSECiFultN5vm0j0vpPi5lketmficwu7dwA6/w4V8crVUDWLWyTsqY
 8OoPYp4v+ItjOII1zU36Mav15815eIsfUTaiOy6Oynbfvc4bw9dOEinkx0rg9PdgcvsE
 MbAw==
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=vY3ePCFsY+BOU4LYVtgwAjI1MN3QauY3xxe26ul0MPI=;
 b=AfyUaMHARnlcML1fNxDXP0ymzZ+6oxgkHyNz+QCChw8VCNYWEjFCI8aCsMGw/NnQsW
 3q2VI9Weca7YC7kF8t4+CSm/7W+0RXCn5WwbvzuLpVuGpFxH7RireWzqiN6IXdqH/PAO
 kgB0A5CsWkmfmB1hMyrLie6sPs4qQmccfUVLQ2UrkQPUHH0/G/zefrvY5i3bRBYi/vd8
 hOYWhHEC0tmCKzp70pwfk8ghfHDX9OAYn1QUwd4E4KsAJDqOVpmLZfw2HRzr5J0yB4Ld
 P1MqVsywUNfREpRq3u061DioF+T9QcrBnV4EcLNMGVuMI5YIw1r8vt463gKI/UltEAxG
 Kicg==
X-Gm-Message-State: AOAM5322QNxT3sIeUEqLgES+OkQB4AZUGb0IkUZUaS2sA/QH1MRrgwbU
 7jc41+UlIh5/T45anZ9x95f7/JD5G3VsEQmGmFA68g==
X-Google-Smtp-Source: ABdhPJxtCUMy1OflibALPbx56friy1kKsz9DNEwwPMd6zURcM2IDtBHOmXOTPH5cKHVgMCabf7e6dhwzL1XNQDN/HrY=
X-Received: by 2002:a05:6512:22c6:: with SMTP id
 g6mr5127426lfu.1.1642810758867; 
 Fri, 21 Jan 2022 16:19:18 -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>
 <CAGpPWDYOJFkOdzkoq6XMB0Z9SEEP4nmdmcZDEZckWQL+BzPOZw@mail.gmail.com>
In-Reply-To: <CAGpPWDYOJFkOdzkoq6XMB0Z9SEEP4nmdmcZDEZckWQL+BzPOZw@mail.gmail.com>
From: Bram Cohen <bram@chia.net>
Date: Fri, 21 Jan 2022 16:19:07 -0800
Message-ID: <CAHUJnBCy4Jbm+oJjGknCVEGzTqSshjgtf86egVX9D5TPxGDs=w@mail.gmail.com>
To: Billy Tetrud <billy.tetrud@gmail.com>
Content-Type: multipart/alternative; boundary="000000000000b73e9805d620af9c"
X-Mailman-Approved-At: Sat, 22 Jan 2022 01:56:48 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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: Sat, 22 Jan 2022 00:19:22 -0000

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

On Fri, Jan 21, 2022 at 9:32 AM Billy Tetrud <billy.tetrud@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.

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

<div dir=3D"ltr"><div dir=3D"ltr">On Fri, Jan 21, 2022 at 9:32 AM Billy Tet=
rud &lt;<a href=3D"mailto:billy.tetrud@gmail.com">billy.tetrud@gmail.com</a=
>&gt; wrote:<br></div><div class=3D"gmail_quote"><blockquote class=3D"gmail=
_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204=
,204);padding-left:1ex"><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 &quot;parent&quot; loosely in context=C2=A0here to mean=
 a relationship where an input has constraints applied to an output (or out=
puts).</div></div></blockquote><div><br></div><div>Yes and I&#39;m using it=
 more specifically to mean a single parent because the tricks for implement=
ing capabilities I&#39;m talking about don&#39;t work if you don&#39;t have=
 a way of talking about &#39;my parent&#39; as an unambiguously defined sin=
gle UTXO.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"=
margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-lef=
t:1ex"><div dir=3D"ltr"><div><br></div>&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.</div></div></blockquote><div=
><br></div><div>The idea here is to optimize for adding as little to the UX=
TO model as possible and doing everything with Bitcoin script additions. So=
me optional mappings of inputs to outputs in a transaction seem to be neces=
sary but beyond that the current model can remain unchanged.</div><div>=C2=
=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir=3D"ltr"=
><div> If you send to an address that has such a reverse-looking script, yo=
u could brick funds that came from the wrong parent. With the reverse mecha=
nism, the transaction creating the child, you can prevent this from happeni=
ng by defining the transaction creating such a child as invalid unless the =
child matches the covenant in the parent.=C2=A0</div></div></blockquote><di=
v><br></div><div>If you want to pay to a singleton you don&#39;t do it by p=
aying to some scriptpubkey which represents that singleton, you pay to a sc=
riptpubkey which says &#39;I can be spent in any transaction which includes=
 singleton X&#39; and it does the validation of that other UTXO being the c=
urrent incarnation of the singleton using the capabilities validation trick=
s I mentioned before.</div><div>=C2=A0</div><blockquote class=3D"gmail_quot=
e" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204)=
;padding-left:1ex"><div dir=3D"ltr"><div><br></div><div>&gt; &quot;you can =
only point back so far&quot; leads to transactions becoming invalid, which =
is something we&#39;ve always strictly avoided because it can result in hug=
e problems during reorgs</div><div><br></div><div>I&#39;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&#39;ve been unsuccessful in finding m=
uch information about this. I tried to document the full extent of my under=
standing in <a href=3D"https://github.com/fresheneesz/bip-efficient-bitcoin=
-vaults/blob/main/bbv/bip-beforeblockverify.md#reorg-safety" target=3D"_bla=
nk">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></blockquote><div><br></div><div>It can be made so t=
hat if it goes past the time when the backpointer works then the transactio=
n is still valid but its vbytes goes up because the referenced string needs=
 to be repeated on the chain.</div><div><br></div><div>I too am a bit on th=
e fence about whether strict transaction monotinicity=C2=A0is absolutely ne=
cessary. The most plausible violation of it to add would be some kind of ma=
x height/age condition to go with the current min height/age restrictions. =
What scares me about that isn&#39;t so much the ability to replay reorgs ge=
tting messed up (those can be derailed by double spends anyway) but that ei=
ther an intentional DOS or just a spike in transaction fees could cause a d=
eadline to be passed and something to be bricked for completely technical r=
easons having nothing to do with its intended logic. The same type of funct=
ionality 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&#39;t=
 asleep at the wheel the transaction will switch to a new state which disal=
lows whatever it is that was supposed to be disallowed at that time.</div><=
div><br></div><div>Since there isn&#39;t any compelling bit of functionalit=
y which needs to violate monotinicity to be implemented I don&#39;t see any=
 need to call for an end to it as a principle. It certainly makes mempool l=
ogic a lot simpler and more reliable.</div><div><br></div></div></div>

--000000000000b73e9805d620af9c--