MIME-Version: 1.0
References: <c7bdbBVd0KmLFPUeYk0QUdni7tbDwJSj4HGLlEOkdPzIYzOyaX147HWJPKE-isTL267nQeJds8-rsKNyzRrBhucsZvwZcg5dZjQxDnbwxAA=@wuille.net>
 <86BAFB7B-5ECB-4790-A19B-6E296A063C59@voskuil.org>
 <CAGpPWDbR5ctxf=HjLjqy0ADcQZMy9HQv-ZJfyFKmSBTntvkE9A@mail.gmail.com>
In-Reply-To: <CAGpPWDbR5ctxf=HjLjqy0ADcQZMy9HQv-ZJfyFKmSBTntvkE9A@mail.gmail.com>
From: shymaa arafat <shymaa.arafat@gmail.com>
Date: Mon, 7 Feb 2022 18:51:54 +0200
Message-ID: <CAM98U8mT8SFfd4dPfFBbofrJQsXv+GX6Q5-Xb2y0hgqR5XMGSA@mail.gmail.com>
To: Billy Tetrud <billy.tetrud@gmail.com>, 
 Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000a4deb905d7706bdf"
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

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

On Mon, Feb 7, 2022, 16:44 Billy Tetrud via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> > every lightning network transaction adds one dust UTXO
>
> Could you clarify what you mean here? What dust do lightning transactions
> create?
>
I mean this msg
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-December/01963=
6.html
Even though, the writer clarified after my enquiry I still think it is the
same meaning most of the time only one will be spent. His words:
..............
*My statement was technically incorrect, it should have been "most of the
time only one of them is spent".*
*But nothing prevents them to be both spent, or none of them to be spent.*
*They are strictly equivalent, the only difference is the public key that
can sign for them: one of these outputs belongs to you, the other belongs
to your peer.*

*You really cannot distinguish anything when inserting them into the utxo
set, they are perfectly symmetrical and you cannot know beforehand for sure
which one will be spent.*
*You can guess which one will be spent most of the time, but your heuristic
will never be 100% correct, so I don't think it's worth pursuing.*
*.........*........

>
> 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 t=
he
> 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 s=
o
> 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 S=
at
>> 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 rul=
e
>> remain in place. Depending on how feerate economics work out in the futu=
re,
>> such outputs may not even remain uneconomical to spend. Therefore, dropp=
ing
>> 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 usi=
ng
>> amount as a heuristic about what to keep and how long. IIRC, not even ev=
ery
>> full node implementation even uses a UTXO model.
>>
>> You recall correctly. Libbitcoin has never used a UTXO store. A full nod=
e
>> 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, publish=
ed,
>> 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 mine=
rs
>> 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
>> _______________________________________________
>> 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
>

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

<div dir=3D"auto"><div><br><br><div class=3D"gmail_quote"><div dir=3D"ltr" =
class=3D"gmail_attr">On Mon, Feb 7, 2022, 16:44 Billy Tetrud via bitcoin-de=
v &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@=
lists.linuxfoundation.org</a>&gt; wrote:<br></div><blockquote class=3D"gmai=
l_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left=
:1ex"><div dir=3D"auto">&gt;=C2=A0<span style=3D"font-size:12.8px">every li=
ghtning network transaction adds one dust UTXO</span><div dir=3D"auto"><spa=
n style=3D"font-size:12.8px"><br></span></div><div dir=3D"auto"><span style=
=3D"font-size:12.8px">Could you clarify what you mean here? What dust do li=
ghtning transactions create?</span></div></div></blockquote></div></div><di=
v dir=3D"auto">I mean this msg</div><div dir=3D"auto"><a href=3D"https://li=
sts.linuxfoundation.org/pipermail/bitcoin-dev/2021-December/019636.html">ht=
tps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-December/019636.=
html</a></div><div dir=3D"auto">Even though, the writer clarified after my =
enquiry I still think it is the same meaning most of the time only one will=
 be spent. His words:</div><div dir=3D"auto">..............</div><div dir=
=3D"auto"><i>My statement was technically incorrect, it should have been &q=
uot;most of the time only one of them is spent&quot;.</i></div><div dir=3D"=
auto"><i>But nothing prevents them to be both spent, or none of them to be =
spent.</i></div><div dir=3D"auto"><i>They are strictly equivalent, the only=
 difference is the public key that can sign for them: one of these outputs =
belongs to you, the other belongs to your peer.</i></div><div dir=3D"auto">=
<i><br></i></div><div dir=3D"auto"><i>You really cannot distinguish anythin=
g when inserting them into the utxo set, they are perfectly symmetrical and=
 you cannot know beforehand for sure which one will be spent.</i></div><div=
 dir=3D"auto"><i>You can guess which one will be spent most of the time, bu=
t your heuristic will never be 100% correct, so I don&#39;t think it&#39;s =
worth pursuing.</i></div><div dir=3D"auto"><i>.........</i>........</div><d=
iv dir=3D"auto"><div class=3D"gmail_quote"><blockquote class=3D"gmail_quote=
" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><=
div dir=3D"auto"><div dir=3D"auto"><span style=3D"font-size:12.8px"><br></s=
pan></div><div dir=3D"auto"><span style=3D"font-size:12.8px">I do think tha=
t 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 solut=
ion to this problem. In the mean time, I kind of agree with Eric that outpu=
ts 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 i=
s 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 class=3D"gmail_quot=
e"><div dir=3D"ltr" class=3D"gmail_attr">On Sun, Feb 6, 2022, 13:14 Eric Vo=
skuil via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundati=
on.org" target=3D"_blank" rel=3D"noreferrer">bitcoin-dev@lists.linuxfoundat=
ion.org</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"=
margin:0 0 0 .8ex;border-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" rel=3D"noreferrer noreferrer=
" target=3D"_blank">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 noreferrer" target=3D"_blank">https=
://bitinfocharts.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" rel=3D"norefe=
rrer noreferrer" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a=
><br>
&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" rel=3D"noreferrer noreferrer noreferrer" target=3D"_blank">https://lis=
ts.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"noreferrer =
noreferrer" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer noreferrer" target=3D"_blank">https://lists.li=
nuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>
_______________________________________________<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></div></div>

--000000000000a4deb905d7706bdf--