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 ) 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 To: Gregory Maxwell , Tier Nolan Message-ID: <20140425211426.GD8994@savin> References: <20140425201403.GA8994@savin> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="wLAMOaPNJ0fu1fTG" Content-Disposition: inline In-Reply-To: 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 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 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--