Odinn Cyberguerrilla [ARCHIVE] on Nostr: 📅 Original date posted:2014-03-04 📝 Original message:Nothing is safe. Take ...
📅 Original date posted:2014-03-04
📝 Original message: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 at 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
📝 Original message: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 at 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>