summaryrefslogtreecommitdiff
path: root/2b/7a050dc97d7f22694e0a3ef3ea3b78a56b7f9a
blob: fb7ecb8795bc2413461f49424256aee5307a770d (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
129
130
131
132
133
134
135
136
Return-Path: <sjors@sprovoost.nl>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 48D81D094
	for <bitcoin-dev@lists.linuxfoundation.org>;
	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 <bitcoin-dev@lists.linuxfoundation.org>;
	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: <xms:oL6CXPghRlkhTthnSYFzOn5oPkgq--QGqt5u-yExh1rudezUy2irkg>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedutddrgedtgdduvdegucetufdoteggodetrfdotf
	fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
	uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne
	cujfgurhephfgtgfgguffffhfvjgfkofesthhqmhdthhdtvdenucfhrhhomhepufhjohhr
	shcurfhrohhvohhoshhtuceoshhjohhrshesshhprhhovhhoohhsthdrnhhlqeenucfkph
	epkeegrddutdehrdeiuddrudehnecurfgrrhgrmhepmhgrihhlfhhrohhmpehsjhhorhhs
	sehsphhrohhvohhoshhtrdhnlhenucevlhhushhtvghrufhiiigvpedt
X-ME-Proxy: <xmx:oL6CXBakEwEj85se0wf9e9Own683x8DlIADANde3cPQiqXwZfPM9tg>
	<xmx:oL6CXLijNEZ-7CCxHPCsKw97k2pj8F_DTYmkPn9oi3ZlpCzXDA93tQ>
	<xmx:oL6CXBaXYdHQoMJ9Ol5IZRovnkwH1KD6Hbp5NnksFuVdovfQ6WqLqA>
	<xmx:ob6CXIIilbYVc-Z2ZVNm0rMW8Zo9peAOMZbu_dkzoAocPmlNfQGBfg>
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 <sjors@sprovoost.nl>
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: <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>
To: Matt Corallo <lf-lists@mattcorallo.com>,
	Russell O'Connor <roconnor@blockstream.io>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
In-Reply-To: <6bb308f5-f478-d5ec-064f-e4972709f29c@mattcorallo.com>
Message-Id: <D2014BB7-1EFC-4604-ACF6-3C5AC74B6FC0@sprovoost.nl>
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 <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: 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