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 82C45DDD for ; Mon, 11 Mar 2019 19:15:51 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-it1-f176.google.com (mail-it1-f176.google.com [209.85.166.176]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2105482B for ; Mon, 11 Mar 2019 19:15:50 +0000 (UTC) Received: by mail-it1-f176.google.com with SMTP id w18so450876itj.4 for ; Mon, 11 Mar 2019 12:15:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=blockstream.io; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=X6si/bcQKzT1jl1go4ufdqzYwuvkq69GNuFYPDMRbRI=; b=Ai6H/Ipv585dDl8mUAu9FQi8C0f+ZWOHjdrFQUQaLaS/dkLF8AT0zJNyRfF+FLwMVA v9Y7mubnljmr9YpLefjWLvrZyPjeqwb7ATwH3AyE7deGBGQ1uzaNaSHcksXYp/HCanRY 1cDpNfYL4sQFlTXj013QYwG+Jw1GF7dOSV2C4= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=X6si/bcQKzT1jl1go4ufdqzYwuvkq69GNuFYPDMRbRI=; b=L5Zm3KPBhGECc+9DUrf3jxBkMwEGPIyGwmtrybKTI+FTEHCeKVmIk+nXZMlaRcWC/4 rniJEzu9zgPDuuLiOkoETNTJA353WlClZ+WOqDPKEBd2QfAHdpDc0jUlu/7FgQc060v/ DMGAze2Te7ERuK1wJuiSsG3Jemwjz2xMZ7iGl/KG/RX2LlVsXqFSpjUgtPFx9+5NyE4p r+Rz0E3Kri/kBEvSpUEM8xIE2MRlXijh/2SRGHDwlgYnGC/sfUZSEiaXYFwu6Gfnh9sX oSETfXJz7hBvbCkW5dMB4ygmxF1x+Jzy0C0pbLxAz6BG9ahHackrLYcNu5Qo5lYuk9U6 PRDg== X-Gm-Message-State: APjAAAV07CLtkrr3Nw8Pbj0CMY4yJqEzvh3u3Qw6T4mo7PTw1vwZXu0J oA0joWl5+OlQsPAujbI7P+qyHsNp6AJ13xuZ7i+78w== X-Google-Smtp-Source: APXvYqxRHr/iT7LLlUumWn2qOdQA+oJdfwWZVltqWD3voIKgMatYxcsVAx5xqMzKIXP6APjzpFkkeOFxmNEMWIpfLjw= X-Received: by 2002:a24:3a8b:: with SMTP id m133mr223174itm.26.1552331750279; Mon, 11 Mar 2019 12:15:50 -0700 (PDT) MIME-Version: 1.0 References: <6bb308f5-f478-d5ec-064f-e4972709f29c@mattcorallo.com> In-Reply-To: From: "Russell O'Connor" Date: Mon, 11 Mar 2019 15:15:38 -0400 Message-ID: To: Dustin Dettmer , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="0000000000008ca8d30583d66624" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, HTML_MESSAGE, RCVD_IN_DNSWL_NONE 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: Mon, 11 Mar 2019 21:15:24 +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: Mon, 11 Mar 2019 19:15:51 -0000 --0000000000008ca8d30583d66624 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Increasing the OP_CODESEPARATOR weight by 520 (p2sh redeemScript size limit) + 40 (stripped txinput size) + 8 (stripped txoutput size) + a few more (overhead for varints) =3D 572ish bytes should be enough to completely eliminate any vulnerability caused by OP_CODESEPARATOR within P2SH transactions without the need to remove it ever. I think it is worth attempting to be a bit more clever than such a blunt rule, but it would be much better than eliminating OP_CODESEPARATOR within P2SH entirely. Remember that the goal isn't to eliminate OP_CODESEPARATOR per se; the goal is to eliminate the vulnerability associated with it. On Mon, Mar 11, 2019 at 12:47 PM Dustin Dettmer via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > What about putting it in a deprecated state for some time. Adjust the > transaction weight so using the op code is more expensive (10x, 20x?) and > get the word out that it will be removed in the future. > > You could even have nodes send a reject code with the message > =E2=80=9COP_CODESEPARATOR is depcrecated.=E2=80=9D > --0000000000008ca8d30583d66624 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Increasing the OP_CODESEPARATOR weig= ht by 520 (p2sh redeemScript size limit) + 40 (stripped txinput size) + 8 (= stripped txoutput size) + a few more (overhead for varints) =3D 572ish byte= s should be enough to completely eliminate any vulnerability caused by OP_C= ODESEPARATOR within P2SH transactions without the need to remove it ever.= =C2=A0 I think it is worth attempting to be a bit more clever than such a b= lunt rule, but it would be much better than eliminating OP_CODESEPARATOR wi= thin P2SH entirely.

Remember that the goal isn'= ;t to eliminate OP_CODESEPARATOR per se; the goal is to eliminate the vulne= rability associated with it.

=
On Mon, Mar 11, 2019 at 12:47 PM Dust= in Dettmer via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
=
Wh= at about putting it in a deprecated state for some time. Adjust the transac= tion weight so using the op code is more expensive (10x, 20x?) and get the = word out that it will be removed in the future.

You could even have nodes send a reject code = with the message =E2=80=9COP_CODESEPARATOR is depcrecated.=E2=80=9D
--0000000000008ca8d30583d66624--