summaryrefslogtreecommitdiff
path: root/32/7756f1ed6016cd5aac2448e1d48d5f859fc4cf
blob: a2d6f343407c656178f50e2abb5c399ffe406769 (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
175
176
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 1WdnSL-0006sf-HC
	for bitcoin-development@lists.sourceforge.net;
	Fri, 25 Apr 2014 21:14:49 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of petertodd.org
	designates 62.13.148.114 as permitted sender)
	client-ip=62.13.148.114; envelope-from=pete@petertodd.org;
	helo=outmail148114.authsmtp.net; 
Received: from outmail148114.authsmtp.net ([62.13.148.114])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
	id 1WdnSJ-000792-LZ for bitcoin-development@lists.sourceforge.net;
	Fri, 25 Apr 2014 21:14:49 +0000
Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237])
	by punt14.authsmtp.com (8.14.2/8.14.2) with ESMTP id s3PLEeKn057499; 
	Fri, 25 Apr 2014 22:14:40 +0100 (BST)
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 s3PLEYXc030455
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
	Fri, 25 Apr 2014 22:14:37 +0100 (BST)
Date: Fri, 25 Apr 2014 17:14:26 -0400
From: Peter Todd <pete@petertodd.org>
To: Gregory Maxwell <gmaxwell@gmail.com>, Tier Nolan <tier.nolan@gmail.com>
Message-ID: <20140425211426.GD8994@savin>
References: <CAE-z3OVsQAya3RDzMTvKNK4hLGQVjFOp6Bseo=xK4ApOdPCh8g@mail.gmail.com>
	<CAE28kUT4rZJHzww5gsdkCyzyKV6q2bV4h4rL_hzAcvhtCpKW4w@mail.gmail.com>
	<20140425201403.GA8994@savin>
	<CAAS2fgQc_UgwYgc0kVso-cL6xqP-2MGg2JoWDHYyAUXhQkyaoA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature"; boundary="wLAMOaPNJ0fu1fTG"
Content-Disposition: inline
In-Reply-To: <CAAS2fgQc_UgwYgc0kVso-cL6xqP-2MGg2JoWDHYyAUXhQkyaoA@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 9bb8c2a9-ccbe-11e3-94fa-002590a135d3
X-AuthReport-Spam: If SPAM / abuse - report it at:
	http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
	bgdMdAcUGUUGAgsB AmIbWVZeUVl7WmQ7 bAxPbAVDY01GQQRq
	WVdMSlVNFUsrAnx9 c3d2ARlxdwFDfTBy YEJjWz5SDhZyJkQs
	S1MHRj9TeGZhPWMC WUQOJh5UcAFPdx8U a1N6AHBDAzANdhES
	HhM4ODE3eDlSNilR RRkIIFQOdA4hPwZ0 AlgiFC4vVWkCTCY+
	I1QaMFcaB08aLkQ1 NzM+
X-Authentic-SMTP: 61633532353630.1024: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: 1WdnSJ-000792-LZ
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] BIP - Hash Locked Transaction
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: Fri, 25 Apr 2014 21:14:49 -0000


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

On Fri, Apr 25, 2014 at 01:19:48PM -0700, Gregory Maxwell wrote:
> On Fri, Apr 25, 2014 at 1:14 PM, Peter Todd <pete@petertodd.org> wrote:
> > Actually I did some work looking at this problem a few months ago and
> > other than somewhat larger transactions it looks like implementing
> > oracles by having the oracle reveal ECC secret keys works better in
> > every case. Notably the oracle can prove they really do have the key by
> > signing a challenge message, and with some ECC math the transaction can
> > include keys that have been derived from the oracle keys, blinding what
> > purposes the oracle is being used for from the oracle itself.
>=20
> I think the hash-locked transactions are very useful, and I think
> Peter agrees (no?)

Yup. Revealing EC points is *not* a replacement for the hash-locked
case.

> But I agree with him that that for the oracle case the EC public
> points are superior. (Also: Reality keys works like this.)

Same again, and on top of that the EC public point method still works
better in many circumstances with what are currently non-standard
transactions rather than trying to shoe-horn everything into one big
CHECKMULTISIG.


Along those lines, rather than doing up yet another format specific type
as Tier Nolan is doing with his BIP, why not write a BIP looking at how
the IsStandard() rules could be removed? Last year John Dillon proposed
it be replaced by a P2SH opcode whitelist(1) and I proposed some
extensions(2) to the idea to make sure the whitelist didn't pose
transaction mutability issues; very similar to Pieter Wuille's proposed
soft-fork to stamp-out mutability.(3)

The key reasons to have IsStandard() right now are the following:

1) Mitigate transaction mutability.

Pieter's soft-fork mitigates mutability well, and can be applied even
more easily as an IsStandard() rule.


2) Reduce the potential for scripting bugs to impact the ecosystem.

The scripting system has had a lot more testing since IsStandard() was
implemented. Additionally we have a large pool mining non-standard
transactions anyway, mostly negating the value of IsStandard() for this
purpose.


3) Ensure that after a soft-fork upgrade transactions considered
   IsStandard() by the the remaining non-upgraded hashing power continue
   to be valid.

We don't want that hashing power to be able to be tricked into mining
invalid blocks. Future soft-forks for transactions will most likely be
done by either incrementing the transaction version number, or by
redefining one of the OP_NOPx opcodes with new functionality. We just
need to ignore transactions with version numbers that we are not
familiar with and additionally not include any of the OP_NOPx opcodes in
the whitelist.


One last detail is that sigops should be taken into account when
calculating fees; Luke-Jr's accept non-standard patch has code to do
this already.

1) http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/=
msg02606.html
2) http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/=
msg02611.html
3) https://github.com/bitcoin/bips/blob/master/bip-0062.mediawiki

--=20
'peter'[:-1]@petertodd.org
0000000000000000231ff812c54986461c6f76414390f88e41476a2c2c877304

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

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

iQGrBAEBCACVBQJTWtAuXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAzYWQ5MzNiOWM3ZjVmOGM2NTJjMWNkODRjYWVmYTE1OWY2
MzM4NDI2ZTIxNjAxYjIvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfu0/Af9HzRnEEVn25NsVz7OAI/AmEw8
zuF7lKTfMpxrd8fcSMyh/b//MuMEHSDKKI0OvUXE/1yjR5dlw+CErFEWPtRAUKmi
+iE0pZoRXCkctw9wlm+7fQUgeMr0GYutjZmlBTgmvyG9+PcHlyJFHjJCJknzDrEw
5xpQv10JXUCsLI+l30SMpIgMVaQE7VrkiasL+R1CeKZbszHNVvi3M5DcTfHTWBPT
SEdWs0e4TjVfu3voaGXNA+fgc3FKLhvjwXz3OgYMNm0VnHlwrpx/kr+9YdSXhi/R
SAqC/gWyfGmP4oKOFyTXNjYTydikFbZj2JbmKLrF4kMnIXoQP6qK6ZyjSI8nJw==
=/JWI
-----END PGP SIGNATURE-----

--wLAMOaPNJ0fu1fTG--