Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id D8B50C002D for ; Mon, 25 Apr 2022 13:35:53 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id B543C404DD for ; Mon, 25 Apr 2022 13:35:53 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham 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 lFsYfUvWm9qM for ; Mon, 25 Apr 2022 13:35:53 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from mail-4027.protonmail.ch (mail-4027.protonmail.ch [185.70.40.27]) by smtp2.osuosl.org (Postfix) with ESMTPS id C81F84045C for ; Mon, 25 Apr 2022 13:35:52 +0000 (UTC) Date: Mon, 25 Apr 2022 13:35:48 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail2; t=1650893750; bh=/t8yBI6wCjCfLwD1APnBgaqsrD+RoiwvmVCvgf1ptzY=; h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To: References:Feedback-ID:From:To:Cc:Date:Subject:Reply-To: Feedback-ID:Message-ID; b=kYgpel7ccLzA1E6sHUbrq9tcepY977rqXmsWRhk47+5E8G3yYEgDCmPj+aVtDGTQ3 GtWhjFXM49WOCMoLW6bNTfXIQincke6Kjb+VU5Xukx9p/J5u/YpjmxVdndP8VIgkDj pi6Vo/ug5tb1Cdzg74ZuelpM8L1lBg6sUuUnpGZQIU1EED6rBg37SfI2g+WNZI3wO8 wyzVniMMi7bk04w0sv/nuyXlguqK6UWcyvcNCXhE94Qq5EPtSiHJnSU/VrkPlTQKD5 nfmzSCvcxYmPUeaxVBIOnoHgznvGiflfFt9VKGrVFxA8tDXRn0fj4cbP528TLakyWp 6xr9EkczOYQPg== To: Richard Myers From: darosior Reply-To: darosior Message-ID: In-Reply-To: References: 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: Mon, 25 Apr 2022 13:37:25 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [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: Mon, 25 Apr 2022 13:35:54 -0000 Hi Richard, > Sounds good to me. Although from an activation perspective it may not be = either/or, both proposals do compete for scarce reviewer time Yes, of course. Let's say i was more interested in knowing if people who op= pose CTV would oppose SIGHASH_ANYPREVOUT too. I think talking about activation of anything at thi= s point is premature. > For someone not as versed in CTV, why is it necessary that ANYONECANPAY b= e optional to emulate CTV? Is there a write-up that explains how APO-AS w/out ANYONECANPAY approximates CTV? I'm not aware of any specific to CTV. It's just that the fields covered in = the CTV hash are very close to what ANYPREVOUT_ANYSCRIPT's signature hash covers [0]. The two things that CTV c= ommits to that APO_AS does not are the number of inputs and the hash of the inputs' sequences [1]. Not committing to the number of inputs and other inputs' data is today's be= haviour of ANYONECANPAY that can be combined with other signature hash types [1]. Thus APO_AS makes ACP mand= atory, and to emulate CTV completely it should be optional. Antoine [0] https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki#Detailed= _Specification [1] https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki#signatur= e-message [2] https://github.com/bitcoin/bitcoin/blob/10a626a1d6776447525f50d3e1a97b3= c5bbad7d6/src/script/interpreter.cpp#L1327, https://github.com/bitcoin/bitc= oin/blob/10a626a1d6776447525f50d3e1a97b3c5bbad7d6/src/script/interpreter.cp= p#L1517-L1522 ------- Original Message ------- Le dimanche 24 avril 2022 =C3=A0 10:41 PM, Richard Myers a =C3=A9crit : > Hi darosior, > > Thanks for sharing your thoughts on this. > > > I would like to know people's sentiment about doing (a very slightly tw= eaked version of) BIP118 in place of > > (or before doing) BIP119. > > > Sounds good to me. Although from an activation perspective it may not be = either/or, both proposals do compete for scarce reviewer time so their orde= ring will necessarily be driven by reviewer's priorities. My priority is el= too which is why I focus on BIP-118. > > > SIGHASH_ANYPREVOUTANYSCRIPT, if its "ANYONECANPAY" behaviour is made op= tional [0], can emulate CTV just fine. > > > For someone not as versed in CTV, why is it necessary that ANYONECANPAY b= e optional to emulate CTV? Is there a write-up that explains how APO-AS w/o= ut ANYONECANPAY approximates CTV? > > In the case of eltoo commit txs, we use bring-your-own-fee (BYOF) to late= -bind fees; that means ANYONECANPAY will always be paired with APO-AS for e= ltoo. Settlement txs in eltoo use just APO and do not necessarily need to b= e paired with ANYONECANPAY. > > I would guess making ANYONECANPAY the default for APO-AS was a way to squ= eeze in one more sighash flag. Perhaps there's another way to do it? > > Including SIGHASH_GROUP with APO for eltoo is also tempting. Specifically= so the counter-party who commits a settlement tx can use for fees their se= ttled to_self balance. How to rejigger the sighash flags to accommodate bot= h APO and GROUP may be worth some discussion. > > The BIP-118 proposal will certainly benefit from having input from review= ers looking at other protocols than eltoo. > > -- Richard