path: root/dc/a795a99da55c88418626fb09d68b8c1298930d

Return-Path: <aj@erisian.com.au>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id CFC6BC001A
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 26 Feb 2022 06:00:49 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp2.osuosl.org (Postfix) with ESMTP id AEE34403AE
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 26 Feb 2022 06:00:49 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.621
X-Spam-Level: 
X-Spam-Status: No, score=-1.621 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.276, SPF_HELO_NONE=0.001,
 SPF_NONE=0.001, UNPARSEABLE_RELAY=0.001]
 autolearn=no autolearn_force=no
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 pDU55hkXYcTa
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 26 Feb 2022 06:00:48 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from azure.erisian.com.au (cerulean.erisian.com.au [139.162.42.226])
 by smtp2.osuosl.org (Postfix) with ESMTPS id 2DF11400FF
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Sat, 26 Feb 2022 06:00:48 +0000 (UTC)
Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au)
 by azure.erisian.com.au with esmtpsa (Exim 4.92 #3 (Debian))
 id 1nNq8J-0001oU-Bu; Sat, 26 Feb 2022 16:00:45 +1000
Received: by sapphire.erisian.com.au (sSMTP sendmail emulation);
 Sat, 26 Feb 2022 16:00:40 +1000
Date: Sat, 26 Feb 2022 16:00:40 +1000
From: Anthony Towns <aj@erisian.com.au>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>,
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20220226060040.GA2139@erisian.com.au>
References: <CAMZUoK=pkZuovtifBzdqhoyegzG+9hRTFEc7fG9nZPDK4KbU3w@mail.gmail.com>
 <87leymuiu8.fsf@rustcorp.com.au>
 <CAD5xwhgP2_51Dvar0f1tsMrCXZ61W9-HnLgR45D-54Oc7-X1ag@mail.gmail.com>
 <0100017ee6472e02-037d355d-4c16-43b0-81d2-4a82b580ba99-000000@email.amazonses.com>
 <i710HUIxNHIqCNhkh07dzlShyDp9ZkoEokw9ZBezCFvsk05ZUy5fXK1xx_IQifLh4f3RYb8FJM_MFm7hAaQFaUM3Jy3E8QhfSzkaogAu1Gs=@protonmail.com>
 <20220224065305.GB1965@erisian.com.au>
 <bQvm5sSOMGRKR2udDFTNCJlOv_2vuIjkkBsoYqi4463y8ZjFDY4kxVvJEz7yv0GfxbyrMo-eOhOnEnd6sKPrWSk6PXn8KNerRlWsiGsWZRU=@protonmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <bQvm5sSOMGRKR2udDFTNCJlOv_2vuIjkkBsoYqi4463y8ZjFDY4kxVvJEz7yv0GfxbyrMo-eOhOnEnd6sKPrWSk6PXn8KNerRlWsiGsWZRU=@protonmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
X-Spam-Score-int: -18
X-Spam-Bar: -
Subject: Re: [bitcoin-dev] Recursive covenant opposition,
 or the absence thereof,
 was Re: TXHASH + CHECKSIGFROMSTACKVERIFY in lieu of CTV and ANYPREVOUT
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, 26 Feb 2022 06:00:49 -0000

On Thu, Feb 24, 2022 at 12:03:32PM +0000, ZmnSCPxj via bitcoin-dev wrote:
> > > Logically, if the construct is general enough to form Drivechains, and
> > > we rejected Drivechains, we should also reject the general construct.
> > Not providing X because it can only be used for E, may generalise to not
> > providing Y which can also only be used for E, but it doesn't necessarily
> > generalise to not providing Z which can be used for both G and E.
> Does this not work only if the original objection to merging in BIP-300 was of the form:
> * X implements E.
> * Z implements G and E.
> * Therefore, we should not merge in X and instead should merge in the more general construct Z.

I'd describe the "original objection" more as "E is not worth doing;
X achieves nothing but E; therefore we should not work on or merge X".

Whether we should work on or eventually merge some other construct that
does other things than E, depends on the (relative) merits of those
other things.

> I think we really need someone who NACKed BIP-300 to speak up.

Here's some posts from 2017:

] I think it's great that people want to experiment with things like
] drivechains/sidechains and what not, but their security model is very
] distinct from Bitcoin's and, given the current highly centralized
] mining ecosystem, arguably not very good.  So positioning them as a
] major solution for the Bitcoin project is the wrong way to go. Instead
] we should support people trying cool stuff, at their own risk.

 - https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-July/014726.html

] Regardless, people are free experiment and adopt such an approach. The
] nice thing about it not being a hardfork is that it does not require
] network-wide consensus to deploy. However, I don't think they offer a
] security model that should be encouraged, and thus doesn't have a
] place on a roadmap.

 - https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-July/014729.html

> If my understanding is correct and that the original objection was "Drivechains are bad for reasons R[0], R[1]...", then:
> * You can have either of these two positions:
>   * R[0], R[1] ... are specious arguments and Drivechains are not bad [...]
>   * R[0], R[1] ... are valid arguments are Drivechains are bad, therefore we should **NOT** merge in a feature that implements Recursive Covenants [...]
> You cannot have it both ways.

