Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id F164BC000B for ; Sun, 13 Feb 2022 10:06:51 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id DD43640339 for ; Sun, 13 Feb 2022 10:06:51 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.309 X-Spam-Level: X-Spam-Status: No, score=-1.309 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, RDNS_NONE=0.793, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Authentication-Results: smtp4.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=cock.li 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 luAR_UInXssp for ; Sun, 13 Feb 2022 10:06:49 +0000 (UTC) X-Greylist: delayed 00:10:17 by SQLgrey-1.8.0 Received: from mail.cock.li (unknown [37.120.193.123]) by smtp4.osuosl.org (Postfix) with ESMTPS id 3F4C84030C for ; Sun, 13 Feb 2022 10:06:49 +0000 (UTC) MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cock.li; s=mail; t=1644746182; bh=kEz43TpJG/bLmiYv+/wWL10yDJf10mzn703Phyt0aFM=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=CF7fmHvFtnHfv8srOTiFSp/4+comJIcCbBBbwdTPvCgl9j//6dnbYTNTZkwEuhO64 VvZg6rsPqJ/K1W8lsTkv6hF4oFUq4SqzU+R66owAe9UZuGE1P8Vt50vMTkdjq7avQ/ jxhmdG3iG0g3az5Zfp2oNoM1NKv3TXG9fFYsAlthiH7E/JV+4dPqDMDdBcN/zVP00o br9A51wDLCHMVaDj1jli5HP+Ajewoieztlq4PUZwfwJvYkmQAR5mt1WLradOMgEfcD f9gfwzEAdObas2CslazX7RBAAMGfRKTeMroAL75AkgyGcuZXvmVTM+WDZICXsRsmrG /fc8UvGxHY1Lw== Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Sun, 13 Feb 2022 09:56:21 +0000 From: yanmaani@cock.li To: Billy Tetrud , Bitcoin Protocol Discussion In-Reply-To: References: <86BAFB7B-5ECB-4790-A19B-6E296A063C59@voskuil.org> Message-ID: <021d90632551c45fa7093d503f1bd793@cock.li> X-Sender: yanmaani@cock.li User-Agent: Roundcube Webmail/1.3.17 X-Mailman-Approved-At: Sun, 13 Feb 2022 11:02:06 +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, 13 Feb 2022 10:06:52 -0000 On 2022-02-07 14:34, Billy Tetrud via bitcoin-dev wrote: > I do think that UTXO set size is something that will need to be > addressed at some point. I liked the idea of utreexo or some other > accumulator as the ultimate solution to this problem. What about using economic incentives to disincentivize the creation of new UTXOs? Currently, the fee is only charged per byte of space. What if you instead charged a fee of (bytes*byte_weight + net_utxos*utxo_weight)? For example, if utxo_weight=500, then a transaction that creates 2 new UTXOs would cost as if it were 1 KB in size. And a transaction that consolidated 2 UTXOs into one might even get a negative transaction fee (rebate). Technologically, you'd implement this by lowering the block size cap by max(0, net_utxos_created*utxo_weight). That would be a soft fork, if maybe a contentious one. It's probably also a good idea to limit it at 0, separate from consensus issues, because it means you're not guaranteed to get back whatever you put into it.