From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 3E286C000B for ; Mon, 7 Feb 2022 16:52:09 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 25EF38136B for ; Mon, 7 Feb 2022 16:52:09 +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: smtp1.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JAH5ET7eqQct for ; Mon, 7 Feb 2022 16:52:07 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-ed1-x52e.google.com (mail-ed1-x52e.google.com [IPv6:2a00:1450:4864:20::52e]) by smtp1.osuosl.org (Postfix) with ESMTPS id A276D81353 for ; Mon, 7 Feb 2022 16:52:07 +0000 (UTC) Received: by mail-ed1-x52e.google.com with SMTP id eg42so15660484edb.7 for ; Mon, 07 Feb 2022 08:52:07 -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; bh=RDdDtonQlhLr+DKBCFbn/pbN40kRX5Rz/xz4TtsPvvs=; b=FDzemIh+eDYN8l52bSmwFbwkBzYp+H1tc6IMwVLeBm3jrCxGeBVVNpedcEREqZYPzu wxX8lIkSrPMdZGYDOXlia/7cErEh1ED7jVtxzv7CPXbZs7K6QluOxh9hS1QRkfoHv12W ume3tGgTfHASgMNSpmflwf3OPzNgDWfOYiIKDNpNPm4GIbFyeHsroZ0KvNfkEF+8oKlx HzCChMIv0otiGCstxxUg0hqAGscS6bkSj1HVcgCNqicEBqhzfMu9iGmq9Rdx1a+Q7R1F Xx5Xaf93DcAhtE/ZhuX71CjOfKWneqrFGHysQ8aJa2HHa4QhhhAKMNj3a6wJAPX/AEQM lQ3Q== 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; bh=RDdDtonQlhLr+DKBCFbn/pbN40kRX5Rz/xz4TtsPvvs=; b=zmeMfNP6S5es3UbF2uo7Aif1yF5gyieWgj85HsNwluXS581tA9d0o2ZIDtSzcB3vH7 krsOtK7rmEwah6qQE2oSj4kFNIBCFe0xtgtR2e3OuTx5MrssfLzLhwNezu1ZwZH/PRsm GWDPqOBOApk4rjQBcR78QSC73YTavilTC6BZeyPgWMPYLmRiEBjfwFMW0XMiR8/DoRDy 0YYQS1ne7KlkdumKaKy62EA+cAxDKFW1sai3+XYztPR7/4jmWLKprdJ5/BKvDVDbzNja crpwQ90+7GTAbqvONbHD2vXgzOYFxkc0bRGbl6ywYhn8QEcEHdD18yk1MuayWWxxhnKg /T5Q== X-Gm-Message-State: AOAM533konQcdpfHUzAPZ1a2tKWXwvCuN8e5pK20HqLAHt6jdB2952X8 kjnCXiIGMC0tEsv7nJAIUq5+6rE848PG8Zivx0vjsTlU X-Google-Smtp-Source: ABdhPJxZ6P4SzfVkX4lTVcexEiKlM5btYO7y++AHQMMZUxRFEysGT+PF0G51388dB+5ss92oc0aEFUDB0XPiLjbz7Vg= X-Received: by 2002:aa7:c793:: with SMTP id n19mr396751eds.74.1644252725828; Mon, 07 Feb 2022 08:52:05 -0800 (PST) MIME-Version: 1.0 References: <86BAFB7B-5ECB-4790-A19B-6E296A063C59@voskuil.org> In-Reply-To: From: shymaa arafat Date: Mon, 7 Feb 2022 18:51:54 +0200 Message-ID: To: Billy Tetrud , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000a4deb905d7706bdf" X-Mailman-Approved-At: Mon, 07 Feb 2022 16:59:07 +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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2022 16:52:09 -0000 --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


On Mon, Feb 7, 2022, 16:44 Billy Tetrud via bitcoin-de= v <bitcoin-dev@= lists.linuxfoundation.org> wrote:
>=C2=A0every li= ghtning network transaction adds one dust UTXO

Could you clarify what you mean here? What dust do li= ghtning transactions create?
I mean this msg
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 &q= uot;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 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.
You can guess which one will be spent most of the time, bu= t your heuristic will never be 100% correct, so I don't think it's = worth pursuing.
.................
<= div dir=3D"auto">

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

On Sun, Feb 6, 2022, 13:14 Eric Vo= skuil via bitcoin-dev <bitcoin-dev@lists.linuxfoundat= ion.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 ad= dresses, 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 4= 73 Sat per address.
>
>> -Therefore, a simple solution would be to follow the difficulty ad= justment idea and just delete all those
>
> 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.
>
>> 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 ever= y full node implementation even uses a UTXO model.

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

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.

>> 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).
>
> Do you mean this as a standardness rule, or a consensus rule?
>
> * As a standardness rule it'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.
> * 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's unclear what those rules, if any, should be.
>
> Cheers,
>
> --
> Pieter
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lis= ts.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.li= nuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundati= on.org/mailman/listinfo/bitcoin-dev
--000000000000a4deb905d7706bdf--