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; 
Message-ID: <89bcba571af745c3dbcc68baddf5126f.squirrel@fulvetta.riseup.net>
In-Reply-To: <CA+su7OWD8dyPLK_AHZdXJ-zeJ81CsLFrKkZo+L-byfLWYsKBPw@mail.gmail.com>
References: <CA+su7OWD8dyPLK_AHZdXJ-zeJ81CsLFrKkZo+L-byfLWYsKBPw@mail.gmail.com>
Date: Mon, 3 Mar 2014 21:07:45 -0800
From: "Odinn Cyberguerrilla" <odinn.cyberguerrilla@riseup.net>
To: "Edmund Edgar" <ed@realitykeys.com>
User-Agent: SquirrelMail/1.4.21
MIME-Version: 1.0
Content-Type: text/plain;charset=utf-8
Importance: Normal
Content-Transfer-Encoding: quoted-printable
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Is this a safe thing to be doing with ECC
 addition? (Oracle protocol)
Precedence: list

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:
>  <alice-pub> + <reality-key-yes-pub>
> ...and another with:
>  <bob-pub> + <reality-key-no-pub>
>
> 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:
>  <alice-priv> + <reality-key-yes-priv>
> ...or
>  <bob-priv> + <reality-key-no-priv>
>
> 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 <reality-key-no-p=
ub>
> before he has to produce <bob-pub>, I'm wondering if there's something =
Bob
> could do with <bob-pub> to intentionally weaken the resulting (<bob-pub=
> +
> <reality-key-no-pub>) so that he could sign a transaction with it witho=
ut
> needing to know <reality-key-no-priv>.
>
> 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
>