summaryrefslogtreecommitdiff
path: root/1b/b9e0bf85f0b4c7ba1b8f60cd1d2348f7733d85
blob: f81e4c53f3450e50eaaec354a3e35582088307ab (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
Return-Path: <gmaxwell@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 4E9B0995
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 17 Aug 2016 00:18:12 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm0-f53.google.com (mail-wm0-f53.google.com [74.125.82.53])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7FB201A9
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Wed, 17 Aug 2016 00:18:11 +0000 (UTC)
Received: by mail-wm0-f53.google.com with SMTP id f65so169703065wmi.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 16 Aug 2016 17:18:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:sender:in-reply-to:references:from:date:message-id
	:subject:to:cc;
	bh=QPffCTt/5MCQEDRmunJolfWQaS4J0pCoZeIvS2INknU=;
	b=UETudtZ6tOrNtkwzV0lP9FPLyKdTJJ5kBd8igCtKw+RSSrFo84rQT3ghyO1IHaxtuk
	IsPLs2Cz0YixXozvdQRprshd8GkpVs18FmnsjUrtynFvNyA3I3gNJqQYGso8EtQZtePH
	jbRWumaf3DAo5GVC0uf0268FDiHxRcSHTnZWKqlNyqqW0YqbCRu+zDMj18aanP1KDZpz
	AA5+F5+l7NUfkPZBHjtP77EcwwvYiRZ0uhigOG8z3fOSr9jAhhV6cTwI6uIo6R8v9iyA
	uj1arOgiR+/YSJDKge8vF0vOpmAWAAygMcvN8+zyjJXp8BTt8bnN9HqTxv0fEIuQ+2Q9
	ytlw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:sender:in-reply-to:references:from
	:date:message-id:subject:to:cc;
	bh=QPffCTt/5MCQEDRmunJolfWQaS4J0pCoZeIvS2INknU=;
	b=B3U420kANXmu8loYjuHmHuwOrV4EcfSaaec8c5lmsAMUYPXQvRVpjgGvr8TdYcdWH9
	NSD1gevp3xq6wWE2J2MWasEYlFWFXx8ZNG1GAimbgIfp1oB1TyO6yXVHRBn95TO3kHxp
	UoDRIvJBSgf6wHr8yNLP6RXMXVcJAvzXeyomy8iXmANXN5jqcH6fNVS4Zq22ITWKlmZT
	3y19mreisR5ISwaU3xORHjdnjQ2hlGOcMuLGeLl3dOX7khiMo/QENBxv34MR0QofPmKm
	X2IyAdT16W+HAFDXW5VsFYrzNqA6AOwWUga/KKY7uNni2l5lGBHP0/N5FFOw9zbJP/82
	wMjw==
X-Gm-Message-State: AEkoouu8LoUaKIjRwFpS01oLuCC9UH/of/T4WbPSI92v9AhoVVGK6Lxh7HhX+iZsC0ASU4yAmNEG6vok5UsM6g==
X-Received: by 10.194.221.134 with SMTP id qe6mr40851039wjc.165.1471393090183; 
	Tue, 16 Aug 2016 17:18:10 -0700 (PDT)
MIME-Version: 1.0
Sender: gmaxwell@gmail.com
Received: by 10.195.12.116 with HTTP; Tue, 16 Aug 2016 17:18:09 -0700 (PDT)
In-Reply-To: <CAMZUoKnebdULkJXqM38i-SkzoD6ufcxdEhcBD1PG5C78qyjFOw@mail.gmail.com>
References: <1736097121.90204.1471369988809@privateemail.com>
	<201608161937.20748.luke@dashjr.org>
	<20160816194332.GA5888@fedora-21-dvm>
	<CAMZUoKkAkGRFxpyGMxQMz76L7uW6fsQAYVxkrxi5MQCiBtNnqw@mail.gmail.com>
	<CAPg+sBi30SgHHXCyipbNpiMRHYWPCRYz6ejQYKrDg3MLJp39EQ@mail.gmail.com>
	<CAMZUoKktS=Ku4kpD0bocR4X__ZpWXrkPkdOyXBaYxjq+mr9Pmw@mail.gmail.com>
	<CAPg+sBhykn8BU1LAr1izH0z6nFuOv0PzWjuqq7YJX5r35LDa9Q@mail.gmail.com>
	<CAMZUoKnebdULkJXqM38i-SkzoD6ufcxdEhcBD1PG5C78qyjFOw@mail.gmail.com>
From: Gregory Maxwell <greg@xiph.org>
Date: Wed, 17 Aug 2016 00:18:09 +0000
X-Google-Sender-Auth: kLN3q_lVTK0PnlILak2icR7jyH8
Message-ID: <CAAS2fgQ66mQQ6Bdcm7C=CSzjkk3CwZCFLdSsDFdiDaRXhLiO=Q@mail.gmail.com>
To: "Russell O'Connor" <roconnor@blockstream.io>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset=UTF-8
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, FREEMAIL_FROM, 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
Subject: Re: [bitcoin-dev] New BIP: Dealing with OP_IF and OP_NOTIF
 malleability in P2WSH
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: Wed, 17 Aug 2016 00:18:12 -0000

On Tue, Aug 16, 2016 at 10:52 PM, Russell O'Connor via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> I see.
>
> But is it really necessary to soft fork over this issue?  Why not just make
> it a relay rule?  Miners are already incentivized to modify transactions to
> drop excess witness data and/or prioritize (versions of) transactions based
> on their cost.  If a miner wants to mine a block with excess witness data,
> it is mostly their own loss.

Relay rules are quite fragile-- people build programs or protocols not
expecting them to be violated, without proper error handling in those
cases... and then eventually some miner rips them out because they
simply don't care about them: not enforcing them won't make their
blocks invalid.

It's my general view that we should avoid blocking things with relay
rules unless we think that someday they could be made invalid... not
necessarily that they will, but that it's plausible. Then the
elimination at the relay level is just the first exploratory step in
that direction.

One should also consider adversarial behavior by miners.  For example,
I can mine blocks with mutated witnesses with a keyed mac that chooses
the mutation. The key is shared by conspirators or customers, and now
collectively we have a propagation advantage (since we know the
mutated version before it shows up).  Not the _biggest_ concern, since
parties doing this could just create their own new transactions to
selectively propagate; but doing that would require leaving behind fee
paying public transactions, while using malleability wouldn't.