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 1UQFf1-0006l0-Sh for bitcoin-development@lists.sourceforge.net; Thu, 11 Apr 2013 11:27:23 +0000 Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.148.113 as permitted sender) client-ip=62.13.148.113; envelope-from=pete@petertodd.org; helo=outmail148113.authsmtp.com; Received: from outmail148113.authsmtp.com ([62.13.148.113]) by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1UQFez-0008Lo-W7 for bitcoin-development@lists.sourceforge.net; Thu, 11 Apr 2013 11:27:23 +0000 Received: from mail-c226.authsmtp.com (mail-c226.authsmtp.com [62.13.128.226]) by punt10.authsmtp.com (8.14.2/8.14.2/Kp) with ESMTP id r3BBREmG025662; Thu, 11 Apr 2013 12:27:14 +0100 (BST) 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 r3BBR9bo088110 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 11 Apr 2013 12:27:11 +0100 (BST) Date: Thu, 11 Apr 2013 07:27:08 -0400 From: Peter Todd To: Jorge =?iso-8859-1?Q?Tim=F3n?= Message-ID: <20130411112708.GA1006@savin> References: <20130410030301.GA9921@savin> <20130410030831.GA12447@savin> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="3V7upXqbjpZ4EhLz" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: c135728a-a29a-11e2-98a9-0025907ec6c5 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aQdMdwMUGUUGAgsB AmUbWlZeUlp7WGE7 bAxPbAVDY01GQQRq WVdMSlVNFUsqAm5z ZBdMDRl6fwRHeDBx ZE9kVj4IXUd/ckR1 E1MFF2RXeGZhPWIC WUgJfh5UcAFPdx9C PwN5B3ZDAzANdhES HhM4ODE3eDlSNilR RRkIIFQOdA43GXZp EA0eE3B/SnRSXz8+ eElEYgtLAVofdxVl CAw/VFQEBBYIAAxC BUhXERhVLkUIcDE3 ChlTUkMpETtqXTdb HwEzFUgdSmkFRzZW QRsSYUZTDAh4B3wA dDZQMGUQCEQoIks2 P2wkNgUsBxw5TXIA X-Authentic-SMTP: 61633532353630.1020: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. -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: 1UQFez-0008Lo-W7 Cc: Bitcoin Development Subject: Re: [Bitcoin-development] =?utf-8?q?To_prevent_arbitrary_data_storage?= =?utf-8?q?_in_txouts_=E2=80=94_The_Ultimate_Solution?= 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: Thu, 11 Apr 2013 11:27:24 -0000 --3V7upXqbjpZ4EhLz Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 10, 2013 at 05:58:10PM +0200, Jorge Tim=F3n wrote: > On 4/10/13, Peter Todd wrote: > > Oh, and while we're at it, long-term (hard-fork) it'd be good to change > > the tx hash algorithm to extend the merkle tree into the txouts/txins > > itself, which means that to prove a given txout exists you only need to > > provide it, rather than the full tx. > > > > Currently pruning can't prune a whole tx until every output is spent. > > Make that change and we can prune tx's bit by bit, and still be able to > > serve nodes requesting proof of their UTXO without making life difficult > > for anyone trying to spent old UTXO's. The idea is also part of UTXO > > proof stuff anyway. >=20 > I thought about this before, I like the idea very much. > Would such a fork be controversial for anyone? > Would anyone oppose to this for some reason I'm missing? You mean https://bitcointalk.org/index.php?topic=3D137933.0 ? I would oppose it, and I wrote the above proposal. The code required to implement UTXO fraud proofs is more complex than the entire Bitcoin code base; obviously that much new fork-critical code opens up huge technical risks. As an example, can you think of how UTXO fraud proofs can cause an arbitrarily deep re-org? --=20 'peter'[:-1]@petertodd.org --3V7upXqbjpZ4EhLz Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJRZp4MAAoJEH+rEUJn5PoEfpAH/10lKhcSzuBUMdtFJwzh5l6z O65sAp86p6LsjsrIJlCUAV74KHUb17czFhtfObRRYxxE07INSBWF0dGLqbdf8hOK vd9jnFHGHIocW41pD4Z9PAZne4Oe2nCri3Yg6tnOcuX5sH4UCyhoIyFamaoMz3Ux 7KYddTrIX4+Ga5M+pZ6LECT/0XE7J0w1JQ1AUYISxuxOm2HfmcXRZX0k8ctGrIsb t0OV3jkJZH8FQ7AOzhdUC1omJnxkXfsly3Nyc0Dv8uGzhvULKvl+kHII0sK6AUBu YSFvkE7f9naw8ROsBzBOx2qeP9R2SJMigeTmzeCar3xxxudBR1ayEC+OLNQkiDY= =hm7o -----END PGP SIGNATURE----- --3V7upXqbjpZ4EhLz--