MIME-Version: 1.0
References: <CALxbBHU+kdEAh_4+B663vknAAr8OKZpUzVTACORPZi47E=Ehkw@mail.gmail.com>
	<201511032048.18680.luke@dashjr.org>
	<CALxbBHVwv_T4=DTUdmbgG2y7QmjETCKbQ6_oKKNjsCS=HDrJ+A@mail.gmail.com>
	<201511032201.21047.luke@dashjr.org>
	<CABm2gDpNXGZ7yevFoN9k5nx7wBZX86cH0vJs38DyL+PtEPLHxw@mail.gmail.com>
In-Reply-To: <CABm2gDpNXGZ7yevFoN9k5nx7wBZX86cH0vJs38DyL+PtEPLHxw@mail.gmail.com>
From: Christian Decker <decker.christian@gmail.com>
Date: Fri, 06 Nov 2015 14:52:49 +0000
Message-ID: <CALxbBHXESnrDhx13bUo56FS_zwUJto-FrdCien4TjMAR6esP_w@mail.gmail.com>
To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>, 
	Luke Dashjr <luke@dashjr.org>
Content-Type: multipart/alternative; boundary=089e0141a162456e790523e06611
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [BIP] Normalized transaction IDs
Precedence: list

--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 <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 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

<div dir=3D"ltr"><div class=3D"gmail_quote"><div dir=3D"ltr">On Thu, Nov 5,=
 2015 at 4:27 PM Jorge Tim=C3=B3n &lt;jtimon@jtimon.cc&gt; wrote:<br></div>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">I think this is just a terminology confusion=
.<br>
There&#39;s conflicting spends of the same outputs (aka unconfirmed<br>
double-spends), and there&#39;s signature malleability which Segregated<br>
Witnesses solves.<br>
If we want to define malleability as signature malleability +<br>
conflicting spends, then that&#39;s fine.<br>
But it seems Christian is mostly interested in signature malleability,<br>
which is what SW can solve.<br>
In fact, creating conflicting spends is sometimes useful for some<br>
contracts (ie to cancel the contract when that&#39;s supposed to be<br>
allowed).<br>
Maybe it is &quot;incorrect&quot; that people use &quot;malleability&quot; =
when they&#39;re<br>
specifically talking about &quot;signature malleability&quot;, but I think =
that<br>
in this case it&#39;s clear that we&#39;re talking about transactions havin=
g<br>
an id that cannot be changed just by signing with a different nonce<br>
(what SW provides).<br>
<br>
Please, Christian, correct me if you mean something else.<br></blockquote><=
div><br></div><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 &quot;who signs what when&quot; gotchas.=
 Segregated witnesses would be a perfect solution, we just need to find a g=
ood migration plan for Bitcoin :-)</div><div><br></div><div>Sorry for the c=
onfusion caused by me misusing the term malleability, I&#39;ll use signatur=
e malleability in the future :-)</div></div></div>

--089e0141a162456e790523e06611--