public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Eric Voskuil <eric@voskuil.org>
To: Pieter Wuille <bitcoin-dev@wuille.net>,
	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, 6 Feb 2022 11:14:28 -0800	[thread overview]
Message-ID: <86BAFB7B-5ECB-4790-A19B-6E296A063C59@voskuil.org> (raw)
In-Reply-To: <c7bdbBVd0KmLFPUeYk0QUdni7tbDwJSj4HGLlEOkdPzIYzOyaX147HWJPKE-isTL267nQeJds8-rsKNyzRrBhucsZvwZcg5dZjQxDnbwxAA=@wuille.net>



> On Feb 6, 2022, at 10:52, Pieter Wuille via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> 
> 
>> Dear Bitcoin Developers,
> 
>> -When I contacted bitInfoCharts to divide the first interval of addresses, they kindly did divided to 3 intervals. From here:
>> https://bitinfocharts.com/top-100-richest-bitcoin-addresses.html
>> -You can see that there are more than 3.1m addresses holding ≤ 0.000001 BTC (1000 Sat) with total value of 14.9BTC; an average of 473 Sat per address.
> 
>> -Therefore, a simple solution would be to follow the difficulty adjustment idea and just delete all those
> 
> That would be a soft-fork, and arguably could be considered theft. While commonly (but non universally) implemented standardness rules may prevent spending them currently, there is no requirement that such a rule remain in place. Depending on how feerate economics work out in the future, such outputs may not even remain uneconomical to spend. Therefore, dropping them entirely from the UTXO set is potentially destroying potentially useful funds people own.
> 
>> or at least remove them to secondary storage
> 
> Commonly adopted Bitcoin full nodes already have two levels of storage effectively (disk and in-RAM cache). It may be useful to investigate using amount as a heuristic about what to keep and how long. IIRC, not even every full node implementation even uses a UTXO model.

You recall correctly. Libbitcoin has never used a UTXO store. A full node has no logical need for an additional store of outputs, as transactions already contain them, and a full node requires all of them, spent or otherwise.

The hand-wringing over UTXO set size does not apply to full nodes, it is relevant only to pruning. Given linear worst case growth, even that is ultimately a non-issue.

>> for Archiving with extra cost to get them back, along with non-standard UTXOs and Burned ones (at least for publicly known, published, burn addresses).
> 
> Do you mean this as a standardness rule, or a consensus rule?
> 
> * As a standardness rule it's feasible, but it makes policy (further) deviate from economically rational behavior. There is no reason for miners to require a higher price for spending such outputs.
> * As a consensus rule, I expect something like this to be very controversial. There are currently no rules that demand any minimal fee for anything, and given uncertainly over how fee levels could evolve in the future, it's unclear what those rules, if any, should be.
> 
> Cheers,
> 
> --
> Pieter
> 
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


  reply	other threads:[~2022-02-06 19:14 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 [this message]
2022-02-07 14:34     ` Billy Tetrud
2022-02-07 16:51       ` shymaa arafat
2022-02-13  9:56       ` yanmaani
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=86BAFB7B-5ECB-4790-A19B-6E296A063C59@voskuil.org \
    --to=eric@voskuil.org \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=bitcoin-dev@wuille.net \
    /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