1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <odinn.cyberguerrilla@riseup.net>) id 1WKha5-0006XK-OM
for bitcoin-development@lists.sourceforge.net;
Tue, 04 Mar 2014 05:07:53 +0000
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;
Received: from mx1.riseup.net ([198.252.153.129])
by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:AES256-SHA:256)
(Exim 4.76) id 1WKha4-0004pc-En
for bitcoin-development@lists.sourceforge.net;
Tue, 04 Mar 2014 05:07:53 +0000
Received: from fulvetta.riseup.net (fulvetta-pn.riseup.net [10.0.1.75])
(using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))
(Client CN "*.riseup.net",
Issuer "Gandi Standard SSL CA" (not verified))
by mx1.riseup.net (Postfix) with ESMTPS id 021C855998;
Mon, 3 Mar 2014 21:07:45 -0800 (PST)
Received: from [127.0.0.1] (localhost [127.0.0.1])
(Authenticated sender: odinn.cyberguerrilla@fulvetta.riseup.net)
with ESMTPSA id 8D7062C5
Received: from localhost (127.0.0.1)
(SquirrelMail authenticated user odinn.cyberguerrilla)
by fulvetta.riseup.net with HTTP; Mon, 3 Mar 2014 21:07:45 -0800
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
X-Priority: 3 (Normal)
Importance: Normal
X-Virus-Scanned: clamav-milter 0.97.8 at mx1
X-Virus-Status: Clean
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -1.5 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/,
no trust [198.252.153.129 listed in list.dnswl.org]
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
-0.0 SPF_HELO_PASS SPF: HELO matches SPF record
-0.0 SPF_PASS SPF: sender matches SPF record
-0.0 RP_MATCHES_RCVD Envelope sender domain matches handover relay
domain
0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay
lines
X-Headers-End: 1WKha4-0004pc-En
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Is this a safe thing to be doing with ECC
addition? (Oracle protocol)
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Tue, 04 Mar 2014 05:07:53 -0000
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
>
|
