From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 5040E486 for ; 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 ; 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 To: Alex Mizrahi Message-ID: <20160623111152.GB19360@fedora-21-dvm> References: <20160620085649.GA29964@fedora-21-dvm> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="7iMSBzlTiPOCCT2k" Content-Disposition: inline In-Reply-To: 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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: 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--