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
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
|
Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <morcos@gmail.com>) id 1WDkKk-0000IL-KM
for bitcoin-development@lists.sourceforge.net;
Thu, 13 Feb 2014 00:39:18 +0000
Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.216.48 as permitted sender)
client-ip=209.85.216.48; envelope-from=morcos@gmail.com;
helo=mail-qa0-f48.google.com;
Received: from mail-qa0-f48.google.com ([209.85.216.48])
by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WDkKj-00084M-JP
for bitcoin-development@lists.sourceforge.net;
Thu, 13 Feb 2014 00:39:18 +0000
Received: by mail-qa0-f48.google.com with SMTP id f11so15039633qae.7
for <bitcoin-development@lists.sourceforge.net>;
Wed, 12 Feb 2014 16:39:12 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.140.48.104 with SMTP id n95mr68149926qga.90.1392251952036;
Wed, 12 Feb 2014 16:39:12 -0800 (PST)
Received: by 10.140.48.208 with HTTP; Wed, 12 Feb 2014 16:39:11 -0800 (PST)
In-Reply-To: <201402122252.31060.luke@dashjr.org>
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>
Date: Wed, 12 Feb 2014 19:39:11 -0500
Message-ID: <CAPWm=eV9YP3wAbCFt1JcSqJ6Jc3kY_546MVk3cHT+X8seC8vRw@mail.gmail.com>
From: Alex Morcos <morcos@gmail.com>
To: Luke-Jr <luke@dashjr.org>
Content-Type: multipart/alternative; boundary=001a1135183c0ac14f04f23eebab
X-Spam-Score: -0.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
(morcos[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-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: 1WDkKj-00084M-JP
Cc: 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:39:18 -0000
--001a1135183c0ac14f04f23eebab
Content-Type: text/plain; charset=ISO-8859-1
I apologize if this has been discussed many times before.
As a long term solution to malleable transactions, wouldn't it be possible
to modify the signatures to be of the entire transaction. Why do you have
to zero out the inputs? I can see that this would be a hard fork, and
maybe it would be somewhat tricky to extract signatures first (since you
can sign everything except the signatures), but it would seem to me that
this is an important enough change to consider making.
On Wed, Feb 12, 2014 at 5:52 PM, Luke-Jr <luke@dashjr.org> wrote:
> On Wednesday, February 12, 2014 8:27:52 PM Mark Friedenbach wrote:
> > On 02/12/2014 08:44 AM, Alan Reiner wrote:
> > > Changing the protocol to use these static IDs is a pretty fundamental
> > > change that would never happen in Bitcoin. But they can still be
> > > useful at the application level to mitigate these issues.
> >
> > Not to mention that it would be potentially very insecure to have
> > consensus depend on data (scriptSigs) which are not hashed in the Merkle
> > structure of a block.
> >
> > Not that anyone on this list has suggested such a change, but I've seen
> > it raised multiple times on the forum....
>
> This would be a problem if it was used in the merkle tree, but I'm pretty
> sure
> using it for input selection would be pretty safe. One could even avoid the
> index by simply using the hashScript as the sole input value; then even
> CoinJoins would be safe without breaking chains of transactions (although
> this
> would break address reuse entirely - but I don't see that as a problem in a
> theoretical world). One of those things that an altcoin could improve upon
> Bitcoin with... ;)
>
>
> ------------------------------------------------------------------------------
> Android apps run on BlackBerry 10
> Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
> Now with support for Jelly Bean, Bluetooth, Mapview and more.
> Get your Android app in front of a whole new audience. Start now.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=124407151&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--001a1135183c0ac14f04f23eebab
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">I apologize if this has been discussed many times before.<=
div><div><br></div><div>As a long term solution to malleable transactions, =
wouldn't it be possible to modify the signatures to be of the entire tr=
ansaction. =A0Why do you have to zero out the inputs? =A0I can see that thi=
s would be a hard fork, and maybe it would be somewhat tricky to extract si=
gnatures first (since you can sign everything except the signatures), but i=
t would seem to me that this is an important enough change to consider maki=
ng.</div>
<div><br></div><div><br></div><div><br></div><div><br></div>
<div><br></div><div><br></div></div></div><div class=3D"gmail_extra"><br><b=
r><div class=3D"gmail_quote">On Wed, Feb 12, 2014 at 5:52 PM, Luke-Jr <span=
dir=3D"ltr"><<a href=3D"mailto:luke@dashjr.org" target=3D"_blank">luke@=
dashjr.org</a>></span> wrote:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex"><div class=3D"">On Wednesday, February 12, 2=
014 8:27:52 PM Mark Friedenbach wrote:<br>
> On 02/12/2014 08:44 AM, Alan Reiner wrote:<br>
> > Changing the protocol to use these static IDs is a pretty fundame=
ntal<br>
> > change that would never happen in Bitcoin. =A0 But they can still=
be<br>
> > useful at the application level to mitigate these issues.<br>
><br>
> Not to mention that it would be potentially very insecure to have<br>
> consensus depend on data (scriptSigs) which are not hashed in the Merk=
le<br>
> structure of a block.<br>
><br>
> Not that anyone on this list has suggested such a change, but I've=
seen<br>
> it raised multiple times on the forum....<br>
<br>
</div>This would be a problem if it was used in the merkle tree, but I'=
m pretty sure<br>
using it for input selection would be pretty safe. One could even avoid the=
<br>
index by simply using the hashScript as the sole input value; then even<br>
CoinJoins would be safe without breaking chains of transactions (although t=
his<br>
would break address reuse entirely - but I don't see that as a problem =
in a<br>
theoretical world). One of those things that an altcoin could improve upon<=
br>
Bitcoin with... ;)<br>
<div class=3D"HOEnZb"><div class=3D"h5"><br>
---------------------------------------------------------------------------=
---<br>
Android apps run on BlackBerry 10<br>
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.<br>
Now with support for Jelly Bean, Bluetooth, Mapview and more.<br>
Get your Android app in front of a whole new audience. =A0Start now.<br>
<a href=3D"http://pubads.g.doubleclick.net/gampad/clk?id=3D124407151&iu=
=3D/4140/ostg.clktrk" target=3D"_blank">http://pubads.g.doubleclick.net/gam=
pad/clk?id=3D124407151&iu=3D/4140/ostg.clktrk</a><br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" target=3D"_blank">https://lists.sourceforge.net/lists/listinfo/bitcoin-de=
velopment</a><br>
</div></div></blockquote></div><br></div>
--001a1135183c0ac14f04f23eebab--
|
