summaryrefslogtreecommitdiff
path: root/3f/2bfb4b3f033f3e83c7e0cc6089cf8013a01789
blob: 14c77ea781cce6572b6127e0a1ba54e74c434768 (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
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <pete@petertodd.org>) id 1Ymoar-0007wY-NR
	for bitcoin-development@lists.sourceforge.net;
	Mon, 27 Apr 2015 19:21:25 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of petertodd.org
	designates 62.13.148.113 as permitted sender)
	client-ip=62.13.148.113; envelope-from=pete@petertodd.org;
	helo=outmail148113.authsmtp.com; 
Received: from outmail148113.authsmtp.com ([62.13.148.113])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
	id 1Ymoaq-0008Fk-6F for bitcoin-development@lists.sourceforge.net;
	Mon, 27 Apr 2015 19:21:25 +0000
Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235])
	by punt17.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t3RJLGCp027394;
	Mon, 27 Apr 2015 20:21:16 +0100 (BST)
Received: from muck (rrcs-23-246-65-155.nyc.biz.rr.com [23.246.65.155])
	(authenticated bits=128)
	by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t3RJLDZX024602
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
	Mon, 27 Apr 2015 20:21:15 +0100 (BST)
Date: Mon, 27 Apr 2015 15:21:12 -0400
From: Peter Todd <pete@petertodd.org>
To: Stephen Morse <stephencalebmorse@gmail.com>
Message-ID: <20150427191855.GE5223@muck>
References: <552EF785.7000207@sky-ip.org>
	<CAPg+sBgAhdgPPjmT5i0PMYhQo=Hk6Weo8tpX_Wyn-NJ5Ye9D_A@mail.gmail.com>
	<552FDF73.6010104@sky-ip.org>
	<CABjHNoTeMiLWkDBUqdV4HJ=nAhj8wqOjD4cypY9Dv2y9HJWJMg@mail.gmail.com>
	<CABHVRKTMg3sih8i3ta0v=jZU+fBzBR-i5b_b7C+drV4CAfGQJg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="s5/bjXLgkIwAv6Hi"
Content-Disposition: inline
In-Reply-To: <CABHVRKTMg3sih8i3ta0v=jZU+fBzBR-i5b_b7C+drV4CAfGQJg@mail.gmail.com>
X-Server-Quench: 9321eb97-ed12-11e4-b396-002590a15da7
X-AuthReport-Spam: If SPAM / abuse - report it at:
	http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
	aQdMdAUUGUUGAgsB AmMbWVReUlx7WGU7 aQlPbwFbfExLQQRv
	VVdMSlVNFUssAn57 emp0OhlwcwNGejBx YUFlXD5SX0Z7IBR0
	RVMBQWwEeGZhPWQC AkNRcR5UcAFPdx8U a1UrBXRDAzANdhES
	HhM4ODE3eDlSNilR RRkIIFQOdA5UQ3N7 Fk1PVSkvB0AeRyI3
	I1QoLURUAFwYNF47 OkcgXlRQLRIIEQxZ GVol
X-Authentic-SMTP: 61633532353630.1023:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 23.246.65.155/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: 1Ymoaq-0008Fk-6F
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] 75%/95% threshold for transaction versions
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, 27 Apr 2015 19:21:25 -0000


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

On Sat, Apr 25, 2015 at 10:32:36AM -0400, Stephen Morse wrote:
> Hi William,
>=20
> I personally prefer this solution, since it nails the problem
> > completely with one simple and obvious change. The BIP 62 approach is
> > more like a game of wac-a-mole.
> >
>=20
> The two are complementary, not competing. BIP62 prevents *non-signers* fr=
om
> mutating the transactions, which is very important.

I strongly disagree.

There are exactly two cases where mutation matters to normal wallets:

1) Spending unconfirmed change. This can be more efficiently done by
   double-spending the first tx with a second that pays both recipients.

2) Large reorganizations. Making mutation impossible makes it more
   likely that after a large reorg all previously confirmed transactions
   will make it back to the blockchain succesfully.

Meanwhile, the "whack-a-mole" aspect of BIP62 is worrying - it's very
likely we'll miss a case. Even right now there are edge cases without
good solutions, like how in a multisig environment any of the key
holders can mutate transactions. Building wallets that make strong
assumptions about malleability and fail if those assumptions turn out to
be wrong is poor engineering.

> The 'Build your own
> nHashType' proposal enables chained transactions even in the face of
> *signers* mutating the transaction. I believe that integrating both will
> lead to the best defense against transaction malleability, and will enable
> more complicated uses of chained transactions (such as micropayment
> channels).

While I think there are better ways to do 'Build your own nHashType'
than what was recently proposed, I strongly agree that for protocols
that really, truly, need malleability resistance it's far better to use
a purpose-built signature hashing algorithm.

--=20
'peter'[:-1]@petertodd.org
00000000000000000e7980aab9c096c46e7f34c43a661c5cb2ea71525ebb8af7

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

-----BEGIN PGP SIGNATURE-----

iQGrBAEBCACVBQJVPowlXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAwZTc5ODBhYWI5YzA5NmM0NmU3ZjM0YzQzYTY2MWM1Y2Iy
ZWE3MTUyNWViYjhhZjcvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQwIXyHOf0udxJmgf6Ay81VmHzKWlChPK+d0b5y5fG
ttnWNAPZUgWGK1i4bxykIOUSHLmk0NI7aIb0sAhEbGjwSKphNGe2MDOi9qErBEK4
ZWMQvna3zGI1lq9Z2r9KF2Th3HRgQbKhPWsQcR8VUM0EkFVw9iFBWG1KS4fLSlve
ObHrLdngVHST2EIWjhijR9JFs58x/O5YnQvclwxadJhqPm/g3BenWe9dkNf+XUSF
ar1Mpxx3BaL+ujJeyJQrbK+rnk0l5rXOFPQtDypp+shHsILpqgtkfh3XB2/NCtK/
OCLt/5nYzX6VHUezgPh6WEJwf+5Kn9y70nHKGyTq46cwhbz5imvJWCbcSxGoUg==
=w262
-----END PGP SIGNATURE-----

--s5/bjXLgkIwAv6Hi--