From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [IPv6:2605:bc80:3010::137]) by lists.linuxfoundation.org (Postfix) with ESMTP id 55F80C000D for ; 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 ; 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 ; 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 ; 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 , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: References: <20210808215101.wuaidu5ww63ajx6h@ganymede> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: lightning-dev 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 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