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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gmaxwell@gmail.com>) id 1WDkSP-0005Kk-2u
for bitcoin-development@lists.sourceforge.net;
Thu, 13 Feb 2014 00:47:13 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.217.177 as permitted sender)
client-ip=209.85.217.177; envelope-from=gmaxwell@gmail.com;
helo=mail-lb0-f177.google.com;
Received: from mail-lb0-f177.google.com ([209.85.217.177])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WDkSO-0002Au-Ab
for bitcoin-development@lists.sourceforge.net;
Thu, 13 Feb 2014 00:47:13 +0000
Received: by mail-lb0-f177.google.com with SMTP id 10so6077291lbg.8
for <bitcoin-development@lists.sourceforge.net>;
Wed, 12 Feb 2014 16:47:05 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.112.236.3 with SMTP id uq3mr31510336lbc.14.1392252425707;
Wed, 12 Feb 2014 16:47:05 -0800 (PST)
Received: by 10.112.198.34 with HTTP; Wed, 12 Feb 2014 16:47:05 -0800 (PST)
In-Reply-To: <CAPWm=eV9YP3wAbCFt1JcSqJ6Jc3kY_546MVk3cHT+X8seC8vRw@mail.gmail.com>
References: <CAPg+sBgPG+2AMbEHSRQNFn6FikbRzxkWduj5MSZLz-O6Wh940w@mail.gmail.com>
<CALf2ePwc=es-aDSeJO2DZwu9kyHwq9dcp5TrMAhN-dvYwNjy-w@mail.gmail.com>
<52FBD948.906@monetize.io> <201402122252.31060.luke@dashjr.org>
<CAPWm=eV9YP3wAbCFt1JcSqJ6Jc3kY_546MVk3cHT+X8seC8vRw@mail.gmail.com>
Date: Wed, 12 Feb 2014 16:47:05 -0800
Message-ID: <CAAS2fgSwjGohhiXuwhG3bJ5mLxSS8Dx0Hytmg7PhhRzwnw7FNQ@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Alex Morcos <morcos@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.6 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(gmaxwell[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1WDkSO-0002Au-Ab
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with
malleability
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Thu, 13 Feb 2014 00:47:13 -0000
On Wed, Feb 12, 2014 at 4:39 PM, Alex Morcos <morcos@gmail.com> wrote:
> I apologize if this has been discussed many times before.
It has been, but there are probably many people like you who have not
bothered researching who may also be curious.
> As a long term solution to malleable transactions, wouldn't it be possibl=
e
> to modify the signatures to be of the entire transaction. Why do you hav=
e
> to zero out the inputs? I can see that this would be a hard fork, and ma=
ybe
> it would be somewhat tricky to extract signatures first (since you can si=
gn
> everything except the signatures), but it would seem to me that this is a=
n
> important enough change to consider making.
Because doing so would be both unnecessary and ineffective.
Unnecessary because we can very likely eliminate malleability without
changing what is signed. It will take time, but we have been
incrementally moving towards that, e.g. v0.8 made many kinds of
non-canonical encoding non-standard.
Ineffective=E2=80=94 at least as you describe it=E2=80=94 because the signa=
tures
_themselves_ are malleable.
|
