1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
|
Return-Path: <decker.christian@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id B1E6890
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 6 Nov 2015 14:53:00 +0000 (UTC)
Received: by wikq8 with SMTP id q8so31770640wik.1
for <bitcoin-dev@lists.linuxfoundation.org>;
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: <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
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 <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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <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 <jtimon@jtimon.cc> 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's conflicting spends of the same outputs (aka unconfirmed<br>
double-spends), and there's signature malleability which Segregated<br>
Witnesses solves.<br>
If we want to define malleability as signature malleability +<br>
conflicting spends, then that'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's supposed to be<br>
allowed).<br>
Maybe it is "incorrect" that people use "malleability" =
when they're<br>
specifically talking about "signature malleability", but I think =
that<br>
in this case it's clear that we'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 "who signs what when" 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'll use signatur=
e malleability in the future :-)</div></div></div>
--089e0141a162456e790523e06611--
|