I guess you mean to say that I've got to pick one, rather than can't
pick both. But in any event, I don't pick either; my view is more along
the lines of:

 * drivechains shouldn't be used
 * it's okay if other people think drivechains are worth using, and go
   ahead and do so, if they're not creating a direct burden on everyone
   else

That's the same position I hold for other things, like using lightning
on mainnet in January 2018; or giving your bitcoin to an anonymous
custodian so it it can be borrowed via a flash loan on some novel third
party smart contract platform.

> Admittedly, there may be some set of restrictions that prevent Turing-Completeness from implementing Drivechains, but you have to demonstrate a proof of that set of restrictions existing.

Like I said; I don't think the drivechains game theory works without
the implicit threat of miner censorship, and therefore you need a
"from_coinbase" flag as well as covenants. That's not a big objection,
though. (On the other hand, if I'm wrong and drivechains *do* work
without that threat; then drivechains don't cause a block size increase,
and can be safely ignored by miners and full node operators, and the
arguments against drivechains are specious; and implementing them purely
via covenants so miners aren't put in a privileged position seems an
improvement)

> > I think it's pretty reasonable to say:
> >
> > a) adding dedicated consensus features for drivechains is a bad idea
> > in the absence of widespread consensus that drivechains are likely
> > to work as designed and be a benefit to bitcoin overall
> >
> > b) if you want to risk your own funds by leaving your coins on an
> > exchange or using lightning or eltoo or tumbling/coinjoin or payment
> > pools or drivechains or being #reckless in some other way, and aren't
> > asking for consensus changes, that's your business
> 
> *Shrug* I do not really see the distinction here --- in a world with Drivechains, you are free to not put your coins in a Drivechain-backed sidechain, too.

Well, yes: I'm saying there's no distinction between putting funds in
drivechains and other #reckless things you might do with your money?

My opinion is (a) we should be conservative about adding new consensus
features because of the maintenance cost; (b) we should design
consensus/policy in a way to encourage minimising the externality costs
users impose on each other; and (c) we should make it as easy as possible
to use bitcoin safely in general -- but if people *want* to be reckless,
even knowing the consequences, that's fine.

> (Admittedly, Drivechains does get into a Mutually Assured Destruction argument, so that may not hold.
> But if Drivechains going into a MAD argument is an objection, then I do not see why covenant-based Drivechains would also not get into the same MAD argument --- and if you want to avoid the MADness, you cannot support recursive covenants, either.

I think the argument you believe, but aren't quite actually making,
is along the lines of:

 a) drivechain technology doen't just potentially harm people who use
    them; it is an existential threat to bitcoin if used by anyone

 b) therefore the ability for anyone to implement them must be prevented

 c) (a) is well known and widely agreed upon by all reasonable
    well-informed people

(b) is definitely a reasonable consequence of (a), but I don't agree
with (a).  Drivechains have certainly been criticised as a bad idea,
but there are plenty of bad ideas that don't need to be outlawed.

But I think the simplest *method* of preventing drivechains from having
significant adoption is just "users encourage miners to steal funds
deposited into drivechains" (eg, by declining to do a UASF to prevent
such theft), which then obviously discourages people from putting funds
into drivechains. Since that can still be done even if bip300 or an
implementation of drivechains-via-covenants is deployed, I don't think
drivechains are an existential threat to bitcoin.

> Remember, 51% attackers can always censor the blockchain, regardless of whether you put the Drivechain commitments into the coinbase, or in an ostensibly-paid-by-somebody-else transaction.)

I think you could make the analogy between drivechains and covenants a
fair bit stronger in the following way:

The idea behind drivechains and the liquid sidechain is, in both cases,
that funds can be moved to some other blockchain with its own rules, and
then moved back to the bitcoin blockchain, via the assistance of some
group that will hopefully follow the stated rules of the sidechain. In
liquid's case it's a group of semi-known functionaries who are also
directly responsible for transactions appearing on the liquid sidechain,
and it's done by them signing via multisig. For bip300, it's bitcoin
miners, and done by putting entries in the coinbase.

But because just letting any miner alone immediately move funds
would be obviously too risky to consider, bip300 adds additional
restrictions, adding both multisig-like aspects, delays, and the ability
to back-out/correct a theft attempt before it's final, which provides
the opportunity for honest participants to react to miners attempting to
cheat and hopefully achieve a legitimate outcome instead. Whether that's
enough is still debatable -- but it's certainly an improvement to go from
"too risky to consider" to "debatable".

But the same incentive can apply to liquid too: it might be good to be
able to have liquid funds encumbered on the bitcoin blockchain in such a
way that it's even harder for people with liquid's private keys to cheat
than it currently is -- ie, it would be good to be able to specify more
"vault-like" behaviours for the liquid funds, perhaps in relation to the
"backup recovery keys" [0], eg.

As a result, while it's not obvious, I think it shouldn't be *surprising*
that the same technology that allows "vaults" also enables (something
like) drivechains -- since the goal in both cases is just constraining
how withdrawals work.

Cheers,
aj

[0] https://medium.com/blockstream/patching-the-liquid-timelock-issue-b4b2f5f9a973