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
|
Return-Path: <pete@petertodd.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 10F0D9D
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 24 Jun 2016 22:23:24 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from outmail149080.authsmtp.com (outmail149080.authsmtp.com
[62.13.149.80])
by smtp1.linuxfoundation.org (Postfix) with ESMTP id C1111133
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 24 Jun 2016 22:23:22 +0000 (UTC)
Received: from mail-c247.authsmtp.com (mail-c247.authsmtp.com [62.13.128.247])
by punt21.authsmtp.com (8.14.2/8.14.2/) with ESMTP id u5OMNLlF095783;
Fri, 24 Jun 2016 23:23:21 +0100 (BST)
Received: from petertodd.org (ec2-52-5-185-120.compute-1.amazonaws.com
[52.5.185.120]) (authenticated bits=0)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id u5OMNIjO082522
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
Fri, 24 Jun 2016 23:23:19 +0100 (BST)
Received: from [127.0.0.1] (localhost [127.0.0.1])
by petertodd.org (Postfix) with ESMTPSA id 7D07E4010C;
Fri, 24 Jun 2016 22:21:12 +0000 (UTC)
Received: by localhost (Postfix, from userid 1000)
id F14F620275; Fri, 24 Jun 2016 18:23:16 -0400 (EDT)
Date: Fri, 24 Jun 2016 18:23:16 -0400
From: Peter Todd <pete@petertodd.org>
To: Alex Mizrahi <alex.mizrahi@gmail.com>
Message-ID: <20160624222316.GA28767@fedora-21-dvm>
References: <20160620085649.GA29964@fedora-21-dvm>
<CAE28kUTkBmhLm-7rNVtX7Dm2yYABQiepZX0RCYpBn60Uo9=ehA@mail.gmail.com>
<20160623111152.GB19360@fedora-21-dvm>
<CAE28kUQXLc=-8SoEsWNXz99hezMBmM0ws+Xx3+nrp4YPZkMaPQ@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="cNdxnHkX5QqsyA0e"
Content-Disposition: inline
In-Reply-To: <CAE28kUQXLc=-8SoEsWNXz99hezMBmM0ws+Xx3+nrp4YPZkMaPQ@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Server-Quench: 414c8b95-3a5a-11e6-bcde-0015176ca198
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aAdMdAYUEkAaAgsB AmAbWVdeUl57WGo7 bghPaBtcak9QXgdq
T0pMXVMcUQAXfGJ4 XGEeWht3dQcIeX9y YEQsWnFfD0wofENg
QR9RRHAHZDJmdTJM BBVFdwNVdQJNeEwU a1l3GhFYa3VsNCMk
FAgyOXU9MCtqYA5I QwUBLFQdCWwPGTU/ XFgFE30zHUBNfDk6
MxFuD1cXHEcXPw0b KUM7XlsTM1cODW8W NEZLGyJfPEQaLwAA
X-Authentic-SMTP: 61633532353630.1038:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 52.5.185.120/25
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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: Fri, 24 Jun 2016 22:23:24 -0000
--cNdxnHkX5QqsyA0e
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Thu, Jun 23, 2016 at 03:58:29PM +0300, Alex Mizrahi wrote:
> >
> > 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.
> >
>=20
> 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.)
>=20
> 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 B=
ob
> 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?
Not necessarily. In my writeup I outlined two ways that those chains can be
shortened: trusted validity oracles and the probabalistic, inflationary,
history proof concept.
Equally, even if history grows over time, that's no worse than Bitcoin.
> And how it works in general:
>=20
> 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 t=
he
> expression>" with her PGP key.
Alice isn't _creating_ a tokne, she's _defining_ a token.
> 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 evaluat=
es
> as true. Oracle stores this in a map: Alice_expression -> (Bob_expression=
.
> signatures)
Nope.
In Alice's token definition, the genesis state of the token is defined to be
associated with a specific single-use seal. To transfer the token to Bob, s=
he
asks Bob for the seal he wishes to use, and then closes the genesis seal ov=
er a
new state committing to Bob's seal.
Now Alice could construct the seal for Bob, in which case she'd just need to
know the auth expression Bob wants to use, but that's not the most fundamen=
tal
way of implementing this.
Regardless, the seal oracle doesn't need to know that any of the above is
happening; all it needs to do is spit out seal closed witnesses when the
authorization expressions are satisfied appropriately; the oracle does not =
and
should not know what the seals have been closed over. Whether or not the or=
acle
stores anything when seals are closed is an implementation decision - see my
original writeup on the unbounded vs. bounded oracle case. And of course, s=
eals
implemented with decentralized blockchains are a different matter entirely.
> 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.
>=20
> So this seems to have rather bad scalability even with trusted oracles, am
> I missing something?
Yes, as I mentioned above, there exists multiple techniques that can shorten
history proofs in a variety of ways, depending on what kinds of tradeoffs y=
our
application needs.
--=20
https://petertodd.org 'peter'[:-1]@petertodd.org
--cNdxnHkX5QqsyA0e
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
iQEcBAEBCAAGBQJXbbLSAAoJEGOZARBE6K+yxogH/i4HJ+3NdTnRQsq/u8nXQi4j
4HqNdlTZAousfMTh1hmnlSVkvROKtcAiTinGoPKTtzN/HSTomh6VHQyyl6kLKDg4
p+dVqAIxm9fMTi1ki7RmGMMpo7ztyYkpDmv4JC+cbJUHyyWyEhC7MUL4q4QJhtXg
+4GDVWqyPJsa5c7ZxoLq2JZb4zsba0jxajVm/yjz8l69czr2GgZg0Xqb/VoQuZ1o
Vtp/Zk+GhLrL4fzxrkzqo6AB8YUBaFhV/sfsp9Q4A1FllLSaXYua5c1yMSoqdZXX
NmaRFCu/DXhndIabu++D+ESRlRqpBDwPIFrt3fZK0hd4fMGd+WGGAleAnMb1Zzc=
=HGwD
-----END PGP SIGNATURE-----
--cNdxnHkX5QqsyA0e--
|
