Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id CAD38C000B for ; Sun, 6 Feb 2022 17:39:47 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id ABD6F813D7 for ; Sun, 6 Feb 2022 17:39:47 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.1 X-Spam-Level: X-Spam-Status: No, score=-2.1 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp1.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=wuille.net Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IMILqBRFhh6t for ; Sun, 6 Feb 2022 17:39:45 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from mail-4323.proton.ch (mail-4323.proton.ch [185.70.43.23]) by smtp1.osuosl.org (Postfix) with ESMTPS id AC805812FF for ; Sun, 6 Feb 2022 17:39:45 +0000 (UTC) Date: Sun, 06 Feb 2022 17:39:41 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wuille.net; s=protonmail; t=1644169182; bh=gLFuXk1nVP33SDTC6g93PlutzQ2nvIcaYgyEYI87Z1k=; h=Date:To:From:Reply-To:Subject:Message-ID:In-Reply-To:References: From:To:Cc; b=cbM1AyrUFcI8+WDaPBnhcdR0tVf7jo2qpMOflV68QCd9g4sRMpWOPXbpOP7To71Rr 25ve1tbsbs4rY40oMSaS/SdCZSPJLGt1VfDFep5rTPx+SoTWEt1Damtdh5KUjk0AV6 zhQHUA1yyKw2kxsJ9T7HEG745kXn3Qcqm9dHncwWde4lUku+itfRpo85z07CuSbLkv leoUuwWIh9hDBpJaKsU1fksjdCqimAumaQEsnrLp2StX1rmLsLf05+JxH8WK0BuBi/ ar9UuCmCoRO4t4CGu4H8bmOzrL4uC6aZbu+fEZn6V6B+maCLMwGFkBB00xLBk5ZxJT Optl98ZcdquqA== To: shymaa arafat , Bitcoin Protocol Discussion From: Pieter Wuille Reply-To: Pieter Wuille Message-ID: In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Sun, 06 Feb 2022 18:52:20 +0000 Subject: Re: [bitcoin-dev] A suggestion to periodically destroy (or remove to secondary storage for Archiving reasons) dust, Non-standard UTXOs, and also detected burn 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: Sun, 06 Feb 2022 17:39:47 -0000 > Dear Bitcoin Developers, > -When I contacted bitInfoCharts to divide the first interval of addresses= , they kindly did divided to 3 intervals. From here: > https://bitinfocharts.com/top-100-richest-bitcoin-addresses.html > -You can see that there are more than 3.1m addresses holding =E2=89=A4 0.= 000001 BTC (1000 Sat) with total value of 14.9BTC; an average of 473 Sat pe= r address. > -Therefore, a simple solution would be to follow the difficulty adjustmen= t idea and just delete all those That would be a soft-fork, and arguably could be considered theft. While co= mmonly (but non universally) implemented standardness rules may prevent spe= nding them currently, there is no requirement that such a rule remain in pl= ace. Depending on how feerate economics work out in the future, such output= s may not even remain uneconomical to spend. Therefore, dropping them entir= ely from the UTXO set is potentially destroying potentially useful funds pe= ople own. > or at least remove them to secondary storage Commonly adopted Bitcoin full nodes already have two levels of storage effe= ctively (disk and in-RAM cache). It may be useful to investigate using amou= nt as a heuristic about what to keep and how long. IIRC, not even every ful= l node implementation even uses a UTXO model. > for Archiving with extra cost to get them back, along with non-standard U= TXOs and Burned ones (at least for publicly known, published, burn addresse= s). Do you mean this as a standardness rule, or a consensus rule? * As a standardness rule it's feasible, but it makes policy (further) devia= te from economically rational behavior. There is no reason for miners to re= quire a higher price for spending such outputs. * As a consensus rule, I expect something like this to be very controversia= l. There are currently no rules that demand any minimal fee for anything, a= nd given uncertainly over how fee levels could evolve in the future, it's u= nclear what those rules, if any, should be. Cheers, -- Pieter