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 > e...@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 > ------------------------------------------------------------------------------ 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
