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?
next 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 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$(echo .)li \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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