MIME-Version: 1.0
References: <c7bdbBVd0KmLFPUeYk0QUdni7tbDwJSj4HGLlEOkdPzIYzOyaX147HWJPKE-isTL267nQeJds8-rsKNyzRrBhucsZvwZcg5dZjQxDnbwxAA=@wuille.net>
 <86BAFB7B-5ECB-4790-A19B-6E296A063C59@voskuil.org>
In-Reply-To: <86BAFB7B-5ECB-4790-A19B-6E296A063C59@voskuil.org>
From: Billy Tetrud <billy.tetrud@gmail.com>
Date: Mon, 7 Feb 2022 08:34:42 -0600
Message-ID: <CAGpPWDbR5ctxf=HjLjqy0ADcQZMy9HQv-ZJfyFKmSBTntvkE9A@mail.gmail.com>
To: Eric Voskuil <eric@voskuil.org>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000f20c9705d76e80bc"
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
Precedence: list

--000000000000f20c9705d76e80bc
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

> every lightning network transaction adds one dust UTXO

Could you clarify what you mean here? What dust do lightning transactions
create?

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. In the mean time, I kind of agree with
Eric that outputs unlikely to be spent can easily be stored off ram and so
I wouldn't expect them to really be much of an issue to keep around. 3
million utxos is only like 100MB. If software could be improved to move
dust off ram, that sounds like a good win tho.

On Sun, Feb 6, 2022, 13:14 Eric Voskuil via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
>
> > On Feb 6, 2022, at 10:52, Pieter Wuille via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> > =EF=BB=BF
> >> 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 =E2=89=A4=
 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. Whil=
e
> 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 th=
em
> 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 usin=
g
> amount as a heuristic about what to keep and how long. IIRC, not even eve=
ry
> 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-standar=
d
> 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 miner=
s
> 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 f=
or
> 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
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--000000000000f20c9705d76e80bc
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"auto">&gt;=C2=A0<span style=3D"font-size:12.8px">every lightnin=
g network transaction adds one dust UTXO</span><div dir=3D"auto"><span styl=
e=3D"font-size:12.8px"><br></span></div><div dir=3D"auto"><span style=3D"fo=
nt-size:12.8px">Could you clarify what you mean here? What dust do lightnin=
g transactions create?</span></div><div dir=3D"auto"><span style=3D"font-si=
ze:12.8px"><br></span></div><div dir=3D"auto"><span style=3D"font-size:12.8=
px">I do think that UTXO set size is something that will need to be address=
ed at some point. I liked the idea of utreexo or some other accumulator as =
the ultimate solution to this problem. In the mean time, I kind of agree wi=
th Eric that outputs unlikely to be spent can easily be stored off ram and =
so I wouldn&#39;t expect them to really be much of an issue to keep around.=
 3 million utxos is only like 100MB. If software could be improved to move =
dust off ram, that sounds like a good win tho.</span></div></div><br><div c=
lass=3D"gmail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, Feb 6, 2=
022, 13:14 Eric Voskuil via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@l=
ists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wro=
te:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex"><br>
<br>
&gt; On Feb 6, 2022, at 10:52, Pieter Wuille via bitcoin-dev &lt;<a href=3D=
"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" rel=3D"nor=
eferrer">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<br>
&gt; <br>
&gt; =EF=BB=BF<br>
&gt;&gt; Dear Bitcoin Developers,<br>
&gt; <br>
&gt;&gt; -When I contacted bitInfoCharts to divide the first interval of ad=
dresses, they kindly did divided to 3 intervals. From here:<br>
&gt;&gt; <a href=3D"https://bitinfocharts.com/top-100-richest-bitcoin-addre=
sses.html" rel=3D"noreferrer noreferrer" target=3D"_blank">https://bitinfoc=
harts.com/top-100-richest-bitcoin-addresses.html</a><br>
&gt;&gt; -You can see that there are more than 3.1m addresses holding =E2=
=89=A4 0.000001 BTC (1000 Sat) with total value of 14.9BTC; an average of 4=
73 Sat per address.<br>
&gt; <br>
&gt;&gt; -Therefore, a simple solution would be to follow the difficulty ad=
justment idea and just delete all those<br>
&gt; <br>
&gt; That would be a soft-fork, and arguably could be considered theft. Whi=
le commonly (but non universally) implemented standardness rules may preven=
t 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 o=
utputs may not even remain uneconomical to spend. Therefore, dropping them =
entirely from the UTXO set is potentially destroying potentially useful fun=
ds people own.<br>
&gt; <br>
&gt;&gt; or at least remove them to secondary storage<br>
&gt; <br>
&gt; 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 ever=
y full node implementation even uses a UTXO model.<br>
<br>
You recall correctly. Libbitcoin has never used a UTXO store. A full node h=
as no logical need for an additional store of outputs, as transactions alre=
ady contain them, and a full node requires all of them, spent or otherwise.=
<br>
<br>
The hand-wringing over UTXO set size does not apply to full nodes, it is re=
levant only to pruning. Given linear worst case growth, even that is ultima=
tely a non-issue.<br>
<br>
&gt;&gt; for Archiving with extra cost to get them back, along with non-sta=
ndard UTXOs and Burned ones (at least for publicly known, published, burn a=
ddresses).<br>
&gt; <br>
&gt; Do you mean this as a standardness rule, or a consensus rule?<br>
&gt; <br>
&gt; * As a standardness rule it&#39;s feasible, but it makes policy (furth=
er) deviate from economically rational behavior. There is no reason for min=
ers to require a higher price for spending such outputs.<br>
&gt; * As a consensus rule, I expect something like this to be very controv=
ersial. There are currently no rules that demand any minimal fee for anythi=
ng, and given uncertainly over how fee levels could evolve in the future, i=
t&#39;s unclear what those rules, if any, should be.<br>
&gt; <br>
&gt; Cheers,<br>
&gt; <br>
&gt; --<br>
&gt; Pieter<br>
&gt; <br>
&gt; _______________________________________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bl=
ank" rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a><br>
&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfou=
ndation.org/mailman/listinfo/bitcoin-dev</a><br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank" =
rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer" target=3D"_blank">https://lists.linuxfoundati=
on.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000f20c9705d76e80bc--