Peter Todd [ARCHIVE] on Nostr: 📅 Original date posted:2013-03-12 📝 Original message:On Sat, Mar 09, 2013 at ...
📅 Original date posted:2013-03-12
📝 Original message: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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130312/10b7fde5/attachment.sig>;
📝 Original message: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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130312/10b7fde5/attachment.sig>;