summaryrefslogtreecommitdiff
path: root/74/850c2aa43185ed2f3eb6436968a3fb9f1089b2
blob: b6d1555b9d298341b147a810af45f0ef691bfe2b (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
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
	helo=mx.sourceforge.net)
	by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <pete@petertodd.org>) id 1WCh7i-00071s-6N
	for bitcoin-development@lists.sourceforge.net;
	Mon, 10 Feb 2014 03:01:30 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of petertodd.org
	designates 62.13.148.93 as permitted sender)
	client-ip=62.13.148.93; envelope-from=pete@petertodd.org;
	helo=outmail148093.authsmtp.net; 
Received: from outmail148093.authsmtp.net ([62.13.148.93])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
	id 1WCh7h-00042h-2P for bitcoin-development@lists.sourceforge.net;
	Mon, 10 Feb 2014 03:01:30 +0000
Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235])
	by punt14.authsmtp.com (8.14.2/8.14.2) with ESMTP id s1A31L92036587; 
	Mon, 10 Feb 2014 03:01:21 GMT
Received: from savin (76-10-178-109.dsl.teksavvy.com [76.10.178.109])
	(authenticated bits=128)
	by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s1A31HZE090442
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
	Mon, 10 Feb 2014 03:01:19 GMT
Date: Sun, 9 Feb 2014 22:00:48 -0500
From: Peter Todd <pete@petertodd.org>
To: Pieter Wuille <pieter.wuille@gmail.com>
Message-ID: <20140210030048.GB31925@savin>
References: <CAPg+sBgPG+2AMbEHSRQNFn6FikbRzxkWduj5MSZLz-O6Wh940w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="z6Eq5LdranGa6ru8"
Content-Disposition: inline
In-Reply-To: <CAPg+sBgPG+2AMbEHSRQNFn6FikbRzxkWduj5MSZLz-O6Wh940w@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 9dc505f0-91ff-11e3-b802-002590a15da7
X-AuthReport-Spam: If SPAM / abuse - report it at:
	http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
	aAdMdwIUHlAWAgsB AmIbW1deUFx7W2M7 bAxPbAVDY01GQQRq
	WVdMSlVNFUsrAG0C B2Z0Jxl7dwFCejBx ZEdhXT5SCBd/dUMr
	QlNdFDtQeGZhPWMC AkhYdR5UcAFPdx8U a1UrBXRDAzANdhES
	HhM4ODE3eDlSNilR RRkIIFQOdA44JBAX clgxNxQXVVUfQD00
	NBUiHxYwEU8VM0M9 eUQgRVJ6exobDglT FktMBC5FNjH/
X-Authentic-SMTP: 61633532353630.1023:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 76.10.178.109/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
	anti-virus system.
X-Spam-Score: -1.5 (-)
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 SPF_PASS               SPF: sender matches SPF record
X-Headers-End: 1WCh7h-00042h-2P
Cc: Bitcoin Dev <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: Mon, 10 Feb 2014 03:01:30 -0000


--z6Eq5LdranGa6ru8
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon, Feb 10, 2014 at 12:33:02AM +0100, Pieter Wuille wrote:
> Hello all,
>=20
> it was something I planned to do since a long time, but with the
> recent related issues popping up, I finally got around to writing a
> BIP about how we can get rid of transaction malleability over time.
>=20
> The proposed document is here: https://gist.github.com/sipa/8907691
>=20
> I expect most rules to not be controversial. Maybe rules 1 and 3, as
> they require modifications to wallet software (Bitcoin Core 0.9 and
> BitcoinJ already implement it, though) and potentially invalidate some
> script functionality. However, these new rules remain optional and
> controlled by an nVersion increase.
>=20
> Comments please!

You should probably add making CHECKMULTISIG require the dummy value to
be exactly equal to OP_FALSE; verifying that in the transaction itself is
laborious. A more subtle example is we may want both CHECKSIG and
CHECKMULTISIG to fail the transaction if the signature is invalid but
not exactly equal to OP_FALSE; some transaction forms are significantly
more compact if you can have failed signatures, but that's a source of
malleability. (are there counter examples people can think of?)


But as I said on IRC, I'm a bit hesitant to bake in assumptions about
malleability when we have no solid idea if ECC signatures are or are not
malleable on a fundemental level; if "whack-a-mole" anti-malleability is
all we've got it could be ugly if a break is found. Similarly, we may
find we missed something, or some needed change makes the malleability
rules difficult to work with for some new script type that is required.

I'd rather see a new CHECKSIG mode for the case where malleability
absolutely must be eliminated - certain multi-party protocols - and fix
wallet software instead. (the malleability problems people see are
closely related to inability to handle double-spends and reorgs) But I
can easily see that being an impossible goal engineering wise...

--=20
'peter'[:-1]@petertodd.org
0000000000000001465bc2730ffed7493d166d18d288f6cf15e8cdb5d4a3c7b1

--z6Eq5LdranGa6ru8
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (GNU/Linux)

iQGrBAEBCACVBQJS+EDgXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDE0NjViYzI3MzBmZmVkNzQ5M2QxNjZkMThkMjg4ZjZjZjE1
ZThjZGI1ZDRhM2M3YjEvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfvoXQgArcs7lgUpvZqsZR8c7EXSLi/S
TaOs8c+HeP5PPy2auAxiji4gemja7gFjlWi2vJXXBKamlCTnQBP5TyDF5YvwgX6H
zYaa1nROxObFIoqqFD4CCuK1Al0BBKB2e/+FFGJN2M9MjmerBtbvi7RxThYNMqHU
3LCRRVB4KnEsAIcJ/mMb+0MoWL8XSHmVp6fhDc3NMj+flZkv5JJ968jtzG/LvNur
xNpYGSQRYmfrK63HaejDcUhPwmbhUCNbNDdqpNX09BZ7nv9lnS9ew7tGbkgkd4Wa
QTkrSewPkM63BgeSIB0iJK9UOWXLLW46bHpE25tGTbomY2VkM+blsnUJUM9zmQ==
=Gxxa
-----END PGP SIGNATURE-----

--z6Eq5LdranGa6ru8--