From: Mike Hearn <mike@plan99•net>
To: "Tadas Varanavičius" <tadas.varanavicius@gmail•com>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Blocking uneconomical UTXO creation
Date: Mon, 11 Mar 2013 23:19:07 +0100 [thread overview]
Message-ID: <CANEZrP1tYTDf6k76=jcBL+10MpCgemV2TP=wZiRuA02vhUP78A@mail.gmail.com> (raw)
In-Reply-To: <513E2BC6.2050102@gmail.com>
> This would be bloating UTXO data at a speed of 52 GB/year. That's a very
> big memory leak. And this is just the unspendable outputs.
Firstly, the UTXO set is a LevelDB, it's not stored in memory. Outputs
that never get spent are not in the working set by definition, after a
while they just end up in the bottom levels and hardly ever get
accessed. If need be we can always help LevelDB out a bit by moving
outputs that we suspect are unlikely to get spent into a separate
database, but I doubt it's needed.
Secondly, if an output can be proven unspendable it can be pruned
immediately. We already reached consensus on adding some standard
template using OP_RETURN that results in insta-pruning. So people who
want to create unspendable outputs can do so with the only side-effect
being long term chain storage. It would be effectively "free" to
pruning nodes.
So the issue is not really with unspendable outputs but with low-value
spendable outputs. Wallets with lots of tiny outputs end up generating
large transactions that take a long time to verify, in situations
where the network redlines those transactions would end up at the
bottom of the priority queue and might take longer to confirm. So
wallet apps already have incentives to try and find a good balance in
output sizes and defragment themselves if their average output gets
too low in value, eg, by send-to-self transactions at night.
next prev parent reply other threads:[~2013-03-11 22:19 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 [this message]
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
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='CANEZrP1tYTDf6k76=jcBL+10MpCgemV2TP=wZiRuA02vhUP78A@mail.gmail.com' \
--to=mike@plan99$(echo .)net \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=tadas.varanavicius@gmail$(echo .)com \
/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