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 B1E6890 for ; Fri, 6 Nov 2015 14:53:01 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id DDF3013E for ; Fri, 6 Nov 2015 14:53:00 +0000 (UTC) Received: by wikq8 with SMTP id q8so31770640wik.1 for ; Fri, 06 Nov 2015 06:52:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=AN/C4lFfsjtF7yN6/AYlOtCJgl+ZYrYrwHtsBRMu3iA=; b=RQI+3zoe1k4X034y7/9LkXNplP3GJcPp+9aZzFTUvQw+3hzlYiSE+H7cIgk26yx4sa vnVojCcrW71Y5NXiC98DC+4rlsXgR77OtQ45dg6Qk1qFwnWLLfk9b76IPR+WOVpJ1XCX 20r3Wwcp4DtcvEgaQdO3CLQYZdGK5P7QB1kLMOiLRvMgj5CYYjTJd/ITsDvgvsR6FE7R i49vO8CyiRzFOS2eYwnb/gE8nqjiPsBzgabuVDqfOYPQdsUVpCfaxK3A9QncwcDiIs4z TGK7Hgs/8kv0UkS6/lYnxvaAqPbW/x6a6P58kVsSAJpa0tuS4O7HGjdxNSBDBhWP9FgS Fd6Q== X-Received: by 10.194.243.227 with SMTP id xb3mr16911255wjc.96.1446821579024; Fri, 06 Nov 2015 06:52:59 -0800 (PST) MIME-Version: 1.0 References: <201511032048.18680.luke@dashjr.org> <201511032201.21047.luke@dashjr.org> In-Reply-To: From: Christian Decker Date: Fri, 06 Nov 2015 14:52:49 +0000 Message-ID: To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= , Luke Dashjr Content-Type: multipart/alternative; boundary=089e0141a162456e790523e06611 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 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: Fri, 06 Nov 2015 14:53:01 -0000 --089e0141a162456e790523e06611 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Thu, Nov 5, 2015 at 4:27 PM Jorge Tim=C3=B3n wrote: > 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). > > Please, Christian, correct me if you mean something else. > Yes, your differentiation is spot on. My main goal is to eliminate the risk of detaching transactions in off-blockchain protocols that rely on a number of transactions being chained, hence solving signature malleability might be the correct term. Canonical encodings do address part of the problem, however they do nothing in the case of one of the signers re-signing a transaction and detaching any followup transaction. Also having transaction templates is a nice way to reduce the complexity of protocols by eliminating some of the "who signs what when" gotchas. Segregated witnesses would be a perfect solution, we just need to find a good migration plan for Bitcoin :-) Sorry for the confusion caused by me misusing the term malleability, I'll use signature malleability in the future :-) --089e0141a162456e790523e06611 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On Thu, Nov 5,= 2015 at 4:27 PM Jorge Tim=C3=B3n <jtimon@jtimon.cc> wrote:
=
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 havin= g
an id that cannot be changed just by signing with a different nonce
(what SW provides).

Please, Christian, correct me if you mean something else.
<= div>
Yes, your differentiation is spot on. My main goal is to= eliminate the risk of detaching transactions in =C2=A0off-blockchain proto= cols that rely on a number of transactions being chained, hence solving sig= nature malleability might be the correct term. Canonical encodings do addre= ss part of the problem, however they do nothing in the case of one of the s= igners re-signing a transaction and detaching any followup transaction. Als= o having transaction templates is a nice way to reduce the complexity of pr= otocols by eliminating some of the "who signs what when" gotchas.= Segregated witnesses would be a perfect solution, we just need to find a g= ood migration plan for Bitcoin :-)

Sorry for the c= onfusion caused by me misusing the term malleability, I'll use signatur= e malleability in the future :-)
--089e0141a162456e790523e06611--