📅 Original date posted:2021-10-08
📝 Original message:
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 <ZmnSCPxj at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211008/91bd7b81/attachment.html>;
shymaa arafat [ARCHIVE] /
npub1l7…hgr56
2023-06-09 13:03:55
in reply to nevent1q…zjml
Author Public Key
npub1l7ldumxqplqv4h9lfkwpwp3lapj3xnla2hnf8h8mm9da3qlv6shqfhgr56Published at
2023-06-09 13:03:55Event JSON
{
"id": "a591a49afcae353103cde47d1616d10d0e6e57ab16b93dd3297abeead061ae63",
"pubkey": "ffbede6cc00fc0cadcbf4d9c17063fe865134ffd55e693dcfbd95bd883ecd42e",
"created_at": 1686315835,
"kind": 1,
"tags": [
[
"e",
"051e2fa4433ba1f2b07138a1681c2429af218c1f2f601189fc0f95041ae2ca20",
"",
"root"
],
[
"e",
"b5946267923ae2181c4edff799650e0bb0835b75b67db6ae68fdc8b56c90a5c3",
"",
"reply"
],
[
"p",
"4505072744a9d3e490af9262bfe38e6ee5338a77177b565b6b37730b63a7b861"
]
],
"content": "📅 Original date posted:2021-10-08\n📝 Original message:\nThe suggested idea I was replying to is to make all dust TXs invalid by\nsome nodes. I suggested a compromise by keeping them in secondary storage\nfor full nodes, and in a separate Merkle Tree for bridge servers.\n-In bridge servers they won't increase any worstcase, on the contrary this\nwill enhance the performance even if slightly.\n-In full nodes, and since they will usually appear in clusters, they will\nbe fetched rarely (either by a dust sweeping action, or a malicious\nattacker)\nIn both cases as a batch\n-To not exhaust the node with DoS(as the reply mentioned)one may think of\nuploading the whole dust partition if they were called more than certain\nthreshold (say more than 1 Tx in a block)\n-and then keep them there for \"a while\", but as a separate partition too to\nexclude them from any caching mechanism after that block.\n-The \"while\" could be a tuned parameter.\n-Take care that the more dust is sweeped, the less dust to remain in the\nUTXO set; as users are already much dis-incentivised to create more.\n.\nThanks for allowing the reply\n\nOn Thu, Oct 7, 2021, 16:43 ZmnSCPxj \u003cZmnSCPxj at protonmail.com\u003e wrote:\n\n\u003e\n\u003e\n\u003e \u003e I don't know what brings up sorting here, unless as an example.\n\u003e\n\u003e Yes, it is an example: quicksort is bad for network-facing applications\n\u003e because its ***worst-case behavior*** is bad.\n\u003e Bitcoin is a network-facing application, and similarly, ***worst-case\n\u003e behavior*** being bad is something that would strongly discourage\n\u003e particular approaches.\n\u003e Your proposal risks bad ***worst-case behavior***.\n\u003e\n\u003e \u003e Anyways, I was comparing to rejecting them completely, not to keeping\n\u003e them in one set. In addition, those dust sweep Transactions will probably\n\u003e be a dust sweep and thus contain so many inputs which \"maybe\" makes 1-one\n\u003e disk visit to fetch all their hashes at once, 2-from a smaller subset with\n\u003e max size 5-10% the UTXO set, justifiable.\n\u003e\n\u003e Do not consider the ***average case*** where a block is composed of only a\n\u003e few dust sweep transactions and most transactions are normal,\n\u003e non-dust-sweep transactions.\n\u003e\n\u003e Instead, consider the ***worst case*** where ***all*** transactions in a\n\u003e block are dust sweep transactions, because that is what attackers will use.\n\u003e\n\u003e Regards,\n\u003e ZmnSCPxj\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211008/91bd7b81/attachment.html\u003e",
"sig": "5869589e147a904c790b13ea920bcee004ed982948aff7cb7c98423bf267cc95600bbbdc55b906328a1db39cca0110a3032f5d48914f1533c55de310a1498e4f"
}