path: root/c4/af8714af50588278767da52a86d52bb1aa250a

Return-Path: <fresheneesz@gmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id A447EC000B
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  7 Feb 2022 14:34:56 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 92E68402AD
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  7 Feb 2022 14:34:56 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level: 
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001,
 HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001,
 SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
 dkim=pass (2048-bit key) header.d=gmail.com
Received: from smtp4.osuosl.org ([127.0.0.1])
 by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
 with ESMTP id VTcdI0EK1q_U
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  7 Feb 2022 14:34:55 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com
 [IPv6:2a00:1450:4864:20::52d])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 3FAAC40245
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon,  7 Feb 2022 14:34:55 +0000 (UTC)
Received: by mail-ed1-x52d.google.com with SMTP id b13so30464666edn.0
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Mon, 07 Feb 2022 06:34:55 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112;
 h=mime-version:references:in-reply-to:from:date:message-id:subject:to
 :cc; bh=d9yPb123JdevQ6NNcuD5M01A5xJTxf9t/mqpMvxPQYE=;
 b=D5XvudfhcBtk/pMB2fS/gJkD+WDAdzEB+2joPe6ygj1MO7bOlkgkfaN8uMTbwNP60/
 oa7AbDr/9p8ejOck9jKjQeCFDmRkfzGqU/dYqPoyE5warC2wf9qMgXzRIufOU4ZolPBG
 zrvLcBoqy7XGOaU+KOiRrdRLgw1xVO7uI/O/5bfAk1PEhPHyQdgxynG8QN8FAJq06IfQ
 TWQA0NP59Ga7eSeNqCKLm1Qbq4VevLc2dTG6OWA7qPmveyTw2d1OGIp4X9ugivpL9hdh
 AkLd3Qqbx0nez3hyFHkx9ii9AOm3aoG1LKyOtPS+6PLvpBq3IM0EPbKkt/jvYPRp5aB6
 t3+A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
 d=1e100.net; s=20210112;
 h=x-gm-message-state:mime-version:references:in-reply-to:from:date
 :message-id:subject:to:cc;
 bh=d9yPb123JdevQ6NNcuD5M01A5xJTxf9t/mqpMvxPQYE=;
 b=LYYfl0QElHwclz2lfzQQhD+y6LEdR183hUsDk81vjYF7E4KlwRTp5I6CX792jmH1hW
 ysvhuMYxDTJ5+X0IDqGQX9zgZVQ9Z1h2VwQ+VaSgJwMCIxgs40IAxzfDZ9Y2zoeZ5OwI
 lGFg90Mrw0gs2DUJRtHxqm4gRpePNgHWSTUkbIvnOGV4nBaVA7mleSCSHvtII5KZbFhy
 A2KzEq0HKuXE4pUIx2CKS+m27+B1sGw0a5PVcecxB64I9Fy7XnZ3aLnRM/DCsuZf6sqP
 OPNUrY1fPFHbx3MY9Ix7jbOprJfaNgdixEy+7pgwwTVkDXFV3XF76gAUr0dyiM0zG5a8
 /70A==
X-Gm-Message-State: AOAM5315tTEKY0C7zMkyCdzo88ygs8fDUNVwMs8sOhrM9/wpNdQHCEMg
 FEk9top04wQvpn90pgr1NRl+r7c4OG3XnTcmWpvrmpFE
X-Google-Smtp-Source: ABdhPJwrNFSl2lbzDIRpApImfeLeXT5uWXnNnCLq8y4oe/URT2CIuziSl9BUmG2m9BniEHze2mJqmwni934g4U+auAA=
X-Received: by 2002:a05:6402:2932:: with SMTP id
 ee50mr7003881edb.213.1644244493273; 
 Mon, 07 Feb 2022 06:34:53 -0800 (PST)
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"
X-Mailman-Approved-At: Mon, 07 Feb 2022 14:43:06 +0000
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
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Feb 2022 14:34:56 -0000

--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--