Return-Path: Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137]) by lists.linuxfoundation.org (Postfix) with ESMTP id A447EC000B for ; 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 ; 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 ; 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 ; Mon, 7 Feb 2022 14:34:55 +0000 (UTC) Received: by mail-ed1-x52d.google.com with SMTP id b13so30464666edn.0 for ; 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: <86BAFB7B-5ECB-4790-A19B-6E296A063C59@voskuil.org> In-Reply-To: <86BAFB7B-5ECB-4790-A19B-6E296A063C59@voskuil.org> From: Billy Tetrud Date: Mon, 7 Feb 2022 08:34:42 -0600 Message-ID: To: Eric Voskuil , Bitcoin Protocol Discussion 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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
>=C2=A0every lightnin= g network transaction adds one dust UTXO

Could you clarify what you mean here? What dust do lightnin= g transactions create?

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'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, 2= 022, 13:14 Eric Voskuil via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wro= te:


> 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://bitinfoc= harts.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://lists.linuxfou= ndation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundati= on.org/mailman/listinfo/bitcoin-dev
--000000000000f20c9705d76e80bc--