Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 30A4192 for ; Wed, 21 Oct 2015 08:41:18 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from zinan.dashjr.org (zinan.dashjr.org [192.3.11.21]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 94CA58C for ; Wed, 21 Oct 2015 08:41:17 +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 48E4C38A532F; Wed, 21 Oct 2015 08:39:43 +0000 (UTC) X-Hashcash: 1:25:151021:decker.christian@gmail.com::YVzIttc4YsezGtGQ:gK4C+ X-Hashcash: 1:25:151021:bitcoin-dev@lists.linuxfoundation.org::Mbd=eFYOYF6vWDrz:s4/G From: Luke Dashjr To: Christian Decker Date: Wed, 21 Oct 2015 08:39:41 +0000 User-Agent: KMail/1.13.7 (Linux/4.1.9-gentoo-r1; KDE/4.14.8; x86_64; ; ) References: <201510210752.17527.luke@dashjr.org> 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: <201510210839.42420.luke@dashjr.org> X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD 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@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] [BIP] Normalized transaction IDs X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 21 Oct 2015 08:41:18 -0000 On Wednesday, October 21, 2015 8:31:42 AM Christian Decker wrote: > On Wed, Oct 21, 2015 at 9:52 AM Luke Dashjr wrote: > > On Wednesday, October 21, 2015 7:39:45 AM Christian Decker wrote: > > > On Wed, Oct 21, 2015 at 8:19 AM Luke Dashjr wrote: > > > > This doesn't completely close malleability (which should be > > > > documented > > > > in > > > > > > the BIP), so I'm not sure it's worth the cost, especially if closing > > > > malleability later on would need more. How about specifying flags > > > > upfront > > > > > > in the UTXO-creating transaction specifying which parts the signature > > > > will cover? This would allow implementation of fully > > > > malleability-proof wallets. > > > > > > As far as I see it the only remaining venues for malleability are the > > > use of sighash flags that are not SIGHASH_ALL, as mentioned in the > > > BIP. Any > > > > use > > > > > of non-sighash_all flags is already an explicit permission to modify > > > the transactions, by adding and removing inputs and outputs, so I > > > don't see > > > > how > > > > > these can be made non-malleable. Am I missing something? > > > > Signer malleability is still a notable concern needing consideration. > > Ideally, > > wallets should be trying to actively CoinJoin, bump fees on, etc any > > pending > > transactions in the background. These forms of malleability affect nearly > > as > > many real use cases as third-party malleability. > > > > Luke > > How is signer malleability still a problem if we remove the signatures from > the transaction ID of the transaction and all preceding transactions? The > signer can re-sign a transaction but it won't change the transaction ID. The signer can also change the order of the inputs, the inputs themselves, add/remove outputs, etc... all which should be possible without becoming a different logical transaction. The only unique property of the logical transaction is the scriptPubKey/address. Luke