Date: Sat, 14 May 2022 07:43:47 +1000
From: Anthony Towns <aj@erisian.com.au>
To: Russell O'Connor <roconnor@blockstream.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20220513214347.GA2463@erisian.com.au>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAMZUoKmhOpt2N+6YxxREMzmRca2hNnPHBMRMsT09efkEs0CJiQ@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Subject: Re: [bitcoin-dev] Speedy covenants (OP_CAT2)
Precedence: list

On Thu, May 12, 2022 at 06:48:44AM -0400, Russell O'Connor via bitcoin-dev wrote:
> On Wed, May 11, 2022 at 11:07 PM ZmnSCPxj <ZmnSCPxj@protonmail.com> wrote:
> > So really: are recursive covenants good or...?
> My view is that recursive covenants are inevitable.  It is nearly
> impossible to have programmable money without it because it is so difficult
> to avoid.

I think my answer is that yes they are good: they enable much more
powerful contracting.

Of course, like any cryptographic tool they can also be harmful to you if
you misuse them, and so before you use them yourself you should put in the
time to understand them well enough that you *don't* misuse them. Same as
using a kitchen knife, or riding a bicycle, or swimming. Can be natural
to be scared at first, too.

> Given that we cannot have programmable money without recursive covenants
> and given all the considerations already discussed regarding them, i.e. no
> worse than being compelled to co-sign transactions, and that user generated
> addresses won't be encumbered by a covenant unless they specifically
> generate it to be, I do think it makes sense to embrace them.

I think that's really the easy way to be sure *you* aren't at risk
from covenants: just follow the usual "not your keys, not your coins"
philosophy.

The way you currently generate an address from a private key already
guarantees that *your* funds won't be encumbered by any covenants; all
you need to do is to keep doing that. And generating the full address
yourself is already necessary with taproot: if you don't understand
all the tapscript MAST paths, then even though you can spend the coin,
one of those paths you don't know about might already allow someone to
steal your funds. But if you generated the address, you (or at least your
software) will understand everything and not include anything dangerous,
so your funds really are safu.

It may be that some people will refuse to send money to your address
because they have some rule that says "I'll only send money to people who
encumber all their funds with covenant X" and you didn't encumber your
address in that way -- but that just means they're refusing to pay you,
just as people who say "I'll only pay you off-chain via coinbase" or
"I'll only pay you via SWIFT" won't send funds to your bitcoin address.

Other examples might include "we only support segwit-v0 addresses not
taproot ones", or "you're on an OFAC sanctions list so I can't send
to you or the government will put me in prison" or "my funds are in a
multisig with the government who won't pay to anyone who isn't also in
a multisig with them".

It does mean you still need people with the moral fortitude to say "no,
if you can't pay me properly, we can't do business" though.

Even better: in so far as wallet software will just ignore any funds
sent to addresses that they didn't generate themselves according to the
rules you selected, you can already kind of outsource that policy to
your wallet. And covenants, recursive or otherwise, don't change that.


For any specific opcode proposal, I think you still want to consider

 1) how much you can do with it
 2) how efficient it is to validate (and thus how cheap it is to use)
 3) how easy it is to make it do what you want
 4) how helpful it is at preventing bugs
 5) how clean and maintainable the validation code is

I guess to me CTV and APO are weakest at (1); CAT/CSFS falls down on
(3) and (4); OP_TX is probably weakest at (5) and maybe not as good as
we'd like at (3) and (4)?

Cheers,
aj