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 890E8955 for ; Tue, 21 Jun 2016 22:42:34 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail148111.authsmtp.net (outmail148111.authsmtp.net [62.13.148.111]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id C1F3E19E for ; Tue, 21 Jun 2016 22:42:33 +0000 (UTC) Received: from mail-c232.authsmtp.com (mail-c232.authsmtp.com [62.13.128.232]) by punt22.authsmtp.com (8.14.2/8.14.2/) with ESMTP id u5LMgTVU060422; Tue, 21 Jun 2016 23:42:29 +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 u5LMgQ2Y079334 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Jun 2016 23:42:27 +0100 (BST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by petertodd.org (Postfix) with ESMTPSA id 1036840116; Tue, 21 Jun 2016 22:40:24 +0000 (UTC) Received: by localhost (Postfix, from userid 1000) id 2B26520217; Tue, 21 Jun 2016 18:42:25 -0400 (EDT) Date: Tue, 21 Jun 2016 18:42:25 -0400 From: Peter Todd To: "zaki@manian.org" , Bitcoin Protocol Discussion Message-ID: <20160621224225.GA10422@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="17pEHd4RhPHOinZp" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Server-Quench: 6e58fb3e-3801-11e6-829e-00151795d556 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aQdMdAMUEkAaAgsB AmAbWVdeVF97W2Q7 bghPaBtcak9QXgdq T0pMXVMcUQAUfEtg BHceVRBxdAEIcXd5 YwhkC3VTChZ5IFt+ Sk5VCGwHMGF9YGIW 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: Tue, 21 Jun 2016 22:42:34 -0000 --17pEHd4RhPHOinZp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 20, 2016 at 04:21:39PM +0000, zaki--- via bitcoin-dev wrote: > Hi Peter, >=20 > I didn't entirely understand the process of transaction linearization. >=20 > What I see is a potential process where when the miner assembles the bloc= k, > he strips all but one sigscript per tx. The selection of which sigscript > is retained is determined by the random oracle. Is this is primary benef= it > you are suggesting? >=20 > It appears to me that blocks still need to contain a list of full TX Input > and Tx Outputs with your approach. Some of the description seems to > indicate that there are opportunities to elide further data but it's > unclear to me how. I think you've misunderstood what I'm proposing. The state machine approach= I described doesn't necessarily require blocks or even miners to exist at all. Rather, it assumes that a single-use seal primitive is available, and a ran= dom beacon primitive for tx linearization, and then builds a system on top of t= hose primitives. Transaction data - the proofs that certain states have been rea= ched in the system - does not need to be broadcast publicly; if Alice wants to convince Bob that she has given him money, the only person who needs that transaction (and transactions prior to it in the tx history) is Bob. So as to your question about miners assembling blocks, and what blocks cont= ain: there doesn't need to be blocks at all! Transaction history linearization is something your wallet would do for you. --=20 https://petertodd.org 'peter'[:-1]@petertodd.org --17pEHd4RhPHOinZp Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJXacLNAAoJEGOZARBE6K+yw1MH/1FS1UBuVoh3ngSUHS8ydXJO WREqKpfuhxv7enolSIgzp7wcxySKjM5wk2I7bumZu9dQXpcFM7krf+rWnMCWGO8M QRS+th9diOVO2vHQs1XoOdwhOo/ZUqXxikwBCy9sW5pXKR+NBhP6KKPDi3Bfdfoa wp7153JKvGhvwnAf+NuyYPMZlt7s9pfPGf5ROXn0oiTZk4dd33I+PRncXnHKGSu1 XaSN9SOq9yQZlIorTIJ+InGT5jVkH9CllWT+MmvyD90s4rPUKi6Ym8AtztNccvB1 znLOyEcnIKos544O7vPD1GEwKyoqKbD3dp+EZUA/QctqsPuGiJBfvd06jcax6VY= =qOXD -----END PGP SIGNATURE----- --17pEHd4RhPHOinZp--