From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WKha5-0006XK-OM for bitcoin-development@lists.sourceforge.net; Tue, 04 Mar 2014 05:07:53 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of riseup.net designates 198.252.153.129 as permitted sender) client-ip=198.252.153.129; envelope-from=odinn.cyberguerrilla@riseup.net; helo=mx1.riseup.net; Received: from mx1.riseup.net ([198.252.153.129]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) id 1WKha4-0004pc-En for bitcoin-development@lists.sourceforge.net; Tue, 04 Mar 2014 05:07:53 +0000 Received: from fulvetta.riseup.net (fulvetta-pn.riseup.net [10.0.1.75]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "*.riseup.net", Issuer "Gandi Standard SSL CA" (not verified)) by mx1.riseup.net (Postfix) with ESMTPS id 021C855998; Mon, 3 Mar 2014 21:07:45 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) (Authenticated sender: odinn.cyberguerrilla@fulvetta.riseup.net) with ESMTPSA id 8D7062C5 Received: from localhost (127.0.0.1) (SquirrelMail authenticated user odinn.cyberguerrilla) by fulvetta.riseup.net with HTTP; Mon, 3 Mar 2014 21:07:45 -0800 Message-ID: <89bcba571af745c3dbcc68baddf5126f.squirrel@fulvetta.riseup.net> In-Reply-To: References: Date: Mon, 3 Mar 2014 21:07:45 -0800 From: "Odinn Cyberguerrilla" To: "Edmund Edgar" User-Agent: SquirrelMail/1.4.21 MIME-Version: 1.0 Content-Type: text/plain;charset=utf-8 X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: clamav-milter 0.97.8 at mx1 X-Virus-Status: Clean Content-Transfer-Encoding: quoted-printable 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 [198.252.153.129 listed in list.dnswl.org] -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_HELO_PASS SPF: HELO matches SPF record -0.0 SPF_PASS SPF: sender matches SPF record -0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay domain 0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay lines X-Headers-End: 1WKha4-0004pc-En Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] Is this a safe thing to be doing with ECC addition? (Oracle protocol) 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: Tue, 04 Mar 2014 05:07:53 -0000 Nothing is safe. Take risks. Engage one trouble at a time. Perform unexpected actions. Observe the results. Rinse and repeat. Ignore the lions. They too shall pass. "Do not sleep under a roof. Carry no money or food. Go alone to places frightening to the common brand of men. Become a criminal of purpose. Be put in jail, and extricate yourself by your own wisdom." -- Miyamoto Musashi (Niten Ichi-ry=C5=AB) > Some people may have seen my service Reality Keys, which can perform a > role > a bit like an External State Oracle as described previously by Mike Hea= rn > and others. (I like to think of it as a Certificate Authority for > propositions, doing for facts what Verisign do for identities.) You > register a possible outcome with us, we publish a public key for "yes" = and > another for "no", and once the outcome happens or fails to happen, we > publish the appropriate private key. > > A few people have been asking for advice on the best way to use our key= s > to > make m-of-n contracts, where each party locks up their stake in a > transaction, then the winner gets their private key from Reality Keys a= nd > uses it to release the funds. Peter Todd suggested what seems like a ve= ry > nice way to do this without needing non-standard transactions or refund > transactions. I've had a go at implementing it and it seems to work, bu= t I > don't know enough about this to distinguish the ECC bit of it from magi= c, > so I'm wondering if people who do understand it could comment on whethe= r > it's a safe thing to be doing. > > What I'm trying to do here is to combine the public key of each party w= ith > the public key of the outcome they're representing, eg I make a public = key > with: > + > ...and another with: > + > > That goes into a 1/2 P2SH address (in the simplest possible case), whic= h > is > spendable by one of Alice or Bob after the outcome occurs with either: > + > ...or > + > > I'm making the transaction with add_pubkeys, then spending it with > add_privkeys, both from: > https://github.com/vbuterin/pybitcointools/blob/master/pybitcointools/m= ain.py#L173 > > What's worrying my superstitious mind is that knowing > before he has to produce , I'm wondering if there's something = Bob > could do with to intentionally weaken the resulting ( + > ) so that he could sign a transaction with it witho= ut > needing to know . > > My example script (and specifically the bit that's scaring me) is here: > https://github.com/edmundedgar/realitykeys-examples/blob/master/reality= keysdemo.py#L247 > > PS. I hope I'm not too far off-topic. Peter Todd suggested it might be > worth talking about here as it potentially has implications for other > protocols. If people prefer to respond at bitcointalk instead, we've be= en > discussing it here: > https://bitcointalk.org/index.php?topic=3D260898.60 > > -- > Edmund Edgar > Founder, Social Minds Inc (KK) > Twitter: @edmundedgar > Linked In: edmundedgar > Skype: edmundedgar > http://www.socialminds.jp > > Reality Keys > @realitykeys > ed@realitykeys.com > https://www.realitykeys.com > -----------------------------------------------------------------------= ------- > Subversion Kills Productivity. Get off Subversion & Make the Move to > Perforce. > With Perforce, you get hassle-free workflows. Merge that actually works= . > Faster operations. Version large binaries. Built-in WAN optimization a= nd > the > freedom to use Git, Perforce or both. Make the move to Perforce. > http://pubads.g.doubleclick.net/gampad/clk?id=3D122218951&iu=3D/4140/os= tg.clktrk_______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development >