From: Peter Todd <pete@petertodd•org>
To: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Blocking uneconomical UTXO creation
Date: Tue, 12 Mar 2013 03:49:45 -0400 [thread overview]
Message-ID: <20130312074945.GB25250@savin> (raw)
In-Reply-To: <20130310043155.GA20020@savin>
[-- Attachment #1: Type: text/plain, Size: 1721 bytes --]
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 <data>
scriptSig: <data>
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.
--
'peter'[:-1]@petertodd.org
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]
next prev parent reply other threads:[~2013-03-12 7:49 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-03-10 4:31 Peter Todd
2013-03-11 11:01 ` Jorge Timón
2013-03-11 15:36 ` Gavin Andresen
2013-03-11 16:45 ` Jorge Timón
2013-03-11 16:46 ` Jorge Timón
2013-03-11 16:54 ` Mike Hearn
2013-03-11 17:08 ` Jorge Timón
2013-03-11 18:17 ` Benjamin Lindner
2013-03-11 18:59 ` Mark Friedenbach
2013-03-11 18:59 ` Jorge Timón
2013-03-11 19:08 ` Tadas Varanavičius
2013-03-11 22:19 ` Mike Hearn
2013-03-11 22:25 ` Tadas Varanavičius
2013-03-11 22:39 ` Mike Hearn
2013-03-11 23:26 ` Tadas Varanavičius
2013-03-11 17:18 ` Jeff Garzik
2013-03-11 20:08 ` Rune Kjær Svendsen
2013-03-11 20:36 ` Michael Gronager
2013-03-11 21:01 ` Gregory Maxwell
2013-03-11 21:15 ` Michael Gronager
2013-03-12 7:49 ` Peter Todd [this message]
2013-03-13 5:31 ` Stephen Pair
2013-03-13 9:20 ` Jorge Timón
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130312074945.GB25250@savin \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox