From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 30337C7CB for ; Thu, 7 Mar 2019 19:50:55 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail.bluematt.me (mail.bluematt.me [192.241.179.72]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id B8D463F7 for ; Thu, 7 Mar 2019 19:50:54 +0000 (UTC) Received: from [10.233.42.100] (gw.vpn.bluematt.me [144.217.106.88]) by mail.bluematt.me (Postfix) with ESMTPSA id 6924F184F43; Thu, 7 Mar 2019 19:50:53 +0000 (UTC) To: Russell O'Connor , Bitcoin Protocol Discussion References: From: Matt Corallo Message-ID: <6bb308f5-f478-d5ec-064f-e4972709f29c@mattcorallo.com> Date: Thu, 7 Mar 2019 19:50:52 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Thu, 07 Mar 2019 23:48:02 +0000 Subject: Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Mar 2019 19:50:55 -0000 Replies inline. Matt On 3/7/19 3:03 PM, Russell O'Connor wrote: > > * OP_CODESEPARATOR in non-BIP 143 scripts fails the script validation. > This includes OP_CODESEPARATORs in unexecuted branches of if > statements, > similar to other disabled opcodes, but unlike OP_RETURN. > > > OP_CODESEPARATOR is the only mechanism available that allows users to > sign which particular branch they are authorizing for within scripts > that have multiple possible conditions that reuse the same public key. This is true, and yet it does not appear to actually be practically usable. Thus far, despite a ton of effort, I have not yet seen a practical use-case for OP_CODESEPARATOR (except for one example of it being used to make SegWit scripts ever-so-slightly more effecient in TumbleBit, hence why this BIP does not propose disabling it for SegWit). > Because of P2SH you cannot know that no one is currently using this > feature.  Activating a soft-fork as describe above means these sorts of > funds would be permanently lost.  It is not acceptable to risk people's > money like this. (1) It has been well documented again and again that there is desire to remove OP_CODESEPARATOR, (2) it is well-documented OP_CODESEPARATOR in non-segwit scripts represents a rather significant vulnerability in Bitcoin today, and (3) lots of effort has gone into attempting to find practical use-cases for OP_CODESEPARATOR's specific construction, with no successes as of yet. I strongly, strongly disagree that the highly-unlikely remote possibility that someone created something before which could be rendered unspendable is sufficient reason to not fix a vulnerability in Bitcoin today. > I suggest an alternative whereby the execution of OP_CODESEPARATOR > increases the transactions weight suitably as to temper the > vulnerability caused by it.  Alternatively there could be some sort of > limit (maybe 1) on the maximum number of OP_CODESEPARATORs allowed to be > executed per script, but that would require an argument as to why > exceeding that limit isn't reasonable. You could equally argue, however, that any such limit could render some moderately-large transaction unspendable, so I'm somewhat skeptical of this argument. Note that OP_CODESEPARATOR is non-standard, so getting them mined is rather difficult in any case.