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 9EA399BA for ; Thu, 23 Feb 2017 01:15:11 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail149058.authsmtp.co.uk (outmail149058.authsmtp.co.uk [62.13.149.58]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id BCF441C9 for ; Thu, 23 Feb 2017 01:15:10 +0000 (UTC) Received: from mail-c232.authsmtp.com (mail-c232.authsmtp.com [62.13.128.232]) by punt20.authsmtp.com (8.14.2/8.14.2/) with ESMTP id v1N1F9Y8035469 for ; Thu, 23 Feb 2017 01:15:09 GMT 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 v1N1F7NQ037890 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 23 Feb 2017 01:15:08 GMT Received: from [127.0.0.1] (localhost [127.0.0.1]) by petertodd.org (Postfix) with ESMTPSA id 4964140123 for ; Thu, 23 Feb 2017 01:15:07 +0000 (UTC) Received: by localhost (Postfix, from userid 1000) id 81ED820245; Wed, 22 Feb 2017 20:15:06 -0500 (EST) Date: Wed, 22 Feb 2017 20:15:06 -0500 From: Peter Todd To: bitcoin-dev@lists.linuxfoundation.org Message-ID: <20170223011506.GC905@savin.petertodd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="rQ2U398070+RC21q" Content-Disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-Server-Quench: 84365579-f965-11e6-829f-00151795d556 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVJwpGK10IU0Fd P1hyKltILEZaQVBf Ri5dBBEKBAw1ADwr dVUTOktfYVU4Cld1 UkhIRUJSFQ9pBBYB DlAbUAd3aQROfWBx Z0Z9XHVEXQo8dDh8 NEkqdG0FYm9paC4c U0lYOQtQcwVPexhM dwZ2UnYQYGRSYGdo RV49emhpZGgGd3UI TlxQc0Q7CWwGAiIx XVgnOA9nMUALRiMy Mx0hLDYB 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: [bitcoin-dev] A Better MMR Definition 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 Feb 2017 01:15:11 -0000 --rQ2U398070+RC21q Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Reposting something that came up recently in a private discussion with some academics: Concretely, let's define a prunable MMR with the following grammar. This definition is an improvement on whats in the python-proofmarshal by committ= ing to the number of items in the tree implicitly; an obvious max-log2(n)-sized proof-of-tree-size can be obtained by following the right-most nodes: Maybe(T) :=3D UNPRUNED | PRUNED FullNode(0) :=3D FullNode(n) :=3D PartialNode(0) :=3D SOME | NONE PartialNode(n) :=3D MMR :=3D FULL | PARTIAL Basically we define it in four parts. First we define Maybe(T) to represent pruned and unpruned (hash only) data. Secondly we define full nodes within = 2^n sized trees. Third we define partial nodes. And finally we define the MMR itself as being either a full or partial node. First of all, with pruning we can define a rule that if any operation (other than checking commitment hashes) attempts to access pruned data, it should immediately fail. In particular, no operation should be able to determine if data is or isn't pruned. Equally, note how an implementation can keep track= of what data was accessed during any given operation, and prune the rest, which means a proof is just the parts of the data structure accessed during one or more operations. With that, notice how proving the soundness of the proofs becomes trivial: = if validation is deterministic, it is obviously impossible to construct two different proofs that prove contradictory statements, because a proof is si= mply part of the data structure itself. Contradiction would imply that the two proofs are different, but that's easily rejected by simply checking the has= h of the data. --=20 https://petertodd.org 'peter'[:-1]@petertodd.org --rQ2U398070+RC21q Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJYrjeWAAoJECSBQD2l8JH7yJkH/2TvMGw/B6pEhka8mKmZyYUk z6DNnnss+Bc9Cy0Euxm5T+sWLlP/h+G4mdGsq0l1yn2MKEceVvOJIoirl/qrcbZ0 c5xRnPd/L6BUFmy+1gTo+HfW2i3l4X1RaU+v8m7t8clwSvqb1DSbumPr3H/AqZoh xUNFpLQCyLPCH5fEfgpGGRFy8qVm6jSHR9R5dGrqdLwk7Hc1Ip6m55a+8J6EMlHp AtB9MZF2nMM0gpcjPdfA8UiNDyTWHVcw2wUqUtQ1Tbj4NP4DgR3ZvFxRYudV+1HJ A1SATEb9DleYPjHuyL127hXyuilk3+1IukOeYcOrMhiGf/aerDTan3VXPQ1VD1I= =sb/5 -----END PGP SIGNATURE----- --rQ2U398070+RC21q--