MIME-Version: 1.0
References: <CAMhCMoH9uZPeAE_2tWH6rf0RndqV+ypjbNzazpFwFnLUpPsZ7g@mail.gmail.com>
In-Reply-To: <CAMhCMoH9uZPeAE_2tWH6rf0RndqV+ypjbNzazpFwFnLUpPsZ7g@mail.gmail.com>
From: Bram Cohen <bram@chia.net>
Date: Tue, 8 Nov 2022 15:34:32 -0800
Message-ID: <CAHUJnBA7PUy3ajygdvvBwg6EyhUXGA-KKL_bkXLKCRPS98kRqw@mail.gmail.com>
To: Salvatore Ingala <salvatore.ingala@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="0000000000000cd12a05ecfdfcfb"
Subject: Re: [bitcoin-dev] Merkleize All The Things
Precedence: list

--0000000000000cd12a05ecfdfcfb
Content-Type: text/plain; charset="UTF-8"

On Tue, Nov 8, 2022 at 2:13 AM Salvatore Ingala via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> I have been working on some notes to describe an approach that uses
> covenants in order to enable general smart contracts in bitcoin. You can
> find them here:
>
>     https://merkle.fun/
> <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>
>

Hash chained covenants in general all have about the same plateau of
functionality, which seems roughly reasonable to add to Bitcoin as it is
today but suffer from being limited and hence likely only a stepping stone
to greater functionality and unless whatever's put in now cleanly extends
to supporting more in the future it's likely to turn into a legacy
appendage which has to be supported. So my generic suggestion for this sort
of thing is that it should be proposed along with a plan for how it could
be extended to support full-blown covenants in the future.

Another probably unhelpful bit of feedback I have is that Bitcoin should
probably be taking verkle trees seriously because those can have
substantially lower size/cost/weight than merkle trees. That doesn't just
apply to this proposal, but to Bitcoin in general, which doesn't seem to
have any serious verkle tree proposals to date.

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

<div dir=3D"ltr"><div dir=3D"ltr"><br></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Tue, Nov 8, 2022 at 2:13 AM Salvat=
ore Ingala via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfou=
ndation.org">bitcoin-dev@lists.linuxfoundation.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"><div dir=3D"ltr"><br>I ha=
ve been working on some notes to describe an approach that uses covenants i=
n order to enable general smart contracts in bitcoin. You can find them her=
e:<div><br></div><div>=C2=A0 =C2=A0 <a href=3D"https://merkle.fun" target=
=3D"_blank">https://merkle.fun</a><a href=3D"https://lists.linuxfoundation.=
org/mailman/listinfo/bitcoin-dev" rel=3D"noreferrer" target=3D"_blank">/</a=
></div></div></blockquote><div><br></div><div>Hash chained covenants in gen=
eral all have about=C2=A0the same plateau of functionality, which seems rou=
ghly reasonable to add to Bitcoin as it is today but suffer from being limi=
ted and hence likely only a stepping stone to greater functionality and unl=
ess whatever&#39;s put in now cleanly extends to supporting more in the fut=
ure it&#39;s likely to turn into a legacy appendage which has to be support=
ed. So my generic suggestion for this sort of thing is that it should be pr=
oposed along with a plan for how it could be extended to support full-blown=
 covenants in the future.</div><div><br></div><div>Another probably unhelpf=
ul bit of feedback I have is that Bitcoin should probably be taking verkle =
trees seriously because those can have substantially lower size/cost/weight=
 than merkle trees. That doesn&#39;t just apply to this proposal, but to Bi=
tcoin in general, which doesn&#39;t seem to have any serious verkle tree pr=
oposals to date.</div></div></div>

--0000000000000cd12a05ecfdfcfb--