From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1UFJyB-0004Tu-G5 for bitcoin-development@lists.sourceforge.net; Tue, 12 Mar 2013 07:49:59 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.149.82 as permitted sender) client-ip=62.13.149.82; envelope-from=pete@petertodd.org; helo=outmail149082.authsmtp.co.uk; Received: from outmail149082.authsmtp.co.uk ([62.13.149.82]) by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1UFJy9-0003R8-Kl for bitcoin-development@lists.sourceforge.net; Tue, 12 Mar 2013 07:49:59 +0000 Received: from mail-c233.authsmtp.com (mail-c233.authsmtp.com [62.13.128.233]) by punt14.authsmtp.com (8.14.2/8.14.2/) with ESMTP id r2C7nph4075362 for ; Tue, 12 Mar 2013 07:49:51 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 r2C7nkc1041633 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO) for ; Tue, 12 Mar 2013 07:49:48 GMT Date: Tue, 12 Mar 2013 03:49:45 -0400 From: Peter Todd To: Bitcoin Dev Message-ID: <20130312074945.GB25250@savin> References: <20130310043155.GA20020@savin> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="/NkBOFFp2J2Af1nK" Content-Disposition: inline In-Reply-To: <20130310043155.GA20020@savin> User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: 6a650243-8ae9-11e2-a49c-0025907707a1 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVJwpGK10IU0Fd P1hXKl1LNVAaWXld WiVPGEoXDxgzCjYj NEgGOBsDNw4AXgd1 LRkLXVBSFQZ4ARsL AhcUVhA8cANYeX5u ZEFqQHFbVVt/fUFi QwAWFx4BOzwzaWAb UUZbdE1ReQpIMBkU bFV/VncOfG1WM3N9 RlY+ZXU4YWRUbXwN GFxcdQ1NGRkCRygG SkJKLh8uAUYCRiN2 IxE4J1obBEMcNFkH eXElXlkbMhkdQhBY EkpKBihcJlIIQ2IW MTN9FUUEHTRBQCBa agAA X-Authentic-SMTP: 61633532353630.1021: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: 1UFJy9-0003R8-Kl Subject: Re: [Bitcoin-development] Blocking uneconomical UTXO creation 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: Tue, 12 Mar 2013 07:49:59 -0000 --/NkBOFFp2J2Af1nK Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Mar 09, 2013 at 11:31:55PM -0500, Peter Todd wrote: > As discussed endlessly data in the UTXO set is more costly, especially > in the long run, than transaction data itself. The fee system is per KB > in a block, and thus doesn't properly capture the long-term costs of > UTXO creation. There's been a lot of discussion about this issue, and many people have asked that Bitcoin not arbitrarily block interesting potential uses of provably unspendable txouts for data applications, and similarly spendable txouts representing assets. I've changed my hardline position and now think we should support all that stuff. However, there is one remaining class of txout not yet talked about, unspendable but not provably so txouts. For instance we could make the following a standard transaction type: scriptPubKey: OP_HASH160 <20 byte digest> OP_EQUALVERIFY scriptSig: Of course, usually the 20 byte digest would be picked randomly, but it might not be, and thus all validating nodes will always have a copy of the data. With the 10KB limit on script sizes you can fit 9974 bytes of data per transaction output with very little waste. A good application is timestamping, with the advantage over coinbase/merkle tree systems in that you don't have to wait until your timestamp confirms, or even store the timestamp at all. Another application, quite possible with large block sizes and hence cheap or free transactions, is secure data backups. In particular such a service, perhaps called Google Chain Storage, can offer the unique guarantee that you can know you're data is secure by simply performing a successful Bitcoin transaction. --=20 'peter'[:-1]@petertodd.org --/NkBOFFp2J2Af1nK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) iQEcBAEBAgAGBQJRPt4ZAAoJEH+rEUJn5PoErgQH/jkLGkwax88uzFZEmkrTDPHi Pmr6djAVzI7DYBSzVllnIzoOUZatGG+AjdNOjP3fiuYMbazMdL0cZta2FAR5Qahk P6R45zx+Wb5kEg7uFuL6HfxbFr4xFEjEAnLEdW1MN1/YvThpuHXuzL8hREwWp7u/ UmxoK3Y56v/kJu6kAI/+10l1XKYFBiT8zzvKIM9+SaCmyPGNkW+DieSyJ0lTIce2 AwmUIHogoOLNbhSjL/IlxzGYetVMD1wxa8CtZI8GvLAbf5xBiWRsM5oEf2DZfW7b tYOd32SegaWe6QWzMWCWGuPyGeuHwX0e0WGo5YtQsWQINjeKIBWrKwtxkWm386o= =X1eu -----END PGP SIGNATURE----- --/NkBOFFp2J2Af1nK--