From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 00CB7C002D for ; Fri, 22 Apr 2022 11:11:51 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id D2FBE40CD6 for ; Fri, 22 Apr 2022 11:11:50 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -0.126 X-Spam-Level: X-Spam-Status: No, score=-0.126 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, PDS_OTHER_BAD_TLD=1.975, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: smtp2.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=protonmail.com 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 x9nW4EncvNzn for ; Fri, 22 Apr 2022 11:11:49 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from mail-4324.protonmail.ch (mail-4324.protonmail.ch [185.70.43.24]) by smtp2.osuosl.org (Postfix) with ESMTPS id 92FF740CE1 for ; Fri, 22 Apr 2022 11:11:49 +0000 (UTC) Date: Fri, 22 Apr 2022 11:11:41 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1650625906; bh=YRUkFYFvG6Q1ORJNlM7C2XYgVfW8l36jWvXOZGWm3pY=; h=Date:To:From:Reply-To:Subject:Message-ID:Feedback-ID:From:To:Cc: Date:Subject:Reply-To:Feedback-ID:Message-ID; b=Lf4svTUoY37YCIUD+tOF11pMhOdqqhCm8R/RPYjHljD86p/au7EgpnvTVYkU1llq8 BMIv9yGCH+Iet3izcmEmL/dB/6dJ3BRJmAmSI3cqscgZ0Jc3qAWXlzVgkR4SAcZNPd OW40EcAcY0BcdevogVP4iDXxt/sf6BbfzHmLWYXSDanuS2/xAwOR4rHMLeYwcBhOng Pkzab9LbqPmh+mYkbpNCSQ14Kk6HQ0sxzW9C2//2ZDuKLoRV+/jEBJoxwJ7NvPyhT+ ttcxDcL3+RDjJCg1gzjiUX9nMO46lpH71SJawxA/moEm5Iqmb95ofS5SgUnGDf+/tW dP6xNP0hEG0wQ== To: Bitcoin Protocol Discussion From: darosior Reply-To: darosior Message-ID: Feedback-ID: 7060259:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Fri, 22 Apr 2022 11:23:06 +0000 Subject: [bitcoin-dev] ANYPREVOUT in place of CTV 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: Fri, 22 Apr 2022 11:11:51 -0000 I would like to know people's sentiment about doing (a very slightly tweake= d version of) BIP118 in place of (or before doing) BIP119. SIGHASH_ANYPREVOUT and its precedent iterations have been discussed for ove= r 6 years. It presents proven and implemented usecases, that are demanded and (please someone correct me if i= 'm wrong) more widely accepted than CTV's. SIGHASH_ANYPREVOUTANYSCRIPT, if its "ANYONECANPAY" behaviour is made option= al [0], can emulate CTV just fine. Sure then you can't have bare or Segwit v0 CTV, and it's a bit more expensi= ve to use. But we can consider CTV an optimization of APO-AS covenants. CTV advocates have been presenting vaults as the flagship usecase. Although= as someone who've been trying to implement practical vaults for the past 2 years i doubt CTV is necessary no= r sufficient for this (but still useful!), using APO-AS covers it. And it's not a couple dozen more virtual = bytes that are going to matter for a potential vault user. If after some time all of us who are currently dubious about CTV's stated u= secases are proven wrong by onchain usage of a less efficient construction to achieve the same goal, we could r= oll-out CTV as an optimization. In the meantime others will have been able to deploy new applications leveragi= ng ANYPREVOUT (Eltoo, blind statechains, etc..[1]). Given the interest in, and demand for, both simple covenants and better off= chain protocols it seems to me that BIP118 is a soft fork candidate that could benefit more (if not most of) Bi= tcoin users. Actually i'd also be interested in knowing if people would oppose the APO-A= S part of BIP118, since it enables CTV's features, for the same reason they'd oppose BIP119. [0] That is, to not commit to the other inputs of the transaction (via `sha= _sequences` and maybe also `sha_amounts`). Cf https://github.com/bitcoin/bips/blob/master/bip-0118.med= iawiki#signature-message. [1] https://anyprevout.xyz/ "Use Cases" section