From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <ZmnSCPxj@protonmail.com> Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 55F80C000D for <bitcoin-dev@lists.linuxfoundation.org>; Fri, 8 Oct 2021 10:39:04 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 427B340382 for <bitcoin-dev@lists.linuxfoundation.org>; Fri, 8 Oct 2021 10:39:04 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.599 X-Spam-Level: X-Spam-Status: No, score=-1.599 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, FROM_LOCAL_NOVOWEL=0.5, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp4.osuosl.org (amavisd-new); dkim=pass (1024-bit key) header.d=protonmail.com Received: from smtp4.osuosl.org ([127.0.0.1]) by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vizlvBK6-pgE for <bitcoin-dev@lists.linuxfoundation.org>; Fri, 8 Oct 2021 10:39:01 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from mail-4318.protonmail.ch (mail-4318.protonmail.ch [185.70.43.18]) by smtp4.osuosl.org (Postfix) with ESMTPS id 4FC7D40370 for <bitcoin-dev@lists.linuxfoundation.org>; Fri, 8 Oct 2021 10:39:01 +0000 (UTC) Date: Fri, 08 Oct 2021 10:38:50 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail; t=1633689538; bh=wbu8kRxw7cd1opnOJMMAEos7GrIbZSIcNq30zRo45VI=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References:From; b=Y3ulqudFl8m5sYwLgefMYzLlk/YbXaesPmK+7NqaM364fgEmOv9GblzQnteyju4VO 9Hab0FYe6SXapFqjHpn+7e0307AqduIeITIX0IknCBN4iq4W5wVewoy8c2u0hQOVwf JMlGp4SF3TthBB77jsTKyisNO68XA5q9q2N2RKdc= To: shymaa arafat <shymaa.arafat@gmail.com>, Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> From: ZmnSCPxj <ZmnSCPxj@protonmail.com> Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com> Message-ID: <R7rqMyBitqJYz8vM37xnRj3OAvTfA4PDZJg3QzTVLNx3nLMeKRUxKNHu49ezhO80N7XeUweFOBeduAeoIUFvEFhjSTfwDltRH4kEdeQ9koE=@protonmail.com> In-Reply-To: <CAM98U8=NGcwoip5CVKrT2LNWjinCogxRjEYLxMtQ4-O+49wsLw@mail.gmail.com> References: <CAD5xwhjFBjvkMKev_6HFRuRGcZUi7WjO5d963GNXWN4n-06Pqg@mail.gmail.com> <20210808215101.wuaidu5ww63ajx6h@ganymede> <MkPutJpff5rqUxXFQrEyHZl6Iz0DfrJU_-BQD-y0El65GQFnj7igVfmWU79fPCtiFztUYl4ofzrqeaN0HFMB45YPErY9rYY7_h1XkuTMfvc=@wuille.net> <CAJowKgKt=yYdNOYYNsWh7FJ2EH7rz0bd2EjUjmyA=cA6k5cvUQ@mail.gmail.com> <BtaljKLqpe75GB6pHEPQMF6_L-hBaE0ZCBGaXrUfnHRYeEbCqFWZ12DaMRm5jEADceL3uPfCiL-WU9MOZJ_m54Zi3Pzu0vSFN3nQvuSKvBM=@protonmail.com> <CAM98U8nSOQ9HpdRLBdkcFAdToW=z7_EhnYisMb7F46ExmJkT-w@mail.gmail.com> <ZKZ4RR6uAv0mG8yFQyRkWDTFQ7JnsGVfLQcMTmsc5ui7MTJXuzMkVk5YQTniPuc4F_KRhn7BEZZHEK60IZYZYU9A1r-tbmfPTnIs0pOd7oU=@protonmail.com> <CAM98U8kKud-7QoJKYd5o245o8vGeUD7YD2OnXF_QeKaO33dSTw@mail.gmail.com> <MCYvJzqskIC56X-ylVCNgdaVk6SNnpCE6GgssXxK-znwwK4MoA41a2A-yNuCG8s99ll3h__YjCjBlP99A27Clbip-aYbF2ZwLpZ0SJT0j2U=@protonmail.com> <CAM98U8=NGcwoip5CVKrT2LNWjinCogxRjEYLxMtQ4-O+49wsLw@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: lightning-dev <lightning-dev@lists.linuxfoundation.org> 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 <bitcoin-dev.lists.linuxfoundation.org> List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> X-List-Received-Date: Fri, 08 Oct 2021 10:39:04 -0000 Good morning shymaa, > The suggested idea I was replying to is to make all dust TXs invalid by s= ome nodes. Is this supposed to be consensus change or not? Why "some" nodes and not all? I think the important bit is for full nodes. Non-full-nodes already work at reduced security; what is important is the s= ecurity-efficiency tradeoff. > I suggested a compromise by keeping them in secondary storage for full no= des, and in a separate Merkle Tree for bridge servers. > -In bridge servers they won't increase any worstcase, on the contrary thi= s 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 attack= er) > 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 t= hreshold (say more than 1 Tx in a block)=C2=A0=C2=A0 > -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. Assuming you meant "dust tx is considered invalid by all nodes". * Block has no dust sweep * With dust rejected: only non-dust outputs are accessed. * With dust in secondary storage: only non-dust outputs are accessed. * Block has some dust sweeps * With dust rejected: only non-dust outputs are accessed, block is reject= ed. * With dust in secondary storage: some data is loaded from secondary stor= age. * Block is composed of only dust sweeps * With dust rejected: only non-dust outputs are accessed, block is reject= ed. * With dust in secondary storage: significant increase in processing to l= oad large secondary storage in memory, So I fail to see how the proposal ever reduces processing compared to the i= dea of just outright making all dust txs invalid and rejecting the block. Perhaps you are trying to explain some other mechanism than what I understo= od? It is helpful to think in terms always of worst-case behavior when consider= ing resistance against attacks. > -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. But creation of dust is also as easy as sweeping them, and nothing really p= revents a block from *both* creating *and* sweeping dust, e.g. a block comp= osed of 1-input-1-output transactions, unless you want to describe some kin= d of restriction here? Such a degenerate block would hit your secondary storage double: one to rea= d, and one to overwrite and add new entries; if the storage is large then t= he index structure you use also is large and updates can be expensive there= as well. Again, I am looking solely at fullnode efficiency here, meaning all rules v= alidated and all transactions validated, not validating and simply acceptin= g some transactions as valid is a degradation of security from full validat= ion to SPV validation. Now of course in practice modern Bitcoin is hard to attack with *only* mini= ng hashpower as there are so many fullnodes that an SPV node would be easil= y able to find the "True" history of the chain. However, as I understand it that proporty of fullnodes protecting against a= ttacks on SPV nodes only exists due to fullnodes being cheap to keep online= ; if the cost of fullnodes in the **worst case** (***not*** average, please= stop talking about average case) increases then it may become feasible for= miners to attack SPV nodes. Regards, ZmnSCPxj