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
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <natanael.l@gmail.com>) id 1WGHPC-0002MG-QC
for bitcoin-development@lists.sourceforge.net;
Thu, 20 Feb 2014 00:22:22 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
designates 74.125.82.182 as permitted sender)
client-ip=74.125.82.182; envelope-from=natanael.l@gmail.com;
helo=mail-we0-f182.google.com;
Received: from mail-we0-f182.google.com ([74.125.82.182])
by sog-mx-4.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1WGHPB-0004u0-HJ
for bitcoin-development@lists.sourceforge.net;
Thu, 20 Feb 2014 00:22:22 +0000
Received: by mail-we0-f182.google.com with SMTP id u57so944613wes.13
for <bitcoin-development@lists.sourceforge.net>;
Wed, 19 Feb 2014 16:22:15 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.180.98.35 with SMTP id ef3mr4115966wib.39.1392855735181;
Wed, 19 Feb 2014 16:22:15 -0800 (PST)
Received: by 10.194.54.10 with HTTP; Wed, 19 Feb 2014 16:22:15 -0800 (PST)
Received: by 10.194.54.10 with HTTP; Wed, 19 Feb 2014 16:22:15 -0800 (PST)
In-Reply-To: <CAPg+sBg9=XK=PGSW8DcU1LR85oeTDmpS4U-vYUXbraZQpU+edg@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>
<CAAS2fgSwjGohhiXuwhG3bJ5mLxSS8Dx0Hytmg7PhhRzwnw7FNQ@mail.gmail.com>
<EFA82A3F-2907-4B2B-9FCB-DCA02CA4EC63@mac.com>
<CAPg+sBgnuNygR7_yny1=+wGWmeLcub0A8_ep3U-5ewmQJk71jw@mail.gmail.com>
<601EE159-9022-4ADF-80AC-7E1C39E86A65@mac.com>
<CAPg+sBg9=XK=PGSW8DcU1LR85oeTDmpS4U-vYUXbraZQpU+edg@mail.gmail.com>
Date: Thu, 20 Feb 2014 01:22:15 +0100
Message-ID: <CAAt2M1-YC8Bv=11AuT=0ATpX60R=g-PhhK+mBK=VHfEO3xLvxQ@mail.gmail.com>
From: Natanael <natanael.l@gmail.com>
To: Pieter Wuille <pieter.wuille@gmail.com>
Content-Type: multipart/alternative; boundary=f46d044401d851aa9e04f2cb7f4a
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
(natanael.l[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: 1WGHPB-0004u0-HJ
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, 20 Feb 2014 00:22:23 -0000
--f46d044401d851aa9e04f2cb7f4a
Content-Type: text/plain; charset=UTF-8
Regarding chains of transactions intended to be published at once together,
wouldn't it be easier to add a "only-mine-with-child flag"?
That way the parent transactions aren't actually valid unless spent
together with the transaction that depends on it, and only the original
will have a child referencing it.
Then malleability is not an issue at all for transaction chains if you only
need to broadcast your full transaction chain once, and don't need to
extend it in two or more occasions, *after* broadcasting subchains to the
network, from the same set of pregenerated transactions.
If you need to broadcast pregenerated subchains separately, then you need
the last child in the chain to be non-malleable.
This would require all miners to start to respect it at once in order to
avoid forking the network.
- Sent from my phone
Den 19 feb 2014 22:13 skrev "Pieter Wuille" <pieter.wuille@gmail.com>:
> On Wed, Feb 19, 2014 at 9:28 PM, Michael Gronager <gronager@mac.com>
> wrote:
> > I think that we could guarantee fewer incidents by making version 1
> transactions unmalleable and then optionally introduce a version 3 that
> supported the malleability feature. That way most existing problematic
> implementations would be fixed and no doors were closed for people
> experimenting with other stuff - tx v 3 would probably then be called
> experimental transactions.
>
> Just to be clear: this change is not directly intended to avoid
> "incidents". It will take way too long to deploy this. Software should
> deal with malleability. This is a longer-term solution intended to
> provide non-malleability guarantees for clients that a) are upgraded
> to use them b) willing to restrict their functionality. As there are
> several intended use cases for malleable transactions (the sighash
> flags pretty directly are a way to signify what malleabilities are
> *wanted*), this is not about outlawing malleability.
>
> While we could right now make all these rules non-standard, and
> schedule a soft fork in a year or so to make them illegal, it would
> mean removing potential functionality that can only be re-enabled
> through a hard fork. This is significantly harder, so we should think
> about it very well in advance.
>
> About new transaction and block versions: this allows implementing and
> automatically scheduling a softfork without waiting for wallets to
> upgrade. The non-DER signature change was discussed for over two
> years, and implemented almost a year ago, and we still notice wallets
> that don't support it. We can't expect every wallet to be instantly
> modified (what about hardware wallets like the Trezor, for example?
> they may not just be able to be upgraded). Nor is it necessary: if
> your software only spends confirmed change, and tracks all debits
> correctly, there is no need.
>
> --
> Pieter
>
>
> ------------------------------------------------------------------------------
> Managing the Performance of Cloud-Based Applications
> Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
> Read the Whitepaper.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=121054471&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
--f46d044401d851aa9e04f2cb7f4a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<p dir=3D"ltr">Regarding chains of transactions intended to be published at=
once together, wouldn't it be easier to add a "only-mine-with-chi=
ld flag"?</p>
<p dir=3D"ltr">That way the parent transactions aren't actually valid u=
nless spent together with the transaction that depends on it, and only the =
original will have a child referencing it.</p>
<p dir=3D"ltr">Then malleability is not an issue at all for transaction cha=
ins if you only need to broadcast your full transaction chain once, and don=
't need to extend it in two or more occasions, *after* broadcasting sub=
chains to the network, from the same set of pregenerated transactions.</p>
<p dir=3D"ltr">If you need to broadcast pregenerated subchains separately, =
then you need the last child in the chain to be non-malleable. </p>
<p dir=3D"ltr">This would require all miners to start to respect it at once=
in order to avoid forking the network. </p>
<p dir=3D"ltr">- Sent from my phone</p>
<div class=3D"gmail_quote">Den 19 feb 2014 22:13 skrev "Pieter Wuille&=
quot; <<a href=3D"mailto:pieter.wuille@gmail.com">pieter.wuille@gmail.co=
m</a>>:<br type=3D"attribution"><blockquote class=3D"gmail_quote" style=
=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Wed, Feb 19, 2014 at 9:28 PM, Michael Gronager <<a href=3D"mailto:gro=
nager@mac.com">gronager@mac.com</a>> wrote:<br>
> I think that we could guarantee fewer incidents by making version 1 tr=
ansactions unmalleable and then optionally introduce a version 3 that suppo=
rted the malleability feature. That way most existing problematic implement=
ations would be fixed and no doors were closed for people experimenting wit=
h other stuff - tx v 3 would probably then be called experimental transacti=
ons.<br>
<br>
Just to be clear: this change is not directly intended to avoid<br>
"incidents". It will take way too long to deploy this. Software s=
hould<br>
deal with malleability. This is a longer-term solution intended to<br>
provide non-malleability guarantees for clients that a) are upgraded<br>
to use them =C2=A0b) willing to restrict their functionality. As there are<=
br>
several intended use cases for malleable transactions (the sighash<br>
flags pretty directly are a way to signify what malleabilities are<br>
*wanted*), this is not about outlawing malleability.<br>
<br>
While we could right now make all these rules non-standard, and<br>
schedule a soft fork in a year or so to make them illegal, it would<br>
mean removing potential functionality that can only be re-enabled<br>
through a hard fork. This is significantly harder, so we should think<br>
about it very well in advance.<br>
<br>
About new transaction and block versions: this allows implementing and<br>
automatically scheduling a softfork without waiting for wallets to<br>
upgrade. The non-DER signature change was discussed for over two<br>
years, and implemented almost a year ago, and we still notice wallets<br>
that don't support it. We can't expect every wallet to be instantly=
<br>
modified (what about hardware wallets like the Trezor, for example?<br>
they may not just be able to be upgraded). Nor is it necessary: if<br>
your software only spends confirmed change, and tracks all debits<br>
correctly, there is no need.<br>
<br>
--<br>
Pieter<br>
<br>
---------------------------------------------------------------------------=
---<br>
Managing the Performance of Cloud-Based Applications<br>
Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.<br>
Read the Whitepaper.<br>
<a href=3D"http://pubads.g.doubleclick.net/gampad/clk?id=3D121054471&iu=
=3D/4140/ostg.clktrk" target=3D"_blank">http://pubads.g.doubleclick.net/gam=
pad/clk?id=3D121054471&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>
</blockquote></div>
--f46d044401d851aa9e04f2cb7f4a--
|
