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
|
Return-Path: <alex.mizrahi@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id F4123884
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 Jun 2016 12:58:31 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f174.google.com (mail-qk0-f174.google.com
[209.85.220.174])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5A44B176
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 Jun 2016 12:58:31 +0000 (UTC)
Received: by mail-qk0-f174.google.com with SMTP id a186so105373782qkf.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 Jun 2016 05:58:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc; bh=ORrvcH9aDD3MVAqIr2iNMTp4HYAn1mXgm+SjCoGfc/w=;
b=rUKAk9Isp/PO/Umbzy8Np2ntIu13keeQj4QdSxIT9O8EetfDDJoKy2/YIj9/uns3d6
jCoMiAeoTXPwVY8JW+yNEq7zZ7Vefygm6IEZuDTIG8M9f6zdgr8xZTrV8nNDCw/i/jS2
zAks495+iAkQdd8KfErHZdjcW0fHV8eqdC9CbiaAwerPmgOGjMgC2dU6BTR+2CRSutU7
1UnINOijspHisH6F6xkRzLtLCEa8fncarUFOSNFwQ28+aHnnRDO4zG2eLk2CjuoaTl73
pX8XStfeDyG3yYgK6nC8S04ryZZiwNdiN2xO2XKPvbVPoD0kl27Fg4hWyWJxOA2h/zZE
8Wzw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc;
bh=ORrvcH9aDD3MVAqIr2iNMTp4HYAn1mXgm+SjCoGfc/w=;
b=jxYgf40wyUn2GFUQY876SfYmC774U7It1ZGyNZ6yGhFsfnaed2rstuCFhnQSIPlcm9
VCidFTSm4aDhgInGVtkiCsomm825SpN9mS+LC82njqm91m0j8TzH3Oq2ZTm/saR4EeG2
NUOeZ/cbqJhysZA9ONTAw02Vqy/JQbTTbCXgS5OOm5ZTYlHL6NpPIfhIIbARqMHaKs2F
PCqchpwnpmkTs6cq/SUPa6isZaq8koiE3aJXEBeWzpW49oRFM1rS7Ut45XqjhBwsESYK
t4MPHxI+Z6ON2CV31ESGd35pNQ5hAY6VFfl9LeLzvNTAt/UJfjCJAFuVZDQf4vAzPZ3Y
KWOA==
X-Gm-Message-State: ALyK8tIzxuN+aHrReR+O63YJBbxKaYBYGRtLlFdV3tbovesiU5aDQvmqRKeQ1xAr7pkOkE9he7rG9nGHTgjuxA==
X-Received: by 10.200.37.9 with SMTP id 9mr25368725qtm.31.1466686710430; Thu,
23 Jun 2016 05:58:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.55.50.85 with HTTP; Thu, 23 Jun 2016 05:58:29 -0700 (PDT)
In-Reply-To: <20160623111152.GB19360@fedora-21-dvm>
References: <20160620085649.GA29964@fedora-21-dvm>
<CAE28kUTkBmhLm-7rNVtX7Dm2yYABQiepZX0RCYpBn60Uo9=ehA@mail.gmail.com>
<20160623111152.GB19360@fedora-21-dvm>
From: Alex Mizrahi <alex.mizrahi@gmail.com>
Date: Thu, 23 Jun 2016 15:58:29 +0300
Message-ID: <CAE28kUQXLc=-8SoEsWNXz99hezMBmM0ws+Xx3+nrp4YPZkMaPQ@mail.gmail.com>
To: Peter Todd <pete@petertodd.org>
Content-Type: multipart/alternative; boundary=001a113bcc445f432a0535f19c29
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Building Blocks of the State Machine Approach to
Consensus
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Thu, 23 Jun 2016 12:58:32 -0000
--001a113bcc445f432a0535f19c29
Content-Type: text/plain; charset=UTF-8
>
> The point I'm making is simply that to be useful, when you close a seal you
> have to be able to close it over some data, in particular, another seal.
> That's
> the key thing that makes the idea a useful construct for smart contacts,
> value
> transfer/currency systems, etc.
>
OK, your second post ("Closed Seal Sets and Truth Lists for Better Privacy
and Censorship Resistance") seems to clarify that this data is one of
arguments to the condition function.
Frankly this stuff is rather hard to follow. (Or maybe I'm dumb.)
Now I don't get scability properties. Let's consider a simplest scenario
where Alice creates some token, sends it to Bob, who sends it to Claire. So
now Claire needs to get both a proof that Alice sent it to Bob and that Bob
sent it to Claire, right? So Claire needs to verify 2 proofs, and for a
chain of N transfers one would need to verify N proofs, right?
And how it works in general:
1. Alice creates a token. To do that she constructs an unique expression
which checks her signature and signs a message "This token has such and
such meaning and its ownership originally associated with seal <hash of the
expression>" with her PGP key.
2. To transfer this token to Bob, she asks Bob for his auth expression and
sends a seal oracle a message (Alice_expression (Bob_expression .
signature)) where signatures is constructed in such a way that it evaluates
as true. Oracle stores this in a map: Alice_expression -> (Bob_expression .
signatures)
3. Bob sends token to Claire in a same way: (Bob_expression
(Claire_expression . signature))
4. Now Claire asks if Alice_expression->(Bob_expression . _) and
Bob_expression->(Claire_expression . _) are in oracle's map. She might
trust the oracle to verify signatures, but oracle doesn't understand token
semantics. Thus she needs to check if these entries were added.
If I understand correctly, Alice_expression->(Bob_expression . _) record
can be communicated in just 3 * size_of_hash_digest bytes.
So this seems to have rather bad scalability even with trusted oracles, am
I missing something?
--001a113bcc445f432a0535f19c29
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><span class=3D"im" style=3D"fon=
t-size:12.8px"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-lef=
t-style:solid;padding-left:1ex">The point I'm making is simply that to =
be useful, when you close a seal you<br>have to be able to close it over so=
me data, in particular, another seal. That's<br>the key thing that make=
s the idea a useful construct for smart contacts, value<br>transfer/currenc=
y systems, etc.<br></blockquote><div><br></div></span><div style=3D"font-si=
ze:12.8px">OK, your second post ("<span style=3D"font-size:inherit;fon=
t-weight:inherit">Closed Seal Sets and Truth Lists for Better Privacy and C=
ensorship Resistance") seems to clarify that this data is one of argum=
ents to the condition function.</span></div><div style=3D"font-size:12.8px"=
><span style=3D"font-size:inherit;font-weight:inherit">Frankly this stuff i=
s rather hard to follow. (Or maybe I'm dumb.)</span></div><div style=3D=
"font-size:12.8px"><span style=3D"font-size:inherit;font-weight:inherit"><b=
r></span></div><div style=3D"font-size:12.8px"><span style=3D"font-size:inh=
erit;font-weight:inherit">Now I don't get scability properties. Let'=
;s consider a simplest scenario where Alice creates some token, sends it to=
Bob, who sends it to Claire. So now Claire needs to get both a proof that =
Alice sent it to Bob and that Bob sent it to Claire, right? So Claire needs=
to verify 2 proofs, and for a chain of N transfers one would need to verif=
y N proofs, right?</span></div><div style=3D"font-size:12.8px"><span style=
=3D"font-size:inherit;font-weight:inherit"><br></span></div><div style=3D"f=
ont-size:12.8px"><span style=3D"font-size:inherit;font-weight:inherit">And =
how it works in general:</span></div><div style=3D"font-size:12.8px"><span =
style=3D"font-size:inherit;font-weight:inherit"><br></span></div><div style=
=3D"font-size:12.8px"><span style=3D"font-size:inherit;font-weight:inherit"=
>1. Alice creates a token. To do that she constructs an unique expression w=
hich checks her signature and signs a message "This token has such and=
such meaning and its ownership originally associated with seal <hash of=
the expression>" with her PGP key.</span></div><div style=3D"font-=
size:12.8px"><span style=3D"font-size:inherit;font-weight:inherit">2. To tr=
ansfer this token to Bob, she asks Bob for his auth expression and sends a =
seal oracle a message (Alice_expression (Bob_expression . signature)) where=
signatures is constructed in such a way that it evaluates as true. Oracle =
stores this in a map: Alice_expression -> (Bob_expression . signatures)<=
/span></div><div style=3D"font-size:12.8px">3. Bob sends token to Claire in=
a same way: (Bob_expression (Claire_expression . signature))</div><div sty=
le=3D"font-size:12.8px">4. Now Claire asks if Alice_expression->(Bob_exp=
ression . _) and Bob_expression->(Claire_expression . _) are in oracle&#=
39;s map. She might trust the oracle to verify signatures, but oracle doesn=
't understand token semantics. Thus she needs to check if these entries=
were added.</div><div style=3D"font-size:12.8px">If I understand correctly=
, Alice_expression->(Bob_expression . _) record can be communicated in j=
ust 3 * size_of_hash_digest bytes.</div><div style=3D"font-size:12.8px"><br=
></div><div style=3D"font-size:12.8px">So this seems to have rather bad sca=
lability even with trusted oracles, am I missing something?</div></div></di=
v>
--001a113bcc445f432a0535f19c29--
|
