Return-Path: Received: from silver.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 78F41C004C for ; Tue, 4 Aug 2020 04:02:27 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by silver.osuosl.org (Postfix) with ESMTP id 6E4AB20491 for ; Tue, 4 Aug 2020 04:02:27 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org Received: from silver.osuosl.org ([127.0.0.1]) by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r6emHFjsmPgx for ; Tue, 4 Aug 2020 04:02:26 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail.as397444.net (mail.as397444.net [69.59.18.99]) by silver.osuosl.org (Postfix) with ESMTPS id 0253E20390 for ; Tue, 4 Aug 2020 04:02:25 +0000 (UTC) Received: by mail.as397444.net (Postfix) with ESMTPSA id 1D3742C1579; Tue, 4 Aug 2020 04:02:23 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable From: lf-lists@mattcorallo.com Mime-Version: 1.0 (1.0) Date: Tue, 4 Aug 2020 00:02:21 -0400 Message-Id: <4AFF2D6A-57BE-40CF-A15F-E972AEB9ACDE@mattcorallo.com> References: <20200709214048.27mycsi5h2bnv3cc@erisian.com.au> In-Reply-To: <20200709214048.27mycsi5h2bnv3cc@erisian.com.au> To: Anthony Towns , Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] BIP 118 and SIGHASH_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: Tue, 04 Aug 2020 04:02:27 -0000 While I admit I haven=E2=80=99t analyzed the feasibility, I want to throw on= e additional design consideration into the ring. Namely, it would ideally be trivial, at the p2p protocol layer, to relay a t= ransaction to a full node without knowing exactly which input transaction th= at full node has in its mempool/active chain. This is at least potentially i= mportant for systems like lighting where you do not know which counterparty c= ommitment transaction(s) are in a random node=E2=80=99s mempool and you shou= ld be able to describe to that node that you are spending then nonetheless. This is (obviously) an incredibly nontrivial problem both in p2p protocol co= mplexity and mempool optimization, but it may leave SIGHASH_NOINPUT rather u= seless for lighting without it. The least we could do is think about the consensus design in that context, e= ven if we have to provide an external overlay relay network in order to make= lighting transactions relay properly (presumably with miners running such s= oftware). Matt > On Jul 9, 2020, at 17:46, Anthony Towns via bitcoin-dev wrote: >=20 > =EF=BB=BFHello world, >=20 > After talking with Christina ages ago, we came to the conclusion that > it made more sense to update BIP 118 to the latest thinking than have > a new BIP number, so I've (finally) opened a (draft) PR to update BIP > 118 with the ANYPREVOUT bip I've passed around to a few people, >=20 > https://github.com/bitcoin/bips/pull/943 >=20 > Probably easiest to just read the new BIP text on github: >=20 > https://github.com/ajtowns/bips/blob/bip-anyprevout/bip-0118.mediawiki >=20 > It doesn't come with tested code at this point, but I figure better to > have the text available for discussion than nothing. >=20 > Some significant changes since previous discussion include complete lack > of chaperone signatures or anything like it (if you want them, you can > always add them yourself, of course), and that ANYPREVOUTANYSCRIPT no > longer commits to the value (details/rationale in the text). >=20 > Cheers, > aj >=20 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev