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 0BC3097 for ; Thu, 5 Nov 2015 19:36:58 +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 CFBED159 for ; Thu, 5 Nov 2015 19:36:56 +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 5944938A65D3; Thu, 5 Nov 2015 19:36:10 +0000 (UTC) X-Hashcash: 1:25:151105:jtimon@jtimon.cc::MgYKASQKBgtJdyqD:b1LOO X-Hashcash: 1:25:151105:decker.christian@gmail.com::m4jBHFSbnq/=tm4f:xcSX X-Hashcash: 1:25:151105:bitcoin-dev@lists.linuxfoundation.org::plit/0mVcaKKmJmn:c4rMZ From: Luke Dashjr To: Jorge =?utf-8?q?Tim=C3=B3n?= Date: Thu, 5 Nov 2015 19:36:08 +0000 User-Agent: KMail/1.13.7 (Linux/4.1.9-gentoo-r1; KDE/4.14.8; x86_64; ; ) References: <201511032201.21047.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="utf-8" Content-Transfer-Encoding: quoted-printable Message-Id: <201511051936.09500.luke@dashjr.org> X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_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 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: Thu, 05 Nov 2015 19:36:58 -0000 On Thursday, November 05, 2015 3:27:37 PM Jorge Tim=C3=B3n wrote: > On Tue, Nov 3, 2015 at 11:01 PM, Luke Dashjr via bitcoin-dev >=20 > wrote: > > On Tuesday, November 03, 2015 9:44:02 PM Christian Decker wrote: > >> So this is indeed a form of desired malleability we will likely not be > >> able to fix. I'd argue that this goes more into the direction of > >> double-spending than a form of malleability, and is mostly out of scope > >> for this BIP. As the abstract mentions this BIP attempts to eliminate > >> damage incurred by malleability in the third party modification > >> scenario and in the multisig scenario, with the added benefit of > >> enabling transaction templating. If we can get the segregated witnesses > >> approach working all the better, we don't even have the penalty of > >> increased UTXO size. The problem of singlesig users doublespending > >> their outputs to update transactions remains a problem even then. > >=20 > > I don't know what you're trying to say here. Double spending to the same > > destination(s) and malleability are literally the same thing. Things > > affected by malleability are still just as broken even with this BIP - > > whether it is triggered by a third-party or not is not very relevant. >=20 > I think this is just a terminology confusion. > There's conflicting spends of the same outputs (aka unconfirmed > double-spends), and there's signature malleability which Segregated > Witnesses solves. > If we want to define malleability as signature malleability + > conflicting spends, then that's fine. > But it seems Christian is mostly interested in signature malleability, > which is what SW can solve. > In fact, creating conflicting spends is sometimes useful for some > contracts (ie to cancel the contract when that's supposed to be > allowed). > Maybe it is "incorrect" that people use "malleability" when they're > specifically talking about "signature malleability", but I think that > in this case it's clear that we're talking about transactions having > an id that cannot be changed just by signing with a different nonce > (what SW provides). Ok, then my point is that "signature malleability" is not particularly=20 problematic or interesting alone, and the only way to get a practically-use= ful=20 solution, is to address all kinds of malleability. Luke