Removing the Dust Limit



Summary:

In this conversation, there is a discussion about making all dust transactions invalid by some nodes. The suggestion is to keep them in secondary storage for full nodes and in a separate Merkle Tree for bridge servers. This would enhance the performance even if slightly and be fetched rarely either by a dust sweeping action or a malicious attacker. A threshold could be set to upload the whole dust partition, then keep them there for a while but as a separate partition to exclude them from any caching mechanism after that block. However, this proposal raises concerns about efficiency and security-efficiency tradeoff. The proposal fails to reduce processing compared to the idea of outright making all dust txs invalid and rejecting the block. When considering resistance against attacks, it is helpful to think in terms of worst-case behavior. It is also mentioned that creation of dust is as easy as sweeping them, and nothing prevents a block from creating and sweeping dust. Therefore, such a degenerate block would hit the secondary storage double: one to read and one to overwrite and add new entries; if the storage is large, then the index structure used can also be large, and updates can be expensive there as well. It is emphasized that the cost of fullnodes in the worst case (not average) should not increase; otherwise, it may become feasible for miners to attack SPV nodes.


Updated on: 2023-06-03T05:21:06.952507+00:00