summaryrefslogtreecommitdiff
path: root/ef/a724d911fcb598579372bbece30aac393d1048
blob: 439aff232b2bd1bb0ddebfcdbd5fe1ec1ab1dc50 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
Return-Path: <roconnor@blockstream.io>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 82C45DDD
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 11 Mar 2019 19:15:50 +0000 (UTC)
Received: by mail-it1-f176.google.com with SMTP id w18so450876itj.4
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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: <bf96c2fb-2e2e-a47f-e59f-87e56d83eca3@mattcorallo.com>
	<CAMZUoK=1kgZLR1YZ+cJgzwmEOwrABYFs=2Ri=xGX=BCr+w=VQw@mail.gmail.com>
	<6bb308f5-f478-d5ec-064f-e4972709f29c@mattcorallo.com>
	<D2014BB7-1EFC-4604-ACF6-3C5AC74B6FC0@sprovoost.nl>
	<D631175F-0704-4820-BE3C-110E63F9E3FF@mattcorallo.com>
	<PS2P216MB0179EEBB4E8EBF86EB25EACD9D4F0@PS2P216MB0179.KORP216.PROD.OUTLOOK.COM>
	<CABLeJxS1sK8x-dgkOJ5f4=vjB4xja6EVeca-aHbeqOyS7SwWWQ@mail.gmail.com>
In-Reply-To: <CABLeJxS1sK8x-dgkOJ5f4=vjB4xja6EVeca-aHbeqOyS7SwWWQ@mail.gmail.com>
From: "Russell O'Connor" <roconnor@blockstream.io>
Date: Mon, 11 Mar 2019 15:15:38 -0400
Message-ID: <CAMZUoKkJY6UpN=OmOsR0tDAwLw++dYrZtuo_Vir-+DHrK3ckNg@mail.gmail.com>
To: Dustin Dettmer <dustinpaystaxes@gmail.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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

<div dir=3D"ltr"><div dir=3D"ltr"><div>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.</div><div><br></div><div>Remember that the goal isn&#39=
;t to eliminate OP_CODESEPARATOR per se; the goal is to eliminate the vulne=
rability associated with it.<br></div></div><br><div class=3D"gmail_quote">=
<div dir=3D"ltr" class=3D"gmail_attr">On Mon, Mar 11, 2019 at 12:47 PM Dust=
in Dettmer via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfou=
ndation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-=
left:1px solid rgb(204,204,204);padding-left:1ex"><div><div dir=3D"auto">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.</div></div><div dir=3D"auto=
"><br></div><div dir=3D"auto">You could even have nodes send a reject code =
with the message =E2=80=9COP_CODESEPARATOR is depcrecated.=E2=80=9D</div>
</blockquote></div></div>

--0000000000008ca8d30583d66624--