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
|
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 5040E486
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 Jun 2016 11:11:58 +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 0E64D139
for <bitcoin-dev@lists.linuxfoundation.org>;
Thu, 23 Jun 2016 11:11:56 +0000 (UTC)
Received: from mail-c232.authsmtp.com (mail-c232.authsmtp.com [62.13.128.232])
by punt21.authsmtp.com (8.14.2/8.14.2/) with ESMTP id u5NBBtGl072308;
Thu, 23 Jun 2016 12:11:55 +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 u5NBBrp1078280
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
Thu, 23 Jun 2016 12:11:54 +0100 (BST)
Received: from [127.0.0.1] (localhost [127.0.0.1])
by petertodd.org (Postfix) with ESMTPSA id 9F9B54010D;
Thu, 23 Jun 2016 11:09:49 +0000 (UTC)
Received: by localhost (Postfix, from userid 1000)
id D674320217; Thu, 23 Jun 2016 07:11:52 -0400 (EDT)
Date: Thu, 23 Jun 2016 07:11:52 -0400
From: Peter Todd <pete@petertodd.org>
To: Alex Mizrahi <alex.mizrahi@gmail.com>
Message-ID: <20160623111152.GB19360@fedora-21-dvm>
References: <20160620085649.GA29964@fedora-21-dvm>
<CAE28kUTkBmhLm-7rNVtX7Dm2yYABQiepZX0RCYpBn60Uo9=ehA@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="7iMSBzlTiPOCCT2k"
Content-Disposition: inline
In-Reply-To: <CAE28kUTkBmhLm-7rNVtX7Dm2yYABQiepZX0RCYpBn60Uo9=ehA@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Server-Quench: 4b3713d6-3933-11e6-829e-00151795d556
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aAdMdAEUEkAaAgsB AmAbWlZeUVx7XGc7 bghPaBtcak9QXgdq
T0pMXVMcUQAWc25D Rh8eVRFwfwUIf3p2 ZQhmDHNcXUcuc1t+
S01XCGwHMGF9YGIW BV1YdwJRcQRDe0tA b1YxNiYHcQ5VPz4z
GA41ejw8IwAXAjlU Rg0MK11aa0IMFT0n DxcMVSkvEAU+Wywv
IlQDI1UcHUAcemwq KUEmUFkYewMVaEV1 GEdWDSlCOkJp
X-Authentic-SMTP: 61633532353630.1037: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: Thu, 23 Jun 2016 11:11:58 -0000
--7iMSBzlTiPOCCT2k
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Tue, Jun 21, 2016 at 01:28:48AM +0300, Alex Mizrahi wrote:
> > All practical single-use seals will be associated with some kind of
> > condition,
> > such as a pubkey, or deterministic expression, that needs to be satisfi=
ed
> > for
> > the seal to be closed.
>=20
>=20
> I think it would be useful to classify systems w.r.t. what data is
> available to condition.
> I imagine it might be useful if status of other seals is available.
Useful yes, but actually implementing that often results in systems that are
too tightly coupled to scale well.
> > Secondly, the contents of the proof will be able to
> > commit to new data, such as the transaction spending the output associa=
ted
> > with
> > the seal.
> >
>=20
> So basically a "condition" returns that "new data", right?
> If it commits to a data in a recognizable way, then it's practically a
> function which yields a tuple (valid, new_data).
> If an oracle doesn't care about data then you can convert it to a predica=
te
> using a simple projection.
> But from point of view of a client, it is a function which returns a tupl=
e.
What do you mean by "new data"?
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. Th=
at's
the key thing that makes the idea a useful construct for smart contacts, va=
lue
transfer/currency systems, etc.
> It might help if you describe a type of the condition function.
I did describe some seal authorization condition functions in my more recent
post; the key thing is you'd have some kind of "checksig" operator that che=
cks
a cryptographic signature.
> Some related work on UTXO-based smart contracts:
<snip>
Thanks for the links! Not at all surprising to me that there's a whole bunc=
h of
projects working along those same lines; it's the obvious way to build this
kind of stuff once you realise that the imperative, stateful, model isn't
viable.
--=20
https://petertodd.org 'peter'[:-1]@petertodd.org
--7iMSBzlTiPOCCT2k
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
iQEcBAEBCAAGBQJXa8P2AAoJEGOZARBE6K+yPUAH/2C3KC6q77XZrg6VgNQmB9Aq
O05soN3vcW7F3yoLbc0aBxQ1qWqSxaZqfvjgP8BK5IhCHtB3vEyP/cBOREb91U5n
ohZBz2FdRhgUAud3/AmTdTUd7N/JJZ+0wE2LCzCDaIaGwed+WOVkmByPgZFQKTe6
0B+pYNpv9lutaFpjB6QwaUWoZmb05TUKu0Cp7tehF4rWCg2bPKCd/qy/MsJb/2IX
d3LA7Zhny6wIyqL9Ti6G2/H3WfBKnzS/lcl5KJ7Cn6EPSDMlsdKasA779v/r0sQP
OKTps2VktuyQvdLHfawVBbioq40LGNoAAFqn8QgKdkBhkYa+EMHUAuBrnFBpvxI=
=VpAz
-----END PGP SIGNATURE-----
--7iMSBzlTiPOCCT2k--
|
