summaryrefslogtreecommitdiff
path: root/9d/9ba5a2b16e1c97e7142ebfb60945b50581d017
blob: 22fcbab340988883099e9e4bebfd31c69f5f2827 (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
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
	helo=mx.sourceforge.net)
	by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <pete@petertodd.org>) id 1Xc7IL-0005Mx-NL
	for bitcoin-development@lists.sourceforge.net;
	Thu, 09 Oct 2014 06:33:49 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of petertodd.org
	designates 62.13.148.99 as permitted sender)
	client-ip=62.13.148.99; envelope-from=pete@petertodd.org;
	helo=outmail148099.authsmtp.net; 
Received: from outmail148099.authsmtp.net ([62.13.148.99])
	by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
	id 1Xc7IK-0004r9-BG for bitcoin-development@lists.sourceforge.net;
	Thu, 09 Oct 2014 06:33:49 +0000
Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237])
	by punt18.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s996XavO049540;
	Thu, 9 Oct 2014 07:33:36 +0100 (BST)
Received: from muck (199-36-244-16.mccarran.com [199.36.244.16] (may be
	forged)) (authenticated bits=128)
	by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s996XVIL014239
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
	Thu, 9 Oct 2014 07:33:34 +0100 (BST)
Date: Wed, 8 Oct 2014 23:33:31 -0700
From: Peter Todd <pete@petertodd.org>
To: Gregory Maxwell <gmaxwell@gmail.com>
Message-ID: <20141009063331.GA16898@muck>
References: <CANEZrP1eGi-AHgciQiKUuUB7WwqKsMOyTjCQAAO=RWEkPC2Uiw@mail.gmail.com>
	<CAJHLa0NRNEQLqA2E=ysXsKw6hWS-H9X_AFYK4ckC4-_Bk=qbSA@mail.gmail.com>
	<20141004003850.GA23202@muck>
	<CANEZrP0_jDouDCLn9BvxUd7UYiZLbVsaGGkkxwjcOYxZryBDPQ@mail.gmail.com>
	<CABsx9T0Q8g9KYRbAvCV=35x5Rb5HFnrNkrwwMZ=Mv-namMEPpg@mail.gmail.com>
	<CANEZrP2Xp7ene+KDw_L_YnNW=hDt9K-UigvZ6PLb3oUviOr_Tw@mail.gmail.com>
	<CA+s+GJC2v+g-SWvqdaD2Fb7bb4DkWTtp+e4QNRGvCo1QtraFnQ@mail.gmail.com>
	<5435FD3D.40409@gmail.com>
	<CALqxMTHN4G1HO-7_0Fot943KK-GGOfK9gXDBqaKyyRngiXbuFQ@mail.gmail.com>
	<CAAS2fgRmuyK_k4UU+3Lufaq7=j7wR_MXV1PKeb2HqRRa7VX=pQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="OgqxwSJOaUobr8KG"
Content-Disposition: inline
In-Reply-To: <CAAS2fgRmuyK_k4UU+3Lufaq7=j7wR_MXV1PKeb2HqRRa7VX=pQ@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 325bbab2-4f7e-11e4-9f74-002590a135d3
X-AuthReport-Spam: If SPAM / abuse - report it at:
	http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
	aQdMdgsUF1YAAgsB AmIbW1NeU157WmY7 agNYcwZbfEhKWxtr
	VldMSlVNFUsrCBUH bnhnLhlzcwdFcTBx YUBmWj5YXkEoJxcv
	QFNQQ2pTeGZhPWQC WRZfcx5UcAFPdx8U a1N6AHBDAzANdhES
	HhM4ODE3eDlSNilR RRkIIFQOdA44NB8E DxwYFDszKAUuZwgY
	DDgBAX0gPWM8DGgI EHUQERdQCwUfFABY AyMFCWdFN14cW2Il
	FwRfFUQTETtSCTxE Dxs0agJOHj1WEiNe TEZVUxAVAj9EVy8A VDdYX0UA
X-Authentic-SMTP: 61633532353630.1024:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 199.36.244.16/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.
	-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
	no trust [62.13.148.99 listed in list.dnswl.org]
	-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: 1Xc7IK-0004r9-BG
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent
 a txout from being spent until an expiration time
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, 09 Oct 2014 06:33:49 -0000


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

On Thu, Oct 09, 2014 at 06:28:19AM +0000, Gregory Maxwell wrote:
> On Thu, Oct 9, 2014 at 6:14 AM, Adam Back <adam@cypherspace.org> wrote:
> > I think you can do everything with the existing script level nlocktime
> > in some kind of turing completeness sense (maybe); but there is a
> > complexity cost that often you have to resort to extra dependent
> > transaction(s) (and work-around malleability until that is fully
> > fixed) just to get the effect.
>=20
> Right, ... moreover, even with all the malleability fixes, they only
> work if you refrain from using certain features (e.g. cannot do an
> anyone-can-pay) and we cannot be completely sure all accidental
> vectors for malleability are gone (we've been unable to construct a
> proof that our strengthening of ECDSA turns it into a strong
> signature, though it seems likely).
>=20
> Having the locktime control in a scriptPubKey sidesteps all those
> limitations and simplifies protocols (e.g. not requiring some three
> step state machine and a bunch of risky validation code to be sure a
> refund you receive is actually workable).

Speaking of, can anyone think of an example of a complex transaction
use-case that is affected by malleability which can't be fixed by
CHECKLOCKTIMEVERIFY? I'm sure they exist, but I'm scratching my head
trying to think of a good example.

--=20
'peter'[:-1]@petertodd.org
000000000000000012367d385ad11358a4a1eee86cf8ebe06a76add36dfb4622

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

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

iQGrBAEBCACVBQJUNiw3XhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAxMjM2N2QzODVhZDExMzU4YTRhMWVlZTg2Y2Y4ZWJlMDZh
NzZhZGQzNmRmYjQ2MjIvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfstcAf/QZsEZFPNbzHU3yyGRcVhK2JF
XOz1Ke43kSz8Q3U9FSn6ZbqKDiameBaVpOjXNyQ3sLtT1V0KhnSf1lSOAA4JaA5B
XE2jjeVw9FYp8RUrHmmgvHEUZUfOrDsQt15s1A24IO+tEZy8KGUnc1zsH+Auo6FS
dO2vM6LVLq6lX0YlBdb7Wmmkm+7pwxaJGgammdl5KNJzSsItmKtGDCd1vpZEC1SM
DeGvOXRQEeFmwqL8aSAUBIkqhoLhk3eOYNQItsDX5kYvriptxEr+VBo2NnS7lAUp
Ow7sFZxG41j2A+kjLTCDORbySDvYWVG61OD9lfDg6dkxqIFRAlEIYx3ObGotxg==
=j8uL
-----END PGP SIGNATURE-----

--OgqxwSJOaUobr8KG--