summaryrefslogtreecommitdiff
path: root/b1/135a43114026cdac57124498db04f8a02290a5
blob: 4ceb950d83ebc6ebd329e3635f17f253a2dedd2a (plain)
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
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <gronager@mac.com>) id 1WG7sY-0000ma-57
	for bitcoin-development@lists.sourceforge.net;
	Wed, 19 Feb 2014 14:12:02 +0000
Received-SPF: pass (sog-mx-2.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-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
	id 1WG7sW-00029q-O2 for bitcoin-development@lists.sourceforge.net;
	Wed, 19 Feb 2014 14:12:02 +0000
Received: from [10.6.3.42]
	(cpe.xe-3-1-0-415.bynqe10.dk.customer.tdc.net [188.180.67.254])
	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 <0N18001XWY3SFC90@nk11p04mm-asmtp002.mac.com>
	for bitcoin-development@lists.sourceforge.net; Wed,
	19 Feb 2014 14:11:55 +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_03: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-1402190061
Content-type: multipart/signed;
	boundary="Apple-Mail=_B811C8D1-DECA-4CA1-9E6B-C5B463AD292B";
	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: <CAAS2fgSwjGohhiXuwhG3bJ5mLxSS8Dx0Hytmg7PhhRzwnw7FNQ@mail.gmail.com>
Date: Wed, 19 Feb 2014 15:11:51 +0100
Message-id: <EFA82A3F-2907-4B2B-9FCB-DCA02CA4EC63@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>
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: 1WG7sW-00029q-O2
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 14:12:02 -0000


--Apple-Mail=_B811C8D1-DECA-4CA1-9E6B-C5B463AD292B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Why introduce a new transaction version for this purpose ? Wouldn't it =
be more elegant to simply let:

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

2. In a version later one could block relay of non deterministic =
transactions, as well as the acceptance of blocks with non-confirming =
transactions.

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.

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.


On Feb 13, 2014, at 1:47 AM, Gregory Maxwell <gmaxwell@gmail.com> wrote:

> 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.
>=20
> It has been, but there are probably many people like you who have not
> bothered researching who may also be curious.
>=20
>> 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.
>=20
> Because doing so would be both unnecessary and ineffective.
>=20
> 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.
>=20
> Ineffective=97 at least as you describe it=97 because the signatures
> _themselves_ are malleable.
>=20
> =
--------------------------------------------------------------------------=
----
> 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=3D124407151&iu=3D/4140/ostg.=
clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--Apple-Mail=_B811C8D1-DECA-4CA1-9E6B-C5B463AD292B
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

iQEcBAEBCgAGBQJTBLunAAoJEKpww0VFxdGRqo0H/2beFlzp0D2g/txVsN+Oj1m9
ufobH9xXAL2Ol0goPvDKBj0iDC/UTXO04Xh9mACLRJVmfyXJhiSGYGCNT7aBc5Dc
///SL5I+AzcDrbKWhf/yy3fDrRTcd4QZ8whcWk1vOQ/G4w9VwaHkWDAfJCXPIGi1
ViUW1tdoBfpKLSx6ovE4Mj8yv+zID9/2IEUnDb21SJl2o20m41doabVVw0A3H+42
gcXagk5g1NoNcwbDL4fAnI0GeLx74VAXZ2KQCxmXRsczhuAziIRtliflSWlgzH6C
eKFyCJHTVo9/ldOpGV8sqH8WiL1jg3AnpADwaSK4tCQuoS0TrsT4YNcB3ZoDzsk=
=VMZ4
-----END PGP SIGNATURE-----

--Apple-Mail=_B811C8D1-DECA-4CA1-9E6B-C5B463AD292B--