📅 Original date posted:2013-03-11
📝 Original message:> 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.
Mike Hearn [ARCHIVE] /
npub17t…4qgyd
2023-06-07 11:35:27
in reply to nevent1q…fxq0
Author Public Key
npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgydPublished at
2023-06-07 11:35:27Event JSON
{
"id": "d959e73b8076b6a769faedc66bc1cea0882eb85bca35fb7ad289107311fc9bce",
"pubkey": "f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2",
"created_at": 1686137727,
"kind": 1,
"tags": [
[
"e",
"ac08c1a6c33933128b534f22efee5bb15c3746d60deefafe520b9c4fff7b646d",
"",
"root"
],
[
"e",
"c003a07270c209417ab03cdd2b81e20361a5b7c437941aa356976d862cb5e0f5",
"",
"reply"
],
[
"p",
"cfba5f423d25750803554a7cc7d141c492ed9f37a777de29d3a4d030d5c88c58"
]
],
"content": "📅 Original date posted:2013-03-11\n📝 Original message:\u003e This would be bloating UTXO data at a speed of 52 GB/year. That's a very\n\u003e big memory leak. And this is just the unspendable outputs.\n\nFirstly, the UTXO set is a LevelDB, it's not stored in memory. Outputs\nthat never get spent are not in the working set by definition, after a\nwhile they just end up in the bottom levels and hardly ever get\naccessed. If need be we can always help LevelDB out a bit by moving\noutputs that we suspect are unlikely to get spent into a separate\ndatabase, but I doubt it's needed.\n\nSecondly, if an output can be proven unspendable it can be pruned\nimmediately. We already reached consensus on adding some standard\ntemplate using OP_RETURN that results in insta-pruning. So people who\nwant to create unspendable outputs can do so with the only side-effect\nbeing long term chain storage. It would be effectively \"free\" to\npruning nodes.\n\nSo the issue is not really with unspendable outputs but with low-value\nspendable outputs. Wallets with lots of tiny outputs end up generating\nlarge transactions that take a long time to verify, in situations\nwhere the network redlines those transactions would end up at the\nbottom of the priority queue and might take longer to confirm. So\nwallet apps already have incentives to try and find a good balance in\noutput sizes and defragment themselves if their average output gets\ntoo low in value, eg, by send-to-self transactions at night.",
"sig": "2a5cf8b8a33e8d8ff8aab8aafd98d7e6f00bbb72f7e4b10690eca9dbccd2c1b9dbc58c37de60d789d36ef2f8819d361104517f463fa100d5d74cd75ef59c5a62"
}