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 BD5199E7 for ; Wed, 17 Aug 2016 00:28:19 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ua0-f175.google.com (mail-ua0-f175.google.com [209.85.217.175]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 8E04787 for ; Wed, 17 Aug 2016 00:28:15 +0000 (UTC) Received: by mail-ua0-f175.google.com with SMTP id 97so148784316uav.3 for ; Tue, 16 Aug 2016 17:28:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=blockstream-io.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=9U7NqfmgiqpBuyH6+S2B0L3dQOunskx3+cr2z+xIaFE=; b=PzV+rZmIzU/l+TI6vFZDoo/zpGlxLsmxgbEsRu28piH8wqq7HwA1iG+Kp+0uj9u5ZF 49OkKLH2ZP1w+LMQmxjUwXbA5EQ4Gn4CSK+yavsBZnzeSmVhAdulQBdDb6tYA1vYi3QM lHHKEowODzX2WArQl9kRCcG1GCOtWhq+KPxKfYkXWO4mGZ8ZZ+IEMnFTc0WpOwVXxjfz MP2eQJAvd/wcTyMKdY4olrpWFif4MaZzvOz4WBdrZmhSqEOYnHb/RkIvqNMk8sIjU1FX TqDd/OG3RnoOzN+b3SYfumYFDWv/WwqRZFw0fB+yLfRkxlp0vlGsGJWkpw85vsrul1aP CsAg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=9U7NqfmgiqpBuyH6+S2B0L3dQOunskx3+cr2z+xIaFE=; b=m47jLUvAzuxoyzp0rHvM7jSe7ZLWIxArR+bjmGzF+ShCqoWt144CleiQo09IxhhQhm DKv2xWYNrIN5yeTLRuBD7idLgVZaI3LK7ZGiVoTWoDgUTr0m801PgqmMZyRUT3FCpILL Xy7v0G3cXnJqcc1p5GogeN8onpmrJePW0Z+VhWCzkb5+WWiUt8K+rOkcpy1M0DsgFknD Qvzo8uXw/S7zQWVFG/lJHw0Sk5/IolIlxX04tUWKiz21XWg5KIemIucLwBfCgdIxMXc8 isqnyrmmTxDD0+fO7EJWymxvmfIe3qW+pQOTJRjfdla6VYVAY+Jk+wHJl3+ZJA+lfiOl Jr7g== X-Gm-Message-State: AEkooutXKv4NsEnFelMJ9YM2ABzUNRVQb9nDdKwszsAFRzfgQ+6MsPVM4WCuhR0dmrax22gBu8a1nXktTaVF6MCZ X-Received: by 10.31.151.196 with SMTP id z187mr15372523vkd.138.1471393694807; Tue, 16 Aug 2016 17:28:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.83.45 with HTTP; Tue, 16 Aug 2016 17:27:54 -0700 (PDT) In-Reply-To: References: <1736097121.90204.1471369988809@privateemail.com> <201608161937.20748.luke@dashjr.org> <20160816194332.GA5888@fedora-21-dvm> From: "Russell O'Connor" Date: Tue, 16 Aug 2016 20:27:54 -0400 Message-ID: To: Gregory Maxwell Content-Type: multipart/alternative; boundary=001a11425e44810c62053a398adc X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HTML_MESSAGE,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: Wed, 17 Aug 2016 00:31:29 +0000 Cc: Bitcoin Protocol Discussion 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:28:19 -0000 --001a11425e44810c62053a398adc Content-Type: text/plain; charset=UTF-8 Okay. I'm not really opposed to this BIP, but I am worried that fighting script malleability is a battle that can never be won; even leaving one avenue of malleability open is probably just as bad as having many avenues of malleability, so it just doesn't seem worthwhile to me. On Tue, Aug 16, 2016 at 8:18 PM, Gregory Maxwell wrote: > 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. > --001a11425e44810c62053a398adc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Okay.

I'm not really opposed to this BIP, but I= am worried that fighting script malleability is a battle that can never be= won; even leaving one avenue of malleability open is probably just as bad = as having many avenues of malleability, so it just doesn't seem worthwh= ile to me.

On Tue, Aug 16, 2016 at 8:18 PM, Gregory Maxwell <<= a href=3D"mailto:greg@xiph.org" target=3D"_blank">greg@xiph.org> wrote:
On Tue, Aug 1= 6, 2016 at 10:52 PM, Russell O'Connor via bitcoin-dev
<bitcoin-dev@li= sts.linuxfoundation.org> wrote:
> I see.
>
> But is it really necessary to soft fork over this issue?=C2=A0 Why not= just make
> it a relay rule?=C2=A0 Miners are already incentivized to modify trans= actions to
> drop excess witness data and/or prioritize (versions of) transactions = based
> on their cost.=C2=A0 If a miner wants to mine a block with excess witn= ess data,
> it is mostly their own loss.

Relay rules are quite fragile-- people build programs or protocols n= ot
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.=C2=A0 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).=C2=A0 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.

--001a11425e44810c62053a398adc--