From: "Odinn Cyberguerrilla" <odinn.cyberguerrilla@riseup•net>
To: "Edmund Edgar" <ed@realitykeys•com>
Cc: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Is this a safe thing to be doing with ECC addition? (Oracle protocol)
Date: Mon, 3 Mar 2014 21:07:45 -0800 [thread overview]
Message-ID: <89bcba571af745c3dbcc68baddf5126f.squirrel@fulvetta.riseup.net> (raw)
In-Reply-To: <CA+su7OWD8dyPLK_AHZdXJ-zeJ81CsLFrKkZo+L-byfLWYsKBPw@mail.gmail.com>
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
>
next prev parent reply other threads:[~2014-03-04 5:07 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-03-04 2:59 Edmund Edgar
2014-03-04 5:07 ` Odinn Cyberguerrilla [this message]
2014-03-08 6:55 Edmund Edgar
2014-03-08 8:10 ` Alan Reiner
2014-03-08 8:51 ` Edmund Edgar
2014-03-08 10:37 ` Joel Kaartinen
2014-03-08 17:41 ` Adam Back
2014-03-08 18:15 ` Natanael
2014-03-08 23:13 ` Alan Reiner
2014-03-08 20:30 ` Alan Reiner
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=89bcba571af745c3dbcc68baddf5126f.squirrel@fulvetta.riseup.net \
--to=odinn.cyberguerrilla@riseup$(echo .)net \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=ed@realitykeys$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox