path: root/63/1a0b0984a8a96f2ec55cd0aea3afdb2bf5e2f4

Return-Path: <shymaa.arafat@gmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id A521DC002F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 Fri, 21 Jan 2022 12:16:48 +0000 (UTC)
Received: by mail-ed1-x535.google.com with SMTP id l5so25243043edv.3
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <shymaa.arafat@gmail.com>
Date: Fri, 21 Jan 2022 14:16:35 +0200
Message-ID: <CAM98U8nLZBagE4L0TuyKkEtk_jqKJ_xDmAixAkLGR8axO86pmg@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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 <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: 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

<div dir=3D"auto">Dear Sir,<div dir=3D"auto">Regarding your message</div><d=
iv dir=3D"auto"><a href=3D"https://lists.linuxfoundation.org/pipermail/bitc=
oin-dev/2021-December/019636.html" rel=3D"noreferrer noreferrer noreferrer"=
 target=3D"_blank">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/=
2021-December/019636.html</a></div><div dir=3D"auto">Specifically the part<=
/div><div dir=3D"auto"><i style=3D"background-color:rgb(224,224,224)">&quot=
;Right now, lightning anchor outputs use a 330 sats amount. Each commitment=
</i></div><div dir=3D"auto"><i style=3D"background-color:rgb(224,224,224)">=
transaction has two such outputs, and only one of them is spent&quot;</i></=
div><div dir=3D"auto">I was wondering <u>is there a way to distinguish thos=
e 2 dust UTXOs?</u></div><div dir=3D"auto">I mean does(or could) the protoc=
ol force the user to always spend the first not any of them at random?</div=
><div dir=3D"auto">-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?</div><div dir=3D"aut=
o"><br></div><div dir=3D"auto">-If you look at the number of addresses hold=
ing =E2=89=A41$ here (by subtracting total from &gt;1$), you would find it =
doesn&#39;t change very much with days</div><div dir=3D"auto"><a href=3D"ht=
tps://bitinfocharts.com/top-100-richest-bitcoin-addresses.html" rel=3D"nore=
ferrer noreferrer noreferrer" target=3D"_blank">https://bitinfocharts.com/t=
op-100-richest-bitcoin-addresses.html</a><br></div><div dir=3D"auto">-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</div><div dir=3D"auto">(along with non-standard &amp; burned ones at=
 least from public addresses, these should be separated too as they&#39;re =
not expected be spent ever)</div><div dir=3D"auto">.</div><div dir=3D"auto"=
>So the answer may make a difference,</div><div dir=3D"auto">Thank you</div=
><div dir=3D"auto">Shymaa M Arafat</div></div>

--000000000000afaef705d616976c--