Re: [Bitcoin-development] Is this a safe thing to be doing with ECC addition? (Oracle protocol)

["Odinn Cyberguerrilla" <odinn.cyberguerrilla@riseup.net>]

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ū)



> 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 Hearn
> 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 keys
> 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 and
> uses it to release the funds. Peter Todd suggested what seems like a very
> 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, but I
> don't know enough about this to distinguish the ECC bit of it from magic,
> so I'm wondering if people who do understand it could comment on whether
> it's a safe thing to be doing.
>
> What I'm trying to do here is to combine the public key of each party with
> 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), which
> 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/main.py#L173
>
> What's worrying my superstitious mind is that knowing <reality-key-no-pub>
> 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 without
> 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/realitykeysdemo.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 been
> discussing it here:
> https://bitcointalk.org/index.php?topic=260898.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 and
> the
> freedom to use Git, Perforce or both. Make the move to Perforce.
> http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk_______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>