From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id A521DC002F for ; Fri, 21 Jan 2022 12:16:49 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 8AE454052D for ; Fri, 21 Jan 2022 12:16:49 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: 1.774 X-Spam-Level: * X-Spam-Status: No, score=1.774 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DEAR_SOMETHING=1.973, 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=no autolearn_force=no Authentication-Results: smtp2.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JgB_qs_2TdvS for ; Fri, 21 Jan 2022 12:16:48 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) by smtp2.osuosl.org (Postfix) with ESMTPS id 24D6740167 for ; Fri, 21 Jan 2022 12:16:48 +0000 (UTC) Received: by mail-ed1-x535.google.com with SMTP id l5so25243043edv.3 for ; Fri, 21 Jan 2022 04:16:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:from:date:message-id:subject:to; bh=ZHdK/nzNPeVhnL5+cruVNNa6QWUWEaeSBbfNbS+bufQ=; b=BTn8OiS4u5V2O9/qglxQoGLchqEkeMEIdlvLW7cFXnjpes312JhaMIa39L8amTwh45 hC2wBWdBwbOlKZzB7I3DjD+r4bIN2TcvuaAdBNfOgHU4lEYbv6t8YXBXrWdHX1mnfM7w RsyX4bd0C2N/m865JYyPD9thUoqBs/HloZvnyFDD+Rek8gL4TOjxMbn2LCTJskPGmSHW AKEyHlUzMDuIaaSAoQ/HyNEJlnAi/vpFfKPmw+XOFwyLeL9oZXHoga7QOKqcDIgzUgSf GRAzu5a+CwyOA/MhEwqEBvnqkF7n8LFbCvva/TjZqj/D8jy+Stb7fNvhL3J6roPkldcH bIqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=ZHdK/nzNPeVhnL5+cruVNNa6QWUWEaeSBbfNbS+bufQ=; b=4w6d7qY6bT8AQxZSt7/+Uly9k9t+T5/QYaLzef3HYTMzgQ3fG2DH1xb3qQwGBAPU5Q +Dc+mkrdl46CaK29Qd7LFeJmu3cLFoZ6RkKxht4MzKpsOlSa8OW8ckYV0aW8gDr0BMI4 hZWeuGA5YvIR4SYdwIdvRCrFzEU1/gZeUd+J9837VATjESaGZ4sjuC+mNb2vtnlnKRbq VGUUic7QMsIBvuKsq3A1E024YhcIgM4BLjaktURdiLjAqW+VwBDB6VoHJ7VRac9sO9yw pjgD+gILQqot2ALqSRzp686zG3usaHtUhqpBdMqL6rjXGMPcw4NhkSxXZ6pmWHuwqqAJ kVJw== X-Gm-Message-State: AOAM533mfjfAhs4Rsz/FqxNKOvyKGrsIMF/sk5nT7NiO1R1fstxFYnFr rAVl+R6aEZtBMc3eCz3GVWg7ot7c5u4R057VwpmWuzf1 X-Google-Smtp-Source: ABdhPJw4Myu2ClNssYTVL9ROTxfufv8ORHBPvnoPeLTmTXFjOXkIpzVU01hom1dqt8ks6nQrM653va3ggiRPHwWEaao= X-Received: by 2002:a17:906:2b8e:: with SMTP id m14mr3104201ejg.406.1642767406049; Fri, 21 Jan 2022 04:16:46 -0800 (PST) MIME-Version: 1.0 From: shymaa arafat Date: Fri, 21 Jan 2022 14:16:35 +0200 Message-ID: To: Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary="000000000000afaef705d616976c" X-Mailman-Approved-At: Fri, 21 Jan 2022 12:21:24 +0000 Subject: Re: [bitcoin-dev] Take 2: Removing the Dust Limit 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: Fri, 21 Jan 2022 12:16:49 -0000 --000000000000afaef705d616976c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Sir, Regarding your message https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-December/01963= 6.html Specifically the part *"Right now, lightning anchor outputs use a 330 sats amount. Each commitment* *transaction has two such outputs, and only one of them is spent"* I was wondering *is there a way to distinguish those 2 dust UTXOs?* I mean does(or could) the protocol force the user to always spend the first not any of them at random? -My point is to distinguish between them when inserted in the UTXO set to know in advance which will be spent so fast in the next transaction, and which is gonna stay there for a while? -If you look at the number of addresses holding =E2=89=A41$ here (by subtra= cting total from >1$), you would find it doesn't change very much with days https://bitinfocharts.com/top-100-richest-bitcoin-addresses.html -Meaning not that just official dust value, but values =E2=89=A41$ are rare= ly spent unless one forced to. I always had the idea of storing them separately (along with non-standard & burned ones at least from public addresses, these should be separated too as they're not expected be spent ever) . So the answer may make a difference, Thank you Shymaa M Arafat --000000000000afaef705d616976c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Specifically the part<= /div>
"= ;Right now, lightning anchor outputs use a 330 sats amount. Each commitment=
= transaction has two such outputs, and only one of them is spent"
I was wondering is there a way to distinguish thos= e 2 dust UTXOs?
I mean does(or could) the protoc= ol force the user to always spend the first not any of them at random?
-My point is to distinguish between them when inserted i= n the UTXO set to know in advance which will be spent so fast in the next t= ransaction, and which is gonna stay there for a while?

-If you look at the number of addresses hold= ing =E2=89=A41$ here (by subtracting total from >1$), you would find it = doesn't change very much with days
-Meani= ng not that just official dust value, but values =E2=89=A41$ are rarely spe= nt unless one forced to. I always had the idea of storing them separately= =C2=A0
(along with non-standard & burned ones at= least from public addresses, these should be separated too as they're = not expected be spent ever)
.
So the answer may make a difference,
Thank you
Shymaa M Arafat
--000000000000afaef705d616976c--