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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <gronager@mac.com>) id 1WGDl9-0005tI-L5
for bitcoin-development@lists.sourceforge.net;
Wed, 19 Feb 2014 20:28:47 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of mac.com
designates 17.158.236.237 as permitted sender)
client-ip=17.158.236.237; envelope-from=gronager@mac.com;
helo=nk11p04mm-asmtp002.mac.com;
Received: from nk11p04mm-asmtpout002.mac.com ([17.158.236.237]
helo=nk11p04mm-asmtp002.mac.com)
by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1WGDl2-0005tf-Mw for bitcoin-development@lists.sourceforge.net;
Wed, 19 Feb 2014 20:28:47 +0000
Received: from [10.0.1.102] (2508ds5-oebr.1.fullrate.dk [90.184.5.129])
by nk11p04mm-asmtp002.mac.com
(Oracle Communications Messaging Server 7u4-27.08(7.0.4.27.7) 64bit
(built Aug
22 2013)) with ESMTPSA id <0N1900LC4FJDGYA0@nk11p04mm-asmtp002.mac.com>
for bitcoin-development@lists.sourceforge.net; Wed,
19 Feb 2014 20:28:28 +0000 (GMT)
X-Proofpoint-Virus-Version: vendor=fsecure
engine=2.50.10432:5.11.87,1.0.14,0.0.0000
definitions=2014-02-19_05:2014-02-18, 2014-02-19,
1970-01-01 signatures=0
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0
suspectscore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam
adjust=0
reason=mlx scancount=1 engine=7.0.1-1401130000
definitions=main-1402190126
Content-type: multipart/signed;
boundary="Apple-Mail=_DB92BE89-E5A2-4C70-98AF-D6F26116E3D8";
protocol="application/pgp-signature"; micalg=pgp-sha512
MIME-version: 1.0 (Mac OS X Mail 7.1 \(1827\))
From: Michael Gronager <gronager@mac.com>
In-reply-to: <CAPg+sBgnuNygR7_yny1=+wGWmeLcub0A8_ep3U-5ewmQJk71jw@mail.gmail.com>
Date: Wed, 19 Feb 2014 21:28:24 +0100
Message-id: <601EE159-9022-4ADF-80AC-7E1C39E86A65@mac.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>
To: Pieter Wuille <pieter.wuille@gmail.com>
X-Mailer: Apple Mail (2.1827)
X-Spam-Score: -2.1 (--)
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
(gronager[at]mac.com)
-0.0 SPF_PASS SPF: sender matches SPF record
-0.6 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
X-Headers-End: 1WGDl2-0005tf-Mw
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: Wed, 19 Feb 2014 20:28:47 -0000
--Apple-Mail=_DB92BE89-E5A2-4C70-98AF-D6F26116E3D8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
charset=iso-8859-1
Twisting your words a bit I read:
* you want to support relay of transactions that can be changed on the =
fly, but you consider it wrong to modify them.
* #3 is already not forwarded, but you still find it relevant to support =
it.
Rational use cases of #3 will be pretty hard to find given the fact that =
they can be changed on the fly. We are down to inclusion in blocks by =
miners for special purposes - or did I miss out something?
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.
/M
On Feb 19, 2014, at 3:38 PM, Pieter Wuille <pieter.wuille@gmail.com> =
wrote:
> On Wed, Feb 19, 2014 at 3:11 PM, Michael Gronager <gronager@mac.com> =
wrote:
>> Why introduce a new transaction version for this purpose ? Wouldn't =
it be more elegant to simply let:
>>=20
>> 1. the next bitcoin version "prettify" all relayed transactions as =
deterministic transactions fulfilling the scheme 1-6 effectively =
blocking any malleability attack? If miners would upgrade then all =
transactions in blocks would have a deterministic hash.
>=20
> I consider actively mutating other's transactions worse than not
> relaying them. If we want people to make their software deal with
> malleability, either will work.
>=20
> Regarding deterministic hash: that's impossible. Some signature hash
> types are inherently (and intentionally) malleable. I don't think we
> should pretend to want to change that. The purpose is making
> non-malleability a choice the sender of a transaction can make.
>=20
> Most of the rules actually are enforced by IsStandard already now.
> Only #1 and #7 aren't. #1 affects the majority of all transactions, so
> changing it right now would be painful. #7 only affects multisig.
>=20
>> 2. In a version later one could block relay of non deterministic =
transactions, as well as the acceptance of blocks with non-confirming =
transactions.
>>=20
>> To non-standard conforming clients this "prettify" change of hash =
would be seen as a constant malleability attack, but given the =
"prettify" code it is to fix any client into producing only conforming =
transactions, just by running the transaction through it before =
broadcast.
>>=20
>> There is a possible fork risk in step 2. above - if a majority of =
miners still havn't upgraded to 1 when 2 is introduced. We could monitor =
% non conforming transaction in a block and only introduce 2. once that =
number is sufficiently small for a certain duration - criteria:
>> * Switch on forcing of unmalleable transactions in blocks when there =
has been only conforming transactions for 1000 blocks.
>=20
> The problem in making these rules into consensus rule (affecting
> tx/block validity) is that some rules (in particular #3) may not be
> wanted by everyone, as they effectively limit the possibilities of the
> script language further. As it is ultimately only about protecting
> senders who care about non-malleability, introducing a new transaction
> version is a very neat way of accomplishing that. The new block
> version number is only there to coordinate the rollout, and choosing
> an automatic forking point.
>=20
> --=20
> Pieter
--Apple-Mail=_DB92BE89-E5A2-4C70-98AF-D6F26116E3D8
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename=signature.asc
Content-Type: application/pgp-signature;
name=signature.asc
Content-Description: Message signed with OpenPGP using GPGMail
-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - https://gpgtools.org
iQEcBAEBCgAGBQJTBRPpAAoJEKpww0VFxdGRrKsIAKJtwyKXkNS5/DbeTR87uRGy
duOx9Q9DHQ4007HisddM+l4kdhbyieTUbjY7XAaW2chrJePSda1Pwt4RQWLVU6OV
Oxx70G7T4KyQdlWDQs6fpyGx7KfYL9HX7a7BVkIZ7spaVyLVMcWZmUqnnx6pV37o
ZvyWFMUOQFpJD0U9Ur4N5kM1p+1JEA4b4LgGMlpYoDn6dd/VaNuW28QjJQZy9hdn
Vc6oItKbHrWa/YpU2IvtU8DRBy7bRx5ERy4NjHlCZU4wKkyPqN42u4vF7SqzKO+i
3JMRAS654H1pgz+Yi5diTDEZxcZhWJai7qQTzy2qDPN3q6HS7F4O6yuyHXCDr/4=
=0W6T
-----END PGP SIGNATURE-----
--Apple-Mail=_DB92BE89-E5A2-4C70-98AF-D6F26116E3D8--
|
