Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.215.54 as permitted sender)
	client-ip=209.85.215.54; envelope-from=gmaxwell@gmail.com;
	helo=mail-la0-f54.google.com; 
MIME-Version: 1.0
In-Reply-To: <20140425201403.GA8994@savin>
References: <CAE-z3OVsQAya3RDzMTvKNK4hLGQVjFOp6Bseo=xK4ApOdPCh8g@mail.gmail.com>
	<CAE28kUT4rZJHzww5gsdkCyzyKV6q2bV4h4rL_hzAcvhtCpKW4w@mail.gmail.com>
	<20140425201403.GA8994@savin>
Date: Fri, 25 Apr 2014 13:19:48 -0700
Message-ID: <CAAS2fgQc_UgwYgc0kVso-cL6xqP-2MGg2JoWDHYyAUXhQkyaoA@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: text/plain; charset=UTF-8
Cc: Bitcoin Development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] BIP - Hash Locked Transaction
Precedence: list

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.

I think the hash-locked transactions are very useful, and I think
Peter agrees (no?)

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