š
Original date posted:2021-04-19
š Original message: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?
yanmaani at cock.li [ARCHIVE] /
npub13aā¦9uc29
2023-06-07 22:51:54
in reply to nevent1qā¦0gt3
Author Public Key
npub13adulxazm6ydmpm6vuhk9xjudfa7h0k687j3xfzjrcpcv0v0uz2qz9uc29Published at
2023-06-07 22:51:54Event JSON
{
"id": "9527294e49432c15457a53b89309978a6cfd91cbeba3796d3888d84cbe19314c",
"pubkey": "8f5bcf9ba2de88dd877a672f629a5c6a7bebbeda3fa51324521e03863d8fe094",
"created_at": 1686178314,
"kind": 1,
"tags": [
[
"e",
"2bd37379fda53d57b0f3e799f5b07f960048ad0a7d90e5f26a4cef4fc16a17c4",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "š
Original date posted:2021-04-19\nš Original message:Bitcoin presently suffers from unconstrained UTXO set growth. It would \nbe possible to disincentivize this and incentivize consolidating UTXOs \nby adding a block weight penalty for UTXO creation, and bonus for UTXO \ndestruction:\n\n* For each block, calculate the net change in UTXOs. If all the \ntransactions in a block consume 6,256 inputs and create 6,512 outputs, \nthe net change is +256.\n* For each block, change the weight limit by -penalty * delta\n* For example, if the penalty is 10 vB/UTXO, that block would be 10*256 \n= 2560 vB smaller. At a fee of 150 sat/vB, this would reduce the \npotential transaction fees by 0.00384000 BTC ($230 at current prices)\n\n(Alternatively, it would also be possible to make the penalty in coin, \nwhich would require miners to fail to claim/burn an equivalent amount of \nsubsidy.)\n\nA problem is that it is not possible to increase the weight limit (or \nthe block reward). I can see three possible solutions to this:\n\n1) Let any excess be wasted. Miners can only use consolidated UTXOs to \noffset new ones.\n2) Decrease the weight limit slightly (i.e. by 1%), so that miners have \nan incentive to consolidate UTXOs at least up to that limit.\n3) Increase the weight limit, but only if miners consolidate enough \nUTXOs.\n\nAside from the obvious issues with the third option (it would be a \nhardfork), another problem is that this would make it harder for low-fee \ntransactions to get confirmed; on blocks with bad fees, miners might \ninstead opt to create a load of dust UTXOs, so they can destroy them on \nblocks with very high fees to free up capacity. On the other hand, this \nmight be seen as a feature rather than a bug, since it would allow block \nsizes to vary by demand, a bit like VBR vs. CBR in audio compression.\n\nThoughts? Has this been discussed before?",
"sig": "7a77232c7c2c61fd9f24fcc5835374ec8106844651b6bcd09b754d203bcf751d7d15d5a35069415df5097ce927a5ab7e0539c5b400a50892297d6a1dc60c45f6"
}