diff options
| author | Bram Cohen <bram@chia.net> | 2022-01-21 16:19:07 -0800 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2022-01-22 00:19:22 +0000 |
| commit | f9258768d699f1981e0e3d0ef424a4b75e09ea10 (patch) | |
| tree | 3c1b0fcbf4467c9323a80bb6cac3c70cd5abfa40 | |
| parent | 928a0038561b8a34c0f5bf4679f1a4647654345d (diff) | |
| download | pi-bitcoindev-f9258768d699f1981e0e3d0ef424a4b75e09ea10.tar.gz pi-bitcoindev-f9258768d699f1981e0e3d0ef424a4b75e09ea10.zip | |
Re: [bitcoin-dev] Covenants and capabilities in the UTXO model
| -rw-r--r-- | f8/cfbb41b772d091d66db1ff5bed96b3670f35eb | 249 |
1 files changed, 249 insertions, 0 deletions
diff --git a/f8/cfbb41b772d091d66db1ff5bed96b3670f35eb b/f8/cfbb41b772d091d66db1ff5bed96b3670f35eb new file mode 100644 index 000000000..d5bb17290 --- /dev/null +++ b/f8/cfbb41b772d091d66db1ff5bed96b3670f35eb @@ -0,0 +1,249 @@ +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 <<a href=3D"mailto:billy.tetrud@gmail.com">billy.tetrud@gmail.com</a= +>> 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>> Bitcoin doesn't have= + a strong single concept of a 'parent'</div><div><br></div><div>I&#= +39;m using the term "parent" 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'm using it= + more specifically to mean a single parent because the tricks for implement= +ing capabilities I'm talking about don't work if you don't have= + a way of talking about 'my parent' 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>>=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.</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't do it by p= +aying to some scriptpubkey which represents that singleton, you pay to a sc= +riptpubkey which says 'I can be spent in any transaction which includes= + singleton X' 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>> "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 hug= +e problems during reorgs</div><div><br></div><div>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 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'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'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'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't any compelling bit of functionalit= +y 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 l= +ogic a lot simpler and more reliable.</div><div><br></div></div></div> + +--000000000000b73e9805d620af9c-- + |