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 051C09C for ; Sat, 17 Sep 2016 22:34:45 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-oi0-f54.google.com (mail-oi0-f54.google.com [209.85.218.54]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 603BEE2 for ; Sat, 17 Sep 2016 22:34:44 +0000 (UTC) Received: by mail-oi0-f54.google.com with SMTP id r126so150566131oib.0 for ; Sat, 17 Sep 2016 15:34:44 -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=/yFBLj38VL9b77ibRrmybNZBpgvWDkGXPwo234nej0c=; b=ljN8iAPGT7vt1u+Yz5eOX9TQTczKMkFI6FwiKDjVBUcJifkJN7zOQqSmUyslSMePQm vH+D//xh7kN8YEa8Z0LqlEw35HABf+e65/Qyi4So30MyhWkzyhwuoigU3OgpR4X1BcKt PQDYSfyag7bIQupjOskiF1MDEbE16U6aMse2qb82MyRxgZaiEZLAhrsFAHxvEHrEXhTk Wfw7Xbv1Qhu9F3shfGhqHAwPxWNuVHpNmlBlMZnY62kL45/Rzsm7cYg2p+F6Y5Fadedj VqT7iBi2gGeOvNYYjAnEAvdr9FRKZ+ni3IsGVKBtOFMGdcW/Bp+7gGARisEYsCLAWQZv wlig== 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=/yFBLj38VL9b77ibRrmybNZBpgvWDkGXPwo234nej0c=; b=dl2pJ3OEDSrpu2pXxRk7+awg6YvGwHjlReHEqRnXhPrF7CzsZL+pAAYFF55BwAr5fc aPxZJuSIEKULK2OmwzpsEXXZVWDOMWjFOH2phuU1+wSw/hOUW93TjZR/+9enZjJlayzi 46676u++p8+PeG4IDfNjgkUN1FoHsp0qHaxt7BHUxP4eTcV2RUOFFs0RaRw1XMJQwcKY KBzN7IF1Jdp527CBPp/jFDtB7bEyXCLX64Aa2xfBp08Gyb1DQOl6s7Gh9H2JMGMEep54 ARDJjAoYQP9QY/i1qh2p1CUh5AbeuK7hj3G9gZPJcp2C3ByaIpxK3zQLIGuvG2e5/0La QpTA== X-Gm-Message-State: AE9vXwOxB69esN37Y7VlHq4ywZT3Ko/wioePVLpFAzmZed0VhrUNWq9FXn9kmbs4SI28NokN0iIwJKc51BUI7g== X-Received: by 10.202.228.69 with SMTP id b66mr19745940oih.168.1474151683750; Sat, 17 Sep 2016 15:34:43 -0700 (PDT) MIME-Version: 1.0 Received: by 10.182.52.39 with HTTP; Sat, 17 Sep 2016 15:34:43 -0700 (PDT) In-Reply-To: References: <715F2390-221E-4646-A7F6-3FB937A08764@mattcorallo.com> From: Nick ODell Date: Sat, 17 Sep 2016 16:34:43 -0600 Message-ID: To: "Rune K. Svendsen" , Bitcoin Protocol Discussion Content-Type: text/plain; charset=UTF-8 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, 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] Simple tx ID malleability fix, opcode proposal: OP_TXHASHVERIFY 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: Sat, 17 Sep 2016 22:34:45 -0000 Then you have a new problem. Hash1 must contain Hash2 and the transaction, but Hash2 must contain Hash1 and the transaction. A circular dependency. --Nick On Sat, Sep 17, 2016 at 3:14 PM, Rune K. Svendsen via bitcoin-dev wrote: > I hadn't thought of that... There is a solution, I think, but it makes the > operation less simple. > > If a transaction contains at least two OP_TXHASHVERIFY-protected inputs, > signed without ANYONECANPAY, their signatures would cover the other input's > OP_TXHASHVERIFY hash, right? > > > /Rune > > > On Sat, Sep 17, 2016 at 10:56 PM, Matt Corallo > wrote: >> >> (removing the list) >> >> Because the tx hash in your construction is not signed, someone wishing to >> maleate a transaction may do so by also updating the hash in the scriptSig. >> >> Matt >> >> On September 17, 2016 4:45:17 PM EDT, "Rune K. Svendsen via bitcoin-dev" >> wrote: >>> >>> I would really like to be able to create transactions that are immune to >>> transaction ID malleability now, so I have been thinking of the simplest >>> solution possible, in order to get a BIP through without too much trouble. >>> >>> An opcode we could call OP_TXHASHVERIFY could be introduced. It would be >>> defined to work only if added to a scriptSig as the very first operation, >>> and would abort if the hash of the transaction **with all OP_TXHASHVERIFY >>> operations (including stack push) removed** does not match what has been >>> pushed on the stack. >>> >>> So, in order to produce a transaction with one or more inputs protected >>> against tx ID malleability, one would: >>> >>> 1. Calculate tx ID of the tx: TX_HASH >>> 2. For each input you wish to protect, add "0x32 $TX_HASH >>> OP_TXHASHVERIFY" to the beginning of the scriptSig >>> >>> When evaluating OP_TXHASHVERIFY, we make a copy of the tx in question, >>> and remove the "0x32 <32 bytes> OP_TXHASHVERIFY" sequence from the beginning >>> of all scriptSigs (if present), and abort if the tx copy hash does not match >>> the top stack item. >>> >>> This is a very simple solution that only adds 34 bytes per input, and >>> when something better becomes available (eg. Segwit), we will stop using >>> this. But in the meantime it's very valuable to be able to not worry about >>> tx ID malleability. >>> >>> Please let me know what you think. >>> >>> >>> >>> /Rune >>> >>> ________________________________ >>> >>> bitcoin-dev mailing list >>> bitcoin-dev@lists.linuxfoundation.org >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev >