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 CBB4589E for ; Sat, 17 Sep 2016 21:10:55 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from zinan.dashjr.org (unknown [192.3.11.21]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 704AC124 for ; Sat, 17 Sep 2016 21:10:55 +0000 (UTC) Received: from ishibashi.localnet (unknown [IPv6:2001:470:5:265:61b6:56a6:b03d:28d6]) (Authenticated sender: luke-jr) by zinan.dashjr.org (Postfix) with ESMTPSA id 9AEB238AB7A6; Sat, 17 Sep 2016 21:10:28 +0000 (UTC) X-Hashcash: 1:25:160917:bitcoin-dev@lists.linuxfoundation.org::RXokxK2SkV/u6dEo:bMhj= X-Hashcash: 1:25:160917:runesvend@gmail.com::p2Sd4sTeL/DCNnLk:aPeUM From: Luke Dashjr To: bitcoin-dev@lists.linuxfoundation.org, "Rune K. Svendsen" Date: Sat, 17 Sep 2016 21:10:26 +0000 User-Agent: KMail/1.13.7 (Linux/4.1.18-gentoo; KDE/4.14.20; x86_64; ; ) References: In-Reply-To: X-PGP-Key-Fingerprint: E463 A93F 5F31 17EE DE6C 7316 BD02 9424 21F4 889F X-PGP-Key-ID: BD02942421F4889F X-PGP-Keyserver: hkp://pgp.mit.edu MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201609172110.27782.luke@dashjr.org> X-Spam-Status: No, score=-0.9 required=5.0 tests=BAYES_00,RDNS_DYNAMIC autolearn=no 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 21:10:55 -0000 On Saturday, September 17, 2016 8:45:17 PM 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. First of all, this is likely to be more trouble than segwit to deploy (mainly just because SegWit is already implemented and tested). Secondly, it wouldn't fix your problem: anyone malleating the transaction would simply update the hash before this opcode... Luke