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 4E9B0995 for ; 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 ; Wed, 17 Aug 2016 00:18:11 +0000 (UTC) Received: by mail-wm0-f53.google.com with SMTP id f65so169703065wmi.0 for ; 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: References: <1736097121.90204.1471369988809@privateemail.com> <201608161937.20748.luke@dashjr.org> <20160816194332.GA5888@fedora-21-dvm> From: Gregory Maxwell Date: Wed, 17 Aug 2016 00:18:09 +0000 X-Google-Sender-Auth: kLN3q_lVTK0PnlILak2icR7jyH8 Message-ID: To: "Russell O'Connor" , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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.