Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 4E47BB5E for ; Tue, 16 May 2017 11:01:12 +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 ESMTPS id D808B1A8 for ; Tue, 16 May 2017 11:01:10 +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 v4GB184s092415; Tue, 16 May 2017 12:01:08 +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 v4GB16S9091227 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 16 May 2017 12:01:07 +0100 (BST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by petertodd.org (Postfix) with ESMTPSA id E7EF34009E; Tue, 16 May 2017 11:01:05 +0000 (UTC) Received: by localhost (Postfix, from userid 1000) id 1AC652048A; Tue, 16 May 2017 07:01:04 -0400 (EDT) Date: Tue, 16 May 2017 07:01:04 -0400 From: Peter Todd To: Gregory Maxwell Message-ID: <20170516110104.GA5564@fedora-23-dvm> References: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="r5Pyd7+fXNt84Ff3" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-Server-Quench: f6a7d3b1-3a26-11e7-829f-00151795d556 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aQdMdwQUFVQNAgsB AmEbWlZeUFx7WWQ7 bghPaBtcak9QXgdq T0pMXVMcUgEfcx0H ZRceWxhwdQIIeX52 YkIsCHYKWxB5J0dg QR9WE3AHZDJndWgd WRZFdwNVdQJNdxoR b1V5GhFYa3VsNCMk FAgyOXU9MCtqYB5S RgUMK11afHo7OXYn SgxKHTw0HUAeLwAA 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 Dev Subject: Re: [bitcoin-dev] Rolling UTXO set hashes 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, 16 May 2017 11:01:12 -0000 --r5Pyd7+fXNt84Ff3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, May 15, 2017 at 11:59:58PM +0000, Gregory Maxwell via bitcoin-dev w= rote: > On Mon, May 15, 2017 at 11:04 PM, ZmnSCPxj via bitcoin-dev > wrote: > > transactions is in the header, which would let lite nodes download a UT= XO > > set from any full node and verify it by verifying only block headers > > starting from genesis. >=20 > Ya, lite nodes with UTXO sets are one of the the oldest observed > advantages of a commitment to the UTXO data: >=20 > https://bitcointalk.org/index.php?topic=3D21995.0 >=20 > But it requires a commitment. And for most of the arguments for those > you really want compact membership proofs. The recent rise in > interest in full block lite clients (for privacy reasons), perhaps > complements the membership proofless usage. >=20 > Pieter describes some uses for doing something like this without a > commitment. In my view, it's more interesting to first gain > experience with an operation without committing to it (which is a > consensus change and requires more care and consideration, which are > easier if people have implementation experience). To be clear, *none* of the previous (U)TXO commitment schemes require *mine= rs* to participate in generating a commitment. While that was previously though= t to be true by many, I've seen no counter-arguments to the argument I published= I few months ago(1) that (U)TXO commitments did not require a soft-fork to deploy. 1) "[bitcoin-dev] TXO commitments do not need a soft-fork to be useful", Peter Todd, Feb 23 2017, https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/01= 3591.html --=20 https://petertodd.org 'peter'[:-1]@petertodd.org --r5Pyd7+fXNt84Ff3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJZGtvqAAoJECSBQD2l8JH7LXEH/1wRFPDPKs9Y4ieJ/J/b4lx9 Ou7TpxgqsETa9/3OYlr/9CL4b5QVzP8GBIKMtzIQkOxs9FgdF+sr5k1oEGj+1JVP iVNAt/IW9E6Sd951o4MLd3HSk46F0LVdR8Ru47lh+fuSeAE1lZerU7nwys87fNSL X9R0O0Upp04HE4G7dCpDuHr/ighC8hUzezyUtxqU8nB1/hNDbUWXNihRupvVgZGP bRdhHzcPvy911GNneneM3a325uQy6r7tg49NYZL/uCXXCnHEBc8JQgKNFZKRMpsZ lRtMVOzxvdemiYOcvKDLgP4hzH0AOcIdbly5ITuW/zeJZYecki/dbYs7Z80OAvg= =ry2T -----END PGP SIGNATURE----- --r5Pyd7+fXNt84Ff3--