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)
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Building Blocks of the State Machine Approach to
 Consensus
Precedence: list


--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--