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 7687294D for ; Tue, 16 Aug 2016 22:36:46 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ua0-f177.google.com (mail-ua0-f177.google.com [209.85.217.177]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CF794170 for ; Tue, 16 Aug 2016 22:36:45 +0000 (UTC) Received: by mail-ua0-f177.google.com with SMTP id n59so145709346uan.2 for ; Tue, 16 Aug 2016 15:36:45 -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=Og1qbz7mxCMNLd1eoIfuNpdXSH/RnRuNnLP0Rz3cDio=; b=w9K9j5DVcJjy6c6MOjqyiZhRHUlYXZuFLPPUD3slOvRo8C9hPzRlGwpeV3sOBO35/s ajZ9WHa0eeGgey1D77T50/tdKbqI+bqLZFGeBX0VZeT8wCOn8oVJo/aJYE4z0/en7Ror 9+n4PwbGPmaSQioYUBdzOOJKtNhD/y0a/ii1/l5skAX/viATIrBRrxCmLAtlKYjfM/OR Fpxjw2M+G+8O2go2wbYY4DDguM+nCNvrjCCbT99vj2d6pv6+DxnXCvgtz8vMUgJ9btsR 6PZPIFUjb6/29ytCkfI9pHzn2Egb6PE5Z6ADsxZnu9L6Opqezj5Jn0memCUZSj+AyKdC Ykzg== 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=Og1qbz7mxCMNLd1eoIfuNpdXSH/RnRuNnLP0Rz3cDio=; b=M/9RyN9jNTMc0Zov7MY6m64bcf/BykoNj+lflDURjfbMsc/LFITF3L14iUMuWpwTp0 aRmwYMP/20gWvJ2iWzY6CzcrpZYn8k4L9yz+GoiwN5SaFxbxmWCLaBhWESy2x8rbDSuK IP5+drRJfJk02avgdtFAtTc9Oc1Cm3avcrWJCk5PGWDu0SCKldhpIu/afnL80N7CWmu5 MfOkMRUsGC8l52itt+v49M0OscUnWbBi1UlgrIB9X8Ymy6djCValQaLaPA2W+AZjR6i5 CQd/X9bXf37t75HZLEiHWt9EsMqrW0i7vrxB/Pd1++gM0ac0YI4LcQhVfHBQKpzD52bQ whAw== X-Gm-Message-State: AEkooutOvivImvEIm2fedzuwgOqpljJLm4dtyxcZJ/VV4VYiE8avUTyG5yBsCuubwoFdkZ8JLwBa9IGYj23SawfX X-Received: by 10.159.38.73 with SMTP id 67mr18056513uag.136.1471387005076; Tue, 16 Aug 2016 15:36:45 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.83.45 with HTTP; Tue, 16 Aug 2016 15:36:24 -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 18:36:24 -0400 Message-ID: To: Pieter Wuille Content-Type: multipart/alternative; boundary=001a114950dcc3dc0b053a37fb37 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 Cc: Bitcoin Dev 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: Tue, 16 Aug 2016 22:36:46 -0000 --001a114950dcc3dc0b053a37fb37 Content-Type: text/plain; charset=UTF-8 On Tue, Aug 16, 2016 at 6:30 PM, Pieter Wuille wrote: > On Aug 17, 2016 00:23, "Russell O'Connor via bitcoin-dev" < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > > If one's goal is to mess with an transaction to prevent it from being > mined, it is more effective to just not relay the transaction rather than > to mess with the witness. Given two transactions with the same txid and > different witness data, miners and good nodes ought to mine/relay the > version with the lower cost (smaller?) witness data. > > That implies that everyone will see both versions and be able to make that > choice. Unfortunately, those two versions will be definition be in conflict > with each other, and thus only one will end up paying a fee. We're can't > relay two transactions for the price of one, or we'd expose the p2p network > to a very cheap DDoS attack: just send increasingly small versions of the > same transaction. > Can I already do something similar with replace by fee, or are there limits on that? --001a114950dcc3dc0b053a37fb37 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Tue, Aug 16, 2016 at 6:30 PM, Pieter Wuille <p= ieter.wuille@gmail.com> wrote:
=
=

On Aug 17, 2016 00:23, "Russell O'Connor via bitcoi= n-dev" <bitcoin-dev@lists.linuxfoundation.org> wrote:

> If one's goal is to mess with an transaction to pre= vent it from being mined, it is more effective to just not relay the transa= ction rather than to mess with the witness.=C2=A0 Given two transactions wi= th the same txid and different witness data, miners and good nodes ought to= mine/relay the version with the lower cost (smaller?) witness data.

That implies that everyone will see both versions and= be able to make that choice. Unfortunately, those two versions will be def= inition be in conflict with each other, and thus only one will end up payin= g a fee. We're can't relay two transactions for the price of one, o= r we'd expose the p2p network to a very cheap DDoS attack: just send in= creasingly small versions of the same transaction.

Can I already do something similar with replace by fee, o= r are there limits on that?

--001a114950dcc3dc0b053a37fb37--