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 48D81D094 for ; Fri, 8 Mar 2019 19:12:34 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BE126180 for ; Fri, 8 Mar 2019 19:12:33 +0000 (UTC) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 119182222F; Fri, 8 Mar 2019 14:12:33 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute1.internal (MEProxy); Fri, 08 Mar 2019 14:12:33 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sprovoost.nl; h= from:content-type:content-transfer-encoding:mime-version:subject :date:references:to:in-reply-to:message-id; s=fm2; bh=Sdzjpdjitx mKbd9Te7IyhSBrqZBPKpnuuCFKJJAWzFg=; b=b83UecaFxMXzfDXn3Tm8i5h6Uy bOgT8PutkEH7rsnnc+jMDvVMTdioMjgKsWAprNWo8pPDO8cgJnRsUs0uQd5ojgnM BB/8+BqzN87yy5S9UdBQ0xYzIPptr74IuwetdRb36cDQFBkcF1GkqTwyuhM/Rgcy CdqWZTk+AymkTgI2YbYiS67fC1z7T1HlzSg1xGHoSuPjKS3YZS+48iAmupH5kSux hKg0AAH49WE2ghfJQPNGya89TzIhniESdSqYnEUUfjgpCOBRCxHhdGkaR8Hzi0Le 9ws3rSdhRO8LV72D4KnonQa8ORMLH6Kxp42oj3wB1yUsv7ssKGsgClwWhILg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=SdzjpdjitxmKbd9Te7IyhSBrqZBPKpnuuCFKJJAWz Fg=; b=GQ4XqmfInoMq/Ad2QoZQ0tLOBexlGw1y2TTbJqacM1ri+3+8hKeI715aU IsjfvZEHCRu6tirimHgqmbsQlX6akurMMVjh/tnMsKqSJv7bx5KbNoYB8wCM4FQM cS5uzQFrWI2lQUOkWqDyAMSN4OpBWUmllqySRlmTZAgsVGRwBwkcgkPUkl/3kVSO V+4zQ/i7AEtmmebzwrvl3ZpA0ahu22KtNuaOIcj4mkCB5sTqXt2kKcSJjibdVAV4 bGZyKwLpEUQbxxGQRP+c3U2MW31B01v5vShLkaV+3zadZAe7GZlN0Ciq6uCCuqmI UNY+uc1MB66AaZqc9NAPLV8CQI8SA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrgedtgdduvdegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephfgtgfgguffffhfvjgfkofesthhqmhdthhdtvdenucfhrhhomhepufhjohhr shcurfhrohhvohhoshhtuceoshhjohhrshesshhprhhovhhoohhsthdrnhhlqeenucfkph epkeegrddutdehrdeiuddrudehnecurfgrrhgrmhepmhgrihhlfhhrohhmpehsjhhorhhs sehsphhrohhvohhoshhtrdhnlhenucevlhhushhtvghrufhiiigvpedt X-ME-Proxy: Received: from [192.168.178.185] (54693d0f.cm-12-2a.dynamic.ziggo.nl [84.105.61.15]) by mail.messagingengine.com (Postfix) with ESMTPA id 660A2E4383; Fri, 8 Mar 2019 14:12:31 -0500 (EST) From: Sjors Provoost Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Fri, 8 Mar 2019 20:12:29 +0100 References: <6bb308f5-f478-d5ec-064f-e4972709f29c@mattcorallo.com> To: Matt Corallo , Russell O'Connor , Bitcoin Protocol Discussion In-Reply-To: <6bb308f5-f478-d5ec-064f-e4972709f29c@mattcorallo.com> Message-Id: X-Mailer: Apple Mail (2.3445.102.3) X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, RCVD_IN_DNSWL_LOW 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: Fri, 08 Mar 2019 19:53:47 +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: Fri, 08 Mar 2019 19:12:34 -0000 > (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. >=20 >> 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. >=20 > 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. Although I'm not a fan of extra complicity, just to explore these two = ideas a bit further. What if such a transaction: 1. must have one input; and 2. must be smaller than 400 vbytes; and 3. must spend from a UTXO older than fork activation Adding such a contextual check seems rather painful, perhaps comparable = to nLockTime. Anything more specific than the above, e.g. counting the = number of OP_CODESEPARATOR calls, seems like guess work. Transaction weight currently doesn't consider OP codes, it only = considers if bytes are part of the witness. Changing that to something = more akin to Ethereums gas pricing sounds too complicated to even = consider. I would also like to believe that whoever went through the trouble of = using OP_CODESEPARATOR reads this list. Sjors