MIME-Version: 1.0
References: <161946014-482cdec305e2bd7a2c3fc4774c70239d@pmq1v.m5r2.onet>
 <M80pb4TxcE1yCMCW4IboyTtx8MSvp8m9tphXe2EYvIvcrcf2Wzsn4ManJw8EP_ri-ohqtIOPrEaw7XkUcTO3lfVSLN4WMUwpromwzLm15Kc=@protonmail.com>
 <CAMZUoKnzjcYDM-mOhT00P7YO18YmjxRkYsfO6QFtYFn0mEtLQw@mail.gmail.com>
 <fkMEju1kNN5OJPoI1d2K99sV0bhr7qeAnhVbv-99K_UL48YQyHp-rbqEfQ81crx-thaA8JuUY4-eFlYUskvFC_8h6DIhdF0Wj-v-4DNnlcI=@protonmail.com>
 <CAMZUoKmhOpt2N+6YxxREMzmRca2hNnPHBMRMsT09efkEs0CJiQ@mail.gmail.com>
 <20220513214347.GA2463@erisian.com.au>
 <CAMZUoK=stZaPcTNfC_KdOxbQp=VyORwC3osSm3sTeQ0WZ4ejYQ@mail.gmail.com>
In-Reply-To: <CAMZUoK=stZaPcTNfC_KdOxbQp=VyORwC3osSm3sTeQ0WZ4ejYQ@mail.gmail.com>
From: Erik Aronesty <erik@q32.com>
Date: Sat, 14 May 2022 09:32:18 -0400
Message-ID: <CAJowKgKfy7-2UsBoypHmPkGnMb5V+m7Mt3ek5scsEHwj0YW9wA@mail.gmail.com>
To: "Russell O'Connor" <roconnor@blockstream.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="00000000000062277605def8d20e"
Subject: Re: [bitcoin-dev] Speedy covenants (OP_CAT2)
Precedence: list

--00000000000062277605def8d20e
Content-Type: text/plain; charset="UTF-8"

>
>
>
> FWIW, I think the rmain reasons to do CAT+CSFS is to validate oracle
> messages and pubkey delegation.  The ability to covenants would be
> secondary and would mostly serve to get us some real user data about what
> sort of covenants users find especially valuable.
>

I don't think this should be discounted.   I think it's worthwhile to
willingly include possibly less-than-awesome, but proven perfectly-safe
opcodes, knowing we will have to validate them forever, even if new, cooler
and more widely-used ones replace them years from now.

I honestly don't think the development of the latter will happen without
some version of the former.

Personally I am satisfied:

  - the safety of covenants, in general, is covered by how addresses are
generated
  - fears of forced forward-encumbrance are not any worse than can be
easily done today
  - ctv+apo, cat+csfs are fine, but we should pick ones that everyone
thinks are "good enough for everyone who cares about them"
  - they are not an undue burden on nodes in terms of
validate-cpu-cycles-per-byte (have we proven this?)
  - the complexity is low, code is easy to validate
  - won't introduce DDOS attack vectors (also needs to be proven i think?)
  - the game theory underpinning selfish miner support of the chain won't
be altered by causing a widespread use of on-chain leveraging instruments
(shorting bitcoin on-chain would be dangerous, for example)


>

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

<div dir=3D"ltr"><div class=3D"gmail_quote"><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 class=3D"gmail_quote"><div><br><br=
></div><div>FWIW, I think the rmain reasons to do CAT+CSFS is to validate o=
racle messages and pubkey delegation.=C2=A0 The ability to covenants would =
be secondary and would mostly serve to get us some real user data about wha=
t sort of covenants users find especially valuable.<br></div></div></div></=
blockquote><div><br></div><div>I don&#39;t think this should be discounted.=
=C2=A0 =C2=A0I think it&#39;s worthwhile to willingly include possibly less=
-than-awesome, but proven perfectly-safe opcodes, knowing we will have to v=
alidate them forever, even if new, cooler and more widely-used ones replace=
 them years from now.</div><div><div><br></div><div>I honestly don&#39;t th=
ink the development of the latter will happen without some version of the f=
ormer.=C2=A0</div></div><div><br></div><div>Personally I am satisfied:</div=
><div><br></div><div>=C2=A0 - the safety of covenants, in general, is cover=
ed by how addresses are generated</div><div>=C2=A0 - fears of forced forwar=
d-encumbrance are not any worse than can be easily done today=C2=A0</div><d=
iv>=C2=A0 - ctv+apo, cat+csfs are fine, but we should pick ones that everyo=
ne thinks are &quot;good enough for everyone who cares about them&quot;</di=
v><div>=C2=A0 - they are not an undue burden on nodes in terms of validate-=
cpu-cycles-per-byte (have we proven this?)</div><div>=C2=A0 - the complexit=
y is low, code is easy to validate</div><div>=C2=A0 - won&#39;t introduce=
=C2=A0DDOS attack vectors (also needs to be proven i think?)</div><div>=C2=
=A0 - the game theory underpinning selfish miner support of the chain won&#=
39;t be altered by causing a widespread use of on-chain leveraging instrume=
nts (shorting bitcoin on-chain would be dangerous, for example)=C2=A0</div>=
<div><br></div><div>=C2=A0</div><div><br></div><blockquote class=3D"gmail_q=
uote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,2=
04);padding-left:1ex"><br>
</blockquote></div></div>

--00000000000062277605def8d20e--