1

In Monero's early history, many transactions did not include any decoys. It was extremely clear that these outputs were spent.

Could Monero prune these known spent outputs?

Here is an example transaction from block 100000: 9c3c0086ef9aa98f370dac303c5dca109678bf95c9e4252e103dab16dce46fa8

It has a ringsize of 1 and 5 inputs:

2192316b89c7a120a57f24f1d87fac4ad1b39df70c861fe8ec16dad8e9038f61

b255b6c7ae1a10a4673320f32599cb972f1acc63f00abb02d331d6482fcea8c2

5dffd991c54e38a7374d6e54a0be5b6c6c98cae0fa00558b57a0c878f7f258e1

2c74d3187d7576f469928cead3a80e0c855784fea05d086aae3e83a72d56e25f

b41f74b78aaf1c07bda9926d630e06187b5ca1f90e00d3dd23d41f26cc10b598

Since all of these outputs are known to be spent in this transaction, is it possible to prune/delete all record of these outputs and their key images? Are there any significant downsides to doing so?

| improve this question | |
  • From where do you want to delete them? The blockchain itself? Could you elaborate? – el00ruobuob Aug 20 '18 at 5:26
1

In theory, yes. In practice, this might be a bit harder, depending on how the data is laid out in the on-disk blockchain database. Typically, for access speed, data is laid out in a fixed size vector, like this:

A B C D

Now if you want to prune C, you end up with

A B _ D

The space used by C is now unused, but you may not necessarily be able to reclaim that space easily. It is a similar problem to memory fragmentation. Somtimes you can compress this to

A B D

But if you have fast index based access to elements, you have to keep D at offset 4. So it depends on how the database is structured.

Nevertheless, some of that data can be pruned without such problems. You do lose the ability to query the database for those outputs, though.

In any case, you do not want to delete their key images, or they'd be spendable again.

| improve this answer | |
  • One thing I do know is that Monero uses LMDB, which is a key-value store database, not a fixed size vector. hyc could elaborate, but removing an entry will not be the issue at hand. Integrity and being able to prove ownership are surely the issues. Any pruning would rely on trust. – jtgrassie♦ Aug 20 '18 at 11:55
  • Technically, if you remove a small amount of data from a page, you might be able to slot an identical amount in the resulting hole. That amount of data is much smaller than a 4 kB page, so you don't free pages by doing this. It may be that this can be done, and the tree updated to point to the right places. I'm interested to know too. "Any pruning would truly on trust" is false though. If you do it dumbly, then sure, but only then. – user36303 Aug 20 '18 at 11:59
  • If you prune the public blockchain, then others have to trust your pruned db. That's what I'm getting at with the trust point. And LMDB, yes the tree is updated. hyc would need to elaborate further, however, it is definitely not like a fixed size vector as you have answered. – jtgrassie♦ Aug 20 '18 at 12:12
  • The outputs data is not used when others sync from you, so no. Some records are stored in the LMDB database as fixed size records indexed by an index, so it's not as clear cut (though it might be that the sub-page holes can be filled, as I suggested above). – user36303 Aug 20 '18 at 12:41
  • Fixed size record is not the same as fixed size vector. And the tree is updated. And if outputs were pruned, one can't verify the tx. – jtgrassie♦ Aug 20 '18 at 13:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.