From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VtzxY-0005cD-2B for bitcoin-development@lists.sourceforge.net; Fri, 20 Dec 2013 13:17:44 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.149.112 as permitted sender) client-ip=62.13.149.112; envelope-from=pete@petertodd.org; helo=outmail149112.authsmtp.co.uk; Received: from outmail149112.authsmtp.co.uk ([62.13.149.112]) by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1VtzxW-0000iu-T7 for bitcoin-development@lists.sourceforge.net; Fri, 20 Dec 2013 13:17:44 +0000 Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235]) by punt17.authsmtp.com (8.14.2/8.14.2/) with ESMTP id rBKDHamZ072225; Fri, 20 Dec 2013 13:17:36 GMT Received: from savin (76-10-178-109.dsl.teksavvy.com [76.10.178.109]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id rBKDHWBY005551 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Fri, 20 Dec 2013 13:17:34 GMT Date: Fri, 20 Dec 2013 08:17:31 -0500 From: Peter Todd To: Mark Friedenbach Message-ID: <20131220131731.GC21148@savin> References: <52B3A1C8.5000005@monetize.io> <52B42842.6000306@monetize.io> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="aT9PWwzfKXlsBJM1" Content-Disposition: inline In-Reply-To: <52B42842.6000306@monetize.io> User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: 174cc1de-6979-11e3-b802-002590a15da7 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aAdMdAIUHFAXAgsB AmUbWldeUVp7WmY7 bAxPbAVDY01GQQRq WVdMSlVNFUsqc2d1 fnlsOxlycgBDeTBx ZkJmVz5aW0ApJkcp F1NSHGoPeGZhPWMC AkhYdR5UcAFPdx8U a1UrBXRDAzANdhES HhM4ODE3eDlSNilR RRkIIFQOdA4hPwZ0 XwoFBTI0FElXDwwu MxwrLEIdF08NP0l6 KUEsV1MIewMIBwBF dwAA X-Authentic-SMTP: 61633532353630.1023:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 76.10.178.109/587 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Score: -1.5 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: petertodd.org] -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain -0.0 SPF_PASS SPF: sender matches SPF record X-Headers-End: 1VtzxW-0000iu-T7 Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] BIP proposal: Authenticated prefix trees X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Dec 2013 13:17:44 -0000 --aT9PWwzfKXlsBJM1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Dec 20, 2013 at 03:21:38AM -0800, Mark Friedenbach wrote: > Hi Jeremy, Let's give a preview of the application-oriented BIPs I > mentioned: >=20 > Stateless validation and mining involves prefixing transaction and > block messages with proofs of their UTxO state changes. These are the > "operational proofs" I describe in the draft, and they work on prefix > trees whose root hashes committed to the coinbase in a soft-fork > upgrade of the validation rules. >=20 > "Ultimate blockchain compression" involves consensus over an address > index, which can be queried over the p2p network by lightweight nodes. > The structure of the index is an authenticated prefix tree, and the > results of such a query is an an inclusion proof. I've thought about this for awhile and come to the conclusion that UTXO commitments are a really bad idea. I myself wanted to see them implemented about a year ago for fidelity bonded banks, but I've changed my mind and I hope you do too. They force miners and every full node with SPV clients to store the entire UTXO set in perpetuity. This is bad by itself, but then they make it even worse by making Bitcoin really useful and convenient to use as a decentralized database; UTXO commitments make it easy and convenient to implement systems like Namecoin on top of Bitcoin, yet we don't have the UTXO expiration that might make such uses reasonable. Right now the UTXO set is reasonable small - ~300MB - but that can and will change if we make it an attractive way to store data. UTXO commitments do exactly that. You're also *not* giving users what they actually want: the transactions associated with their wallets. Even though Electrum could easily work via a pure UTXO database they implemented transaction lookup instead; Electrum servers cough up every transaction associated with a user's wallet. If you're going to do that, it's just as easy to do per-block lookup trees which don't force the UTXO set to be stored. There's also a more subtle issue: the security model of UTXO commitments sucks. It encourages wallets to essentially trust single confirmations because it's unlikely that nodes will want to store the multiple copies of the UTXO set required to provide proof of multiple confirmations. Basically the issue is when you start your wallet you get a proof of UTXO set for the most recent block; that's just one confirmation. To get more confirmations you have to wait for subsequent blocks, checking the set on each block. Per block indexes on the other hand naturally lead wallets to count confirmations properly. IMO you should take this technology to Namecoin instead. For them the fast lookups are probably worth the trade-offs, and they expire domains so the total set size doesn't grow unbounded. --=20 'peter'[:-1]@petertodd.org 00000000000000028fd077fb1e33e942e3e875aa29cec134fed89d650242c577 --aT9PWwzfKXlsBJM1 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQGqBAEBCACVBQJStENqXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDBkZDMyODJiMGI0YTI3MGJhNzFiOGIzOTUzZWRjZGIxZGYx ZTIwZTNkZGJiZGI0NTUvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkfvCvgf3RrS2GPta002e5KHFYlvVw93X P/+3GWw1QHoCGYzuS3b3Nh1CbAVSm08PCR6/8Q5HibgFiD4jZ+bI4BpkRWtbrFie ULjrLKP967IFkQ1xLWtZmtqmIhF6B1RnTlDy9nrWcJo+cs7cgFpVjbDgCN+AgsND r/vxz3Z76710Xd68HUqkc49oGzxq13fDmVz5VfY6UraFd8M7JyfsYow/2XNAMxxw LtawORozSeWLmvj9oJUvrKEnCwAsCZiY7+22js9giLlGIJuHaIFftABCDkCt3/pt LUdz6158ANqQjOwoVsBRV/qbrfcRc/4SMBcLuEt1OeB6YkfrOOTezMoqMDXq =+h8r -----END PGP SIGNATURE----- --aT9PWwzfKXlsBJM1--