From: yanmaani@cock.li
To: Billy Tetrud <billy.tetrud@gmail.com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>
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
Date: Sun, 13 Feb 2022 09:56:21 +0000 [thread overview]
Message-ID: <021d90632551c45fa7093d503f1bd793@cock.li> (raw)
In-Reply-To: <CAGpPWDbR5ctxf=HjLjqy0ADcQZMy9HQv-ZJfyFKmSBTntvkE9A@mail.gmail.com>
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.
next prev parent reply other threads:[~2022-02-13 10:06 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-02-06 12:41 [bitcoin-dev] A suggestion to periodically destroy (or remove to secondary storage for Archiving reasons) dust, Non-standard UTXOs, and also detected burn shymaa arafat
2022-02-06 17:39 ` Pieter Wuille
2022-02-06 19:14 ` Eric Voskuil
2022-02-07 14:34 ` Billy Tetrud
2022-02-07 16:51 ` shymaa arafat
2022-02-13 9:56 ` yanmaani [this message]
2022-02-13 13:11 ` shymaa arafat
[not found] ` <382073c28af1ec54827093003cbec2cc@willtech.com.au>
[not found] ` <CAM98U8mJvYcBur01Z32TS4RYW+jMDCVQAUtrg5KXF+50d0zirA@mail.gmail.com>
2022-02-13 5:19 ` shymaa arafat
2022-02-18 3:36 ` ZmnSCPxj
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=021d90632551c45fa7093d503f1bd793@cock.li \
--to=yanmaani@cock.li \
--cc=billy.tetrud@gmail.com \
--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