The suggested idea I was replying to is to make all dust TXs invalid by some nodes. I suggested a compromise by keeping them in secondary storage for full nodes, and in a separate Merkle Tree for bridge servers. -In bridge servers they won't increase any worstcase, on the contrary this will enhance the performance even if slightly. -In full nodes, and since they will usually appear in clusters, they will be fetched rarely (either by a dust sweeping action, or a malicious attacker) In both cases as a batch -To not exhaust the node with DoS(as the reply mentioned)one may think of uploading the whole dust partition if they were called more than certain threshold (say more than 1 Tx in a block) -and then keep them there for "a while", but as a separate partition too to exclude them from any caching mechanism after that block. -The "while" could be a tuned parameter. -Take care that the more dust is sweeped, the less dust to remain in the UTXO set; as users are already much dis-incentivised to create more. . Thanks for allowing the reply
On Thu, Oct 7, 2021, 16:43 ZmnSCPxj <zmnsc...@protonmail.com> wrote: > > > > I don't know what brings up sorting here, unless as an example. > > Yes, it is an example: quicksort is bad for network-facing applications > because its ***worst-case behavior*** is bad. > Bitcoin is a network-facing application, and similarly, ***worst-case > behavior*** being bad is something that would strongly discourage > particular approaches. > Your proposal risks bad ***worst-case behavior***. > > > Anyways, I was comparing to rejecting them completely, not to keeping > them in one set. In addition, those dust sweep Transactions will probably > be a dust sweep and thus contain so many inputs which "maybe" makes 1-one > disk visit to fetch all their hashes at once, 2-from a smaller subset with > max size 5-10% the UTXO set, justifiable. > > Do not consider the ***average case*** where a block is composed of only a > few dust sweep transactions and most transactions are normal, > non-dust-sweep transactions. > > Instead, consider the ***worst case*** where ***all*** transactions in a > block are dust sweep transactions, because that is what attackers will use. > > Regards, > ZmnSCPxj >
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
