From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id CFC6BC001A for ; 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 ; 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 ; 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 ; 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 To: ZmnSCPxj , Bitcoin Protocol Discussion Message-ID: <20220226060040.GA2139@erisian.com.au> References: <87leymuiu8.fsf@rustcorp.com.au> <0100017ee6472e02-037d355d-4c16-43b0-81d2-4a82b580ba99-000000@email.amazonses.com> <20220224065305.GB1965@erisian.com.au> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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