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 C957E93D for ; Tue, 16 Aug 2016 22:30:55 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ua0-f174.google.com (mail-ua0-f174.google.com [209.85.217.174]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id EDBD3121 for ; Tue, 16 Aug 2016 22:30:54 +0000 (UTC) Received: by mail-ua0-f174.google.com with SMTP id k90so145553299uak.1 for ; Tue, 16 Aug 2016 15:30:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=Dpu/3cog1ZhO/11vkcFHZ+yd4tbnW5WB2gbhdp2RIOs=; b=TKVeb5/y5+yYAgTwoda1fcFGVK37e/vOw7RV+NZzaLcM+3D7BQ8h36PUWueMXS46ko dNJydbOrD0lwgjzBv4PetsIB2/aY90SPunYjDaMAECnhWHmt0xKVUMqKFwPAiLPw3Oru WT+Es/mmBCIL+467aT02xAakgRR6AxLoAb52LA34OAl+Dur9wAjyexrraEK3EOdwlPTQ Pca5hUMvl2Xh83hSOYeRIwOp65H5K5T2Wvq0jqvNoRCRhJIMkky2DeT2y4TaeXkyc154 lcQcNYOAtJNGovvGYziBWJReHeY8rQ5iDp9DYAFW48gSazxfBx/xk0pYYJ6KUI81Lv5/ sZdw== 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; bh=Dpu/3cog1ZhO/11vkcFHZ+yd4tbnW5WB2gbhdp2RIOs=; b=PKBeHASVh6ubgUhLlFOvmZzc0cvDFlls9QkCPIRQGPoelMdnbIo4RPgq0cRNY9OifY azYEfyd0GVwpFow2M60t2I3qRL1EkCpue3nvatwKGhMMlP6p9l7R8G6fEGNEuqlOsE5T x5y1Rq5E6cKkKoSNB5shkXNJhpFF1t5ENZhVbB2alaEgTbgnoR22dhAESmzOk3feOIi9 aRqw1jzMzxy6TBPLtMKm0GWnc/IT7d97V4BdOE3B0z71EIXQjEQe4AlP8psYbUH+VgKL hoSDd78DlaP8e5MHYrngIJMiZi3EWihUMVL0IXhmxKWTbOUeT9xJltNzko4YQ/aK9Mla t9DQ== X-Gm-Message-State: AEkooutO1NY3sHk81gTwcOXu4sJSyx+CMu9zKQJ12T5TvFnevj2DXDVAidU6p4ySdBAIWKodCbTHaGkW/MmljA== X-Received: by 10.31.98.135 with SMTP id w129mr12746660vkb.93.1471386654077; Tue, 16 Aug 2016 15:30:54 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.51.77 with HTTP; Tue, 16 Aug 2016 15:30:52 -0700 (PDT) Received: by 10.31.51.77 with HTTP; Tue, 16 Aug 2016 15:30:52 -0700 (PDT) In-Reply-To: References: <1736097121.90204.1471369988809@privateemail.com> <201608161937.20748.luke@dashjr.org> <20160816194332.GA5888@fedora-21-dvm> From: Pieter Wuille Date: Wed, 17 Aug 2016 00:30:52 +0200 Message-ID: To: "Russell O'Connor" , Bitcoin Dev Content-Type: multipart/alternative; boundary=94eb2c094e68d7fa34053a37e6da X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,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 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:30:55 -0000 --94eb2c094e68d7fa34053a37e6da Content-Type: text/plain; charset=UTF-8 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. Segwit's third party mallebility protection makes it not an issue for dependent contracts if transactions are mauled (=apparently the verb related to malleability), but there are still good reasons for senders not to gratuitously make their transactions extensible in size or other resources. -- Pieter --94eb2c094e68d7fa34053a37e6da Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

On Aug 17, 2016 00:23, "Russell O'Connor via bitcoi= n-dev" <bi= tcoin-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 abl= e 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= 9;d expose the p2p network to a very cheap DDoS attack: just send increasin= gly small versions of the same transaction.

Segwit's third party mallebility protection makes it not= an issue for dependent contracts if transactions are mauled (=3Dapparently= the verb related to malleability), but there are still good reasons for se= nders not to gratuitously make their transactions extensible in size or oth= er resources.

--
Pieter

--94eb2c094e68d7fa34053a37e6da--