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 95453C000B for ; Tue, 20 Apr 2021 01:22:48 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp4.osuosl.org (Postfix) with ESMTP id 6F6B1402CA for ; Tue, 20 Apr 2021 01:22:48 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: 0.59 X-Spam-Level: X-Spam-Status: No, score=0.59 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 b69ILQZeRBKU for ; Tue, 20 Apr 2021 01:22:44 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from mail.cock.li (unknown [37.120.193.123]) by smtp4.osuosl.org (Postfix) with ESMTPS id D88BC40254 for ; Tue, 20 Apr 2021 01:22:43 +0000 (UTC) MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cock.li; s=mail; t=1618881754; bh=F8mbpoWsrg69xtGpeRNG/DWGHIv5yR13Iqvq5SuJVUY=; h=Date:From:To:Subject:From; b=re60BnbRC6KlAhgzgv0j8jP+oqGShQsgdYtuSZlmgTOS7lXYPTpb3HPn2IbrFzxVD ChElh+ZKs+XTvZmt/otIpN8IkEsSyoHJiwX/T4U/XcnHwOoc36RmQ3Q01v11ScqU+P UfgCpdzNLm1LjrzJhMKXQZ+jBPkTQ3wusvn+oT3+4LQiy/xfsXvQaeFx5Fp7rHoywk 0ea+tq4/t2SuJXA1ioIQ8y9TNPhkDj1IsDSq2pk/HTBGU66W2RfwR+rP3xDSNHDeRf pUC5XfTLx5OEEpb2QNVdaItDWCUuclZI1UQXzlDaK+5LnJZ5zZClRE7ZjgqEz7tK3M DbGwEWXABS6PA== Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Date: Tue, 20 Apr 2021 01:22:34 +0000 From: yanmaani@cock.li To: Bitcoin Protocol Discussion Message-ID: <42775695100e48eb5884d38e60b70957@cock.li> X-Sender: yanmaani@cock.li User-Agent: Roundcube Webmail/1.3.15 X-Mailman-Approved-At: Tue, 20 Apr 2021 02:28:26 +0000 Subject: [bitcoin-dev] Block weight penalty for UTXO set growth 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: Tue, 20 Apr 2021 01:22:48 -0000 Bitcoin presently suffers from unconstrained UTXO set growth. It would be possible to disincentivize this and incentivize consolidating UTXOs by adding a block weight penalty for UTXO creation, and bonus for UTXO destruction: * For each block, calculate the net change in UTXOs. If all the transactions in a block consume 6,256 inputs and create 6,512 outputs, the net change is +256. * For each block, change the weight limit by -penalty * delta * For example, if the penalty is 10 vB/UTXO, that block would be 10*256 = 2560 vB smaller. At a fee of 150 sat/vB, this would reduce the potential transaction fees by 0.00384000 BTC ($230 at current prices) (Alternatively, it would also be possible to make the penalty in coin, which would require miners to fail to claim/burn an equivalent amount of subsidy.) A problem is that it is not possible to increase the weight limit (or the block reward). I can see three possible solutions to this: 1) Let any excess be wasted. Miners can only use consolidated UTXOs to offset new ones. 2) Decrease the weight limit slightly (i.e. by 1%), so that miners have an incentive to consolidate UTXOs at least up to that limit. 3) Increase the weight limit, but only if miners consolidate enough UTXOs. Aside from the obvious issues with the third option (it would be a hardfork), another problem is that this would make it harder for low-fee transactions to get confirmed; on blocks with bad fees, miners might instead opt to create a load of dust UTXOs, so they can destroy them on blocks with very high fees to free up capacity. On the other hand, this might be seen as a feature rather than a bug, since it would allow block sizes to vary by demand, a bit like VBR vs. CBR in audio compression. Thoughts? Has this been discussed before?