public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: yanmaani@cock.li
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: [bitcoin-dev] Block weight penalty for UTXO set growth
Date: Tue, 20 Apr 2021 01:22:34 +0000	[thread overview]
Message-ID: <42775695100e48eb5884d38e60b70957@cock.li> (raw)

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?


             reply	other threads:[~2021-04-20  1:22 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-04-20  1:22 yanmaani [this message]
2021-04-21  4:59 [bitcoin-dev] Block weight penalty for UTXO set growth Prayank

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=42775695100e48eb5884d38e60b70957@cock.li \
    --to=yanmaani@cock.li \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox