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 A6485941 for ; Thu, 23 Jun 2016 11:21:27 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail149095.authsmtp.com (outmail149095.authsmtp.com [62.13.149.95]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id C7B2AE0 for ; Thu, 23 Jun 2016 11:21:26 +0000 (UTC) Received: from mail-c232.authsmtp.com (mail-c232.authsmtp.com [62.13.128.232]) by punt24.authsmtp.com (8.14.2/8.14.2/) with ESMTP id u5NBLNlp053697; Thu, 23 Jun 2016 12:21:23 +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 u5NBLL2O019587 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 23 Jun 2016 12:21:22 +0100 (BST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by petertodd.org (Postfix) with ESMTPSA id B75FB4010C; Thu, 23 Jun 2016 11:19:16 +0000 (UTC) Received: by localhost (Postfix, from userid 1000) id 1C34C20217; Thu, 23 Jun 2016 07:21:16 -0400 (EDT) Date: Thu, 23 Jun 2016 07:21:16 -0400 From: Peter Todd To: Police Terror , Bitcoin Protocol Discussion Message-ID: <20160623112116.GA19556@fedora-21-dvm> References: <20160620085649.GA29964@fedora-21-dvm> <5767EEFE.7060103@dyne.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="IS0zKkzwUGydFO0o" Content-Disposition: inline In-Reply-To: <5767EEFE.7060103@dyne.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Server-Quench: 9d860f68-3934-11e6-829e-00151795d556 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aAdMdAEUEkAaAgsB AmAbWlZeUlx7W2E7 bghPaBtcak9QXgdq T0pMXVMcUQAWc2B9 BGEeUxB3fwIIcHdy ZQhrCnhdXBJ8fVt+ S01QCGwHMGF9YGIW 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 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:21:27 -0000 --IS0zKkzwUGydFO0o Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 20, 2016 at 01:26:22PM +0000, Police Terror via bitcoin-dev wro= te: > Bitcoin could embed a lisp interpreter such as Scheme, reverse engineer > the current protocol into lisp (inside C++), run this alternative engine > alongside the current one as an option for some years (only for fine > tuning) then eventually fade this lisp written validation code instead > of the current one. You know, I'm kinda regretting not making it sufficiently clear that Dex is= n't Lisp... It may look like it with all the braces, but expressions in it are evaluated without any global state (they can be evaluated in parallel) and = I've got a lot of work ahead of me in type safety. > Scheme is small and minimal, and embeds easily in C++. This could be a > better option than the libconsensus library - validation in a functional > scripting language. I'd be surprised if you could find a scheme interpreter that's sufficiently well defined to be suitable for that; starting with an existing one and whipping it into shape would very likely be more work than starting from scratch. =20 > That doesn't mean people can't program the validation code in other > languages (maybe they'd want to optimize), but this code would be the > standard. Yeah, in general I'd expect most of these systems to be layered to a degree; after all even in something like MAST you need tooling to manage the fact t= hat the opcodes that end up public, on-chain, are only a subset of the script. > I wouldn't be so quick to deride good engineering over systematic > provable systems for all domains. Bitcoin being written in C++ is not a > defect. It's actually a strong language for what it does. Especially > when used correctly (which is not often and takes years to master). It's probably the best of a lot of bad alternatives... We use C++ not becau= se it's good, but because there's no other option. In particular, we have enormous cost and risk in moving to other things due= to consensus, so making use of other languages is very difficult; my work with dex/proofchains does not have that constraint. > With the seals idea- am I understand this correctly?: Every transaction > has a number (essentially the index starting from 0 upwards) depending > on where it is in the blockchain. >=20 > Then there is an array (probably an on disk array mapping transaction > indexes to hashes). Each hash entry in the array must be unique (the > hashes) otherwise the transaction will be denied. This is a great idea > to solve transaction hash collisions and simple to implement. No, I think you've very much misunderstood things. The abstract notion of a single-use seal doesn't even need global consensus on anything to implement= ; it does not require transactions to have "indexes" --=20 https://petertodd.org 'peter'[:-1]@petertodd.org --IS0zKkzwUGydFO0o Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJXa8YpAAoJEGOZARBE6K+yVaQH/32hYdD0dDq6A4sWyD1zNRg7 NWa2wZw3c/pLg2GlF/YnuBjEiGcmT19xWXWerdcqjQriul9FGVV3j6FPmcMQ3nyP nlb74VzZh9V6pT7VPAOQMV/j2wTBdK0/zBTzGP/XKo0opCIt95KUjt+i/qx3EToS PtEmNZawFf6dfE3P+WY44HLQOx+6BGr/UsXIqOcd8+VpSldXI7Pcntvc6Otip9Q6 Diwv5ddBX+GpEHxcZSaHlY/McSYRMQTpA1eUBx+X4JoM1GLtAh4rmf2+LlozszsT ji7oZwrg54eRBFuWDGhf6BuvnyWQH6rvdxYlndq3/LPSIaJnju9WvvUIfxUa0gA= =CS+5 -----END PGP SIGNATURE----- --IS0zKkzwUGydFO0o--