Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id D8F11C0011 for ; Thu, 24 Feb 2022 06:53:17 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id B9929401DF for ; Thu, 24 Feb 2022 06:53:17 +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 smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yEyyoxhA7ZyP for ; Thu, 24 Feb 2022 06:53:15 +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 smtp4.osuosl.org (Postfix) with ESMTPS id 96723401DD for ; Thu, 24 Feb 2022 06:53:15 +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 1nN7zy-0003UB-0W; Thu, 24 Feb 2022 16:53:12 +1000 Received: by sapphire.erisian.com.au (sSMTP sendmail emulation); Thu, 24 Feb 2022 16:53:05 +1000 Date: Thu, 24 Feb 2022 16:53:05 +1000 From: Anthony Towns To: ZmnSCPxj , Bitcoin Protocol Discussion Message-ID: <20220224065305.GB1965@erisian.com.au> References: <87leymuiu8.fsf@rustcorp.com.au> <0100017ee6472e02-037d355d-4c16-43b0-81d2-4a82b580ba99-000000@email.amazonses.com> 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: Thu, 24 Feb 2022 06:53:17 -0000 On Wed, Feb 23, 2022 at 11:28:36AM +0000, ZmnSCPxj via bitcoin-dev wrote: > Subject: Turing-Completeness, And Its Enablement Of Drivechains > And we have already rejected Drivechains, That seems overly strong to me. > for the following reason: > 1. Sidechain validators and mainchain miners have a strong incentive to > merge their businesses. > 2. Mainchain miners end up validating and commiting to sidechain blocks. > 3. Ergo, sidechains on Drivechains become a block size increase. I think there are two possible claims about drivechains that would make them unattractive, if true: 1) that adding a drivechain is a "block size increase" in the sense that every full node and every miner need to do more work when validating a block, in order to be sure whether the majority of hash rate will consider it valid, or will reject it and refuse to build on it because it's invalid because of some external drivechain rule 2) that funds deposited in drivechains will be stolen because the majority of hashrate is not enforcing drivechain rules (or that deposited funds cannot be withdrawn, but will instead be stuck in the drivechain, rather than having a legitimate two-way peg) And you could combine those claims, saying that one or the other will happen (depending on whether more or less than 50% of hashpower is enforcing drivechain rules), and either is bad, even though you don't know which will happen. I believe drivechain advocates argue a third outcome is possible where neither of those claims hold true, where only a minority of hashrates needs to validate the drivechain rules, but that is still sufficient to prevent drivechain funds from being stolen. One way to "reject" drivechains is simply to embrace the second claim -- that putting money into drivechains isn't safe, and that miners *should* claim coins that have been drivehcain encumbered (or that miners should not assist with withdrawing funds, leaving them trapped in the drivechain). In some sense this is already the case: bip300 rules aren't enforced, so funds committed today via bip300 can likely expect to be stolen, and likely won't receive the correct acks, so won't progress even if they aren't stolen. I think a key difference between tx-covenant based drivechains and bip300 drivechains is hashpower endorsement: if 50% of hashpower acks enforcement of a new drivechain (as required in bip300 for a new drivechain to exist at all), there's an implicit threat that any block proposing an incorrect withdrawal from that blockchain will have their block considered invalid and get reorged out -- either directly by that hashpower majority, or indirectly by users conducting a UASF forcing the hashpower majority to reject those blocks. I think removing that implicit threat changes the game theory substantially: rather than deposited funds being withdrawn due to the drivechain rules, you'd instead expect them to be withdrawn according to whoever's willing to offer the miners the most upfront fees to withdraw the funds. That seems to me to mean you'd frequently expect to end up in a scorched earth scenario, where someone attempts to steal, then they and the legitimate owner gets into a bidding war, with the result that most of the funds end up going to miners in fees. Because of the upfront payment vs delayed collection of withdrawn funds, maybe it could end up as a dollar auction, with the two parties competing to lose the least, but still both losing substantial amounts? So I think covenant-based drivechains would be roughly the same as bip300 drivechains, where a majority of hashpower used software implementing the following rules: - always endorse any proposed drivechain - always accept any payment into a drivechain - accept bids to ack/nack withdrawals, then ack/nack depending on whoever pays the most You could probably make covenant-based drivechains a closer match to bip300 drivechains if a script could determine if an input was from a (100-block prior) coinbase or not. > 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. 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 Cheers, aj