Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [140.211.166.136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 0A3ABC000D; Fri, 8 Oct 2021 07:45:13 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id D20056089E; Fri, 8 Oct 2021 07:45:12 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp3.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nzukpQGsTq-i; Fri, 8 Oct 2021 07:45:12 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-pf1-x430.google.com (mail-pf1-x430.google.com [IPv6:2607:f8b0:4864:20::430]) by smtp3.osuosl.org (Postfix) with ESMTPS id 1AE7B60890; Fri, 8 Oct 2021 07:45:12 +0000 (UTC) Received: by mail-pf1-x430.google.com with SMTP id m26so7501020pff.3; Fri, 08 Oct 2021 00:45:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=FV0mFFASWOCI2QsGfi2pnrrGc/QqkLslqps8Hmvo/xo=; b=DR8rnv+Kz9YhPn56Ve1uoodthJehBN1bpqjqHrTOoo0tHlBf0J/YhAMfFcEUEjKifU eZz91QBERSzJter1DVUe+d2O5+lcQm/EHhQeEzXTd8R0s397xMeE7XduBKlT6aJ5DtxS 63BqTW78dgm+DS9Cc7DMMJEPmRXl+8ROnUYpqMRNRkuPHD4Sya8HG3a6Bts9E6yVefj5 Xlwh1ExBJOINSmhqXoGThEMYpZqM9puN3YCh8Df/qcOCOCqmOyPcIpVRC7RK5p9+/Qvn L2c0AfpmvmUvCfifO80ETQ3/elmH5uP0NuZWcsJPHriEk6854ntETPt8jooYUbSbmOHl ebBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=FV0mFFASWOCI2QsGfi2pnrrGc/QqkLslqps8Hmvo/xo=; b=sJwgjT7VKmEqtv+HhUM3Bkbxv7f8LZknPy1UaAE1NDPvBXMwKPisOXV9ZU1JS47yid prvIf13moKXKlie2Z3YK9VnfkZrIIoBWnno1sbdHiqPIOFDIwQesQyvJsLYdjHWwgn6/ Qno3HHUYkgHeLeFe7NHHaxO9D1ZkNBzNszgmwouhyJAKRaFXgffo0vcoRYcgtB5AUZ5Y 600DYp9dEV9Nl4HRBFS4yKaomAIwYmSYUD4jf2Hz5zcdgF15tTSH9oWjlV2y7WLRoFjn 9VHXxxfW3oycJWzKFvU81jO4ncFnZBiHEXnHDMPMgFdqbx242IHFgbtWsY35hawxa5P9 dtIQ== X-Gm-Message-State: AOAM533XRQWe887itlbCfFzgCwvtLYN2uovnQdIEnOV9lPmzD9xBYvBf HWf24O8XBlNG1V426p6ZcAzDT5rG3xsVbiZ8wuxtsDM6 X-Google-Smtp-Source: ABdhPJzcvMsK4THINwzAOOtxrBaW2ofaZVwh4+bXRtL1E9/8Dn5/wANznERKld436qRL3MRg35WbuulBp56ptJ6nhKE= X-Received: by 2002:a62:8f53:0:b0:44c:5d10:9378 with SMTP id n80-20020a628f53000000b0044c5d109378mr8561667pfd.19.1633679111205; Fri, 08 Oct 2021 00:45:11 -0700 (PDT) MIME-Version: 1.0 References: <20210808215101.wuaidu5ww63ajx6h@ganymede> In-Reply-To: From: shymaa arafat Date: Fri, 8 Oct 2021 09:44:59 +0200 Message-ID: To: lightning-dev , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="00000000000019b70005cdd28f2e" X-Mailman-Approved-At: Fri, 08 Oct 2021 07:55:07 +0000 Subject: Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Oct 2021 07:45:13 -0000 --00000000000019b70005cdd28f2e Content-Type: text/plain; charset="UTF-8" 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 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 > --00000000000019b70005cdd28f2e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
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 s= lightly.
-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 repl= y mentioned)one may think of uploading the whole dust partition if they wer= e called more than certain threshold (say more than 1 Tx in a block)=C2=A0= =C2=A0
-and then keep them there for "a while&q= uot;, but as a separate partition too to exclude them from any caching mech= anism 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 T= hu, Oct 7, 2021, 16:43 ZmnSCPxj <ZmnSCPxj@protonmail.com> wr= ote:


> 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 bec= ause its ***worst-case behavior*** is bad.
Bitcoin is a network-facing application, and similarly, ***worst-case behav= ior*** being bad is something that would strongly discourage particular app= roaches.
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 b= e a dust sweep and thus contain so many inputs which "maybe" make= s 1-one disk visit=C2=A0 to fetch all their hashes at once, 2-from a smalle= r 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-swee= p transactions.

Instead, consider the ***worst case*** where ***all*** transactions in a bl= ock are dust sweep transactions, because that is what attackers will use.
Regards,
ZmnSCPxj
--00000000000019b70005cdd28f2e--