From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <willtech@live.com.au>
Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136])
by lists.linuxfoundation.org (Postfix) with ESMTP id 7BAAAC000E;
Mon, 30 Aug 2021 03:32:10 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp3.osuosl.org (Postfix) with ESMTP id 596D560748;
Mon, 30 Aug 2021 03:32:10 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, LOTS_OF_MONEY=0.001,
RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001,
SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Received: from smtp3.osuosl.org ([127.0.0.1])
by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id cQynBF7sEQwp; Mon, 30 Aug 2021 03:32:05 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.8.0
X-Greylist: whitelisted by SQLgrey-1.8.0
Received: from APC01-SG2-obe.outbound.protection.outlook.com
(mail-oln040092253094.outbound.protection.outlook.com [40.92.253.94])
by smtp3.osuosl.org (Postfix) with ESMTPS id 0F79D60600;
Mon, 30 Aug 2021 03:32:03 +0000 (UTC)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none;
b=NbdCnqRY9TF1a980RaHuMiys6ACiyg8XPkelTUJhtrVBnhAEmX+NsSk8+byKN7w6i/wmnQx1D0B4vB/kbv1CkxF5YV/PrBvlecXacpE2sSFutR1EATQxOx37f+psoZDK8rnNFPlynKN04RdHOeyaYNn/byWP5KgG+cfo4LhNSkmlcjM4lFBGV0wCV9+h6OQVtH5DLnufCODPbK4jJhH2AVYBfNnBkvdWWw9gyFW8rdka+GfAJcjIno0ojcbIRcgBi2YvRBEUovfDimuODEKPAUs3TDnI5S4VAy1P2+jPbJ2EK6r2NTZ3cViILVPDNrH2jFYMFVrvnN1j4g+ymtj+mQ==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com;
s=arcselector9901;
h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck;
bh=e49HNOv70TqdlD3/9IZ6oDc+Osy0VQK4h6YjN40w+/Y=;
b=mEYjhnnVbDv97ktE/ZAxG99euCvF31o27trsnOvvaDsGhPDB6jUzKmTwbYijvl92jjngY2zVEGHjugiDjoUAr/XcNSHAMy/0nspzTIaMzqXTs3YIA6ZgLSgeJc0E1Tpiw+PENGAyV+mKxmsM4emC7/USezkH9RJAeID6t6RGrt2tWz6RvhpRQdH1QtVnCB21arL7Xq4vIjNkuOzLC6fK+yPRx1XngIvFrjIePHr/usPskgwRRdtCI/Crk0RlUj8+8/zxx/IeW0pEnjgEzQudfGpKOgOU+A/ple+gYIkFoR/u3A+b5bG4w+zU/UnZcYM7IP2ArYHSNOdWH5xAQOOhRg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none;
dkim=none; arc=none
Received: from PS2PR06CA0017.apcprd06.prod.outlook.com (2603:1096:300:56::29)
by SG2PR01MB2837.apcprd01.prod.exchangelabs.com (2603:1096:4:33::20)
with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4457.24; Mon, 30 Aug
2021 03:31:56 +0000
Received: from PU1APC01FT060.eop-APC01.prod.protection.outlook.com
(2603:1096:300:56:cafe::da) by PS2PR06CA0017.outlook.office365.com
(2603:1096:300:56::29) with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4457.19 via Frontend
Transport; Mon, 30 Aug 2021 03:31:56 +0000
Received: from PS2P216MB1089.KORP216.PROD.OUTLOOK.COM (2a01:111:e400:7ebe::41)
by PU1APC01FT060.mail.protection.outlook.com
(2a01:111:e400:7ebe::300) with Microsoft SMTP Server (version=TLS1_2,
cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4457.17 via Frontend
Transport; Mon, 30 Aug 2021 03:31:56 +0000
Received: from PS2P216MB1089.KORP216.PROD.OUTLOOK.COM
([fe80::91f6:588c:d676:a317]) by PS2P216MB1089.KORP216.PROD.OUTLOOK.COM
([fe80::91f6:588c:d676:a317%9]) with mapi id 15.20.4457.024; Mon, 30 Aug 2021
03:31:56 +0000
From: LORD HIS EXCELLENCY JAMES HRMH <willtech@live.com.au>
To: Billy Tetrud <billy.tetrud@gmail.com>, Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org>, shymaa arafat
<shymaa.arafat@gmail.com>
Thread-Topic: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit
Thread-Index: AQHXmsabJoRXm24Zrk+843c88w8+qquHEGaAgARWQmc=
Date: Mon, 30 Aug 2021 03:31:56 +0000
Message-ID: <PS2P216MB108951BFE0724BD49D8EEA809DCB9@PS2P216MB1089.KORP216.PROD.OUTLOOK.COM>
References: <CAD5xwhjFBjvkMKev_6HFRuRGcZUi7WjO5d963GNXWN4n-06Pqg@mail.gmail.com>
<CALZpt+F9FScaLsvXUozdBL4Ss8r71-gtUS_Fh9i53cK_rSGBeA@mail.gmail.com>
<20210810061441.6rg3quotiycomcp6@ganymede>
<CALZpt+G0CRitWLwUTA+7NnnZWNNrsEmFTMW3VmFSQ=vzXZOQGA@mail.gmail.com>
<20210812220339.GA3416@erisian.com.au>
<CAD5xwhiEDa2KjF265iDZ1ism4AFzh3S3D4cJSESVVKNwv9L7zA@mail.gmail.com>
<50s2eg2qZ_BSHhI1mT_mHP7fkDQ8EXnakOb9NmDfZlx_hN44l37UmopfAr2V4ws4yhx0YihNYBIOelJ01vhITI8K4G1UgmobTwf9FyJq_Yo=@protonmail.com>
<CAGpPWDbseo6eYT1a54YB2-fpxpzj2cg9DL+s2_rpoa+dGfnhaQ@mail.gmail.com>
<CAM98U8nOqvOSBvP15dGup-LoW-af9EHFKyTy_XDOjfR-NGjJYA@mail.gmail.com>
In-Reply-To: <CAM98U8nOqvOSBvP15dGup-LoW-af9EHFKyTy_XDOjfR-NGjJYA@mail.gmail.com>
Accept-Language: en-AU, en-US
Content-Language: en-AU
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-incomingtopheadermarker: OriginalChecksum:4D23824EFB8C4A6EE1C4DB2A4B9630102A8E2235BA0EB15C421964489972F36B;
UpperCasedChecksum:24CAC5FE6959F4D8E818C5366E5E237F491563463D255457AFC8601E856445F0;
SizeAsReceived:7633; Count:45
x-ms-exchange-messagesentrepresentingtype: 1
x-tmn: [iW+dbhXQdwPUunsCG6aVGBDahIt4z4ZB]
x-ms-publictraffictype: Email
x-incomingheadercount: 45
x-eopattributedmessage: 0
x-ms-office365-filtering-correlation-id: b9cd6847-5fba-4613-fe6e-08d96b66b7e2
x-ms-traffictypediagnostic: SG2PR01MB2837:
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: 0icZ2WbVatwdX0LFRuckbPhy4Ay66FB8qQO92PTbeg00jxJjSlYnAkVWHzEuklZSo5Wxhd9RiULDLZS0kQ++hF0GqgqyWlKMckHCiv/ATQTF6Ft2Ek+5nvXBhLyCDpV4THmFRff3Rx4Rmk2relcWNPkVdIcK6QUHm6CSDPbEeMMELFNRPqXOLSfX6eJP2ZbwanVA9MMSdYXzfePA8wUtnp5Qd6G1sOByZL3Tiqup1OaW8LEYIZ583z5Obn5vOn7Yi1cJoqu+vqaGCTwIAznMfcG3hi4Cvr+6LnQH2jzfScmOZzOEoZxS9N7K4YV1kpakzj8qw3j4JEaud9LiNZenVXeVL6L4TAZWwaluHysvk0zDufheL2MOhr8AgydreVg9KR4za5SmG3vqEX0fa5y60KPHZE2gtMEXmi9nlJ9PhNrHI5qQ0SW9ic+wkxw9/DXReTA1dDQoLQZK0TpNkuAlPjDBzGami7J9Pdms/0Es/7M=
x-ms-exchange-antispam-messagedata-chunkcount: 1
x-ms-exchange-antispam-messagedata-0: fc6V3A85enuTWHOcmbtLQPzFM9zzUl1283SHfzfWEM6xA5Vvs22Kuyc0BTXU+Zqt/MX0xut8NtAc+e4M9ZHm4UGZ1Kj5Cc68zkp/x/srHaKfdM1v9IcGotSBPFZFmVbD7BZH21qQCFlQ6ghAGxK52g==
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative;
boundary="_000_PS2P216MB108951BFE0724BD49D8EEA809DCB9PS2P216MB1089KORP_"
MIME-Version: 1.0
X-OriginatorOrg: sct-15-20-3174-20-msonline-outlook-5c337.templateTenant
X-MS-Exchange-CrossTenant-AuthAs: Anonymous
X-MS-Exchange-CrossTenant-AuthSource: PU1APC01FT060.eop-APC01.prod.protection.outlook.com
X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-CrossTenant-Network-Message-Id: b9cd6847-5fba-4613-fe6e-08d96b66b7e2
X-MS-Exchange-CrossTenant-originalarrivaltime: 30 Aug 2021 03:31:56.4573 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Internet
X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa
X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SG2PR01MB2837
X-Mailman-Approved-At: Mon, 30 Aug 2021 08:39:29 +0000
Cc: lightning-dev <lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Lightning-dev] 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: Mon, 30 Aug 2021 03:32:10 -0000
--_000_PS2P216MB108951BFE0724BD49D8EEA809DCB9PS2P216MB1089KORP_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Good Afternoon,
It is worth reconsidering the value accumulated in dust. Speculatively, whe=
n the value of 1 BTC reaches US$ 1,000,000.00 then the value of one satoshi=
will be US$ 0.01 so, for 1 satoshi to be of any substantial value the valu=
e of Bitcoin will have to rise substantially higher. I ask what then should=
the value of fees be? Is there not a future case foreseeable at least in c=
onsideration of Bitcoin's comparison with Gold that the value may be so hig=
h as to allow that 1 satoshi may cover the mining cost of any transaction d=
espite the reduction in sat/B for including the additional transaction. Is =
it not that we can foresee the dust has value and that the wealthy may have=
in fact millions of dust transactions that are inheritable, though I hesit=
ate to make my business collecting them I may set up a website. The current=
reason for excluding dust is because it costs more to the transaction to a=
dd the dust than its value but that does not say that will always be the ca=
se.
KING JAMES HRMH
Great British Empire
Regards,
The Australian
LORD HIS EXCELLENCY JAMES HRMH (& HMRH)
of Hougun Manor & Glencoe & British Empire
MR. Damian A. James Williamson
Wills
et al.
Willtech
www.willtech.com.au
www.go-overt.com
and other projects
earn.com/willtech
linkedin.com/in/damianwilliamson
m. 0487135719
f. +61261470192
This email does not constitute a general advice. Please disregard this emai=
l if misdelivered.
----
________________________________
From: bitcoin-dev <bitcoin-dev-bounces@lists.linuxfoundation.org> on behalf=
of shymaa arafat via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Sent: Friday, 27 August 2021 7:07 PM
To: Billy Tetrud <billy.tetrud@gmail.com>; Bitcoin Protocol Discussion <bit=
coin-dev@lists.linuxfoundation.org>
Cc: lightning-dev <lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit
Allow me to ask:
-Untill you find a mitigation that consolidate all dust UTXOS, why don't yo=
u separate them and all probably Unspendable UTXOS in a different partition=
?
-I'm talking at the real UTXO storage level (to be kept in secondary storag=
e), and at the Merkleization level in any accumulator design Utreexo or wha=
t so ever(putting them in one or two subtree/forest with hardly changing ro=
ots according to the categorization will reduce the proof size, even if sli=
ghtly)
-This will also help things like Bloom filters, assume UTXOs,...etc when ab=
out 10% with almost zero probability are trimmed from the pool you are with=
drawing from.
.
-The paper I mentioned earlier says in Feb 2018, there was about 2.4m UTXOS=
less than 1000 Satoshi, of which ~824,892 holds exactly 1 Satoshi
-I don't think any of those were spent since that time, in fact there could=
be a possibility that the numbers may have increased
-As the last previous reply mentioned you have to consider the long run eff=
ect on the UTXO set forever, this is a straight forward improvement that co=
mes with almost no effort
.
Ps.
-If there is something wrong, something I missed in this idea please explai=
n it to me
-Or do you find the improvement itself a "dust" that doesn't worth the effo=
rt???
.
Regards & thank you all for your time in reading & replying
Shymaa M. Arafat
On Fri, Aug 27, 2021, 00:06 Billy Tetrud via bitcoin-dev <bitcoin-dev@lists=
.linuxfoundation.org<mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
One interesting thing I thought of: the cost of maintenance of the dust cre=
ates a (very) small incentive to mine transactions that *use* dust outputs =
with a slightly lower fee that contain dust, in order to reduce the future =
maintenance cost for themselves. However, the rational discount would likel=
y be vanishingly small. It would be interesting to add something to the co=
nsensus rules to decrease the vbytes for a transaction that consumes dust o=
utputs such that the value of removing them from the system (saving the fut=
ure cost of maintenance) is approximately equal to the amount that the fee =
could be made lower for such transactions. Even measuring this as a value o=
ver the whole (future) bitcoin network, I'm not sure how to evaluate the ma=
gnitude of this future cost.
On Fri, Aug 20, 2021 at 8:12 PM ZmnSCPxj via bitcoin-dev <bitcoin-dev@lists=
.linuxfoundation.org<mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
Good morning Jeremy,
> one interesting point that came up at the bitdevs in austin today that fa=
vors remove that i believe is new to this discussion (it was new to me):
>
> the argument can be reduced to:
>
> - dust limit is a per-node relay policy.
> - it is rational for miners to mine dust outputs given their cost of main=
tenance (storing the output potentially forever) is lower than their immedi=
ate reward in fees.
> - if txn relaying nodes censor something that a miner would mine, users w=
ill seek a private/direct relay to the miner and vice versa.
> - if direct relay to miner becomes popular, it is both bad for privacy an=
d decentralization.
> - therefore the dust limit, should there be demand to create dust at prev=
ailing mempool feerates, causes an incentive to increase network centraliza=
tion (immediately)
>
> the tradeoff is if a short term immediate incentive to promote network ce=
ntralization is better or worse than a long term node operator overhead.
Against the above, we should note that in the Lightning spec, when an outpu=
t *would have been* created that is less than the dust limit, the output is=
instead put into fees.
https://github.com/lightningnetwork/lightning-rfc/blob/master/03-transactio=
ns.md#trimmed-outputs
Thus, the existence of a dust limit encourages L2 protocols to have similar=
rules, where outputs below the dust limit are just given over as fees to m=
iners, so the existence of a dust limit might very well be incentivize-comp=
atible for miners, regardless of centralization effects or not.
Regards,
ZmnSCPxj
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org<mailto:bitcoin-dev@lists.linuxfoundat=
ion.org>
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org<mailto:bitcoin-dev@lists.linuxfoundat=
ion.org>
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--_000_PS2P216MB108951BFE0724BD49D8EEA809DCB9PS2P216MB1089KORP_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<html>
<head>
<meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Diso-8859-=
1">
<style type=3D"text/css" style=3D"display:none;"> P {margin-top:0;margin-bo=
ttom:0;} </style>
</head>
<body dir=3D"ltr">
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
color: rgb(0, 0, 0);">
Good Afternoon,</div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
color: rgb(0, 0, 0);">
<br>
</div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
color: rgb(0, 0, 0);">
It is worth reconsidering the value accumulated in dust. Speculatively, whe=
n the value of 1 BTC reaches US$ 1,000,000.00 then the value of one satoshi=
will be US$ 0.01 so, for 1 satoshi to be of any substantial value the valu=
e of Bitcoin will have to rise substantially
higher. I ask what then should the value of fees be? Is there not a future=
case foreseeable at least in consideration of Bitcoin's comparison with Go=
ld that the value may be so high as to allow that 1 satoshi may cover the m=
ining cost of any transaction despite
the reduction in sat/B for including the additional transaction. Is it not=
that we can foresee the dust has value and that the wealthy may have in fa=
ct millions of dust transactions that are inheritable, though I hesitate to=
make my business collecting them
I may set up a website. The current reason for excluding dust is because i=
t costs more to the transaction to add the dust than its value but that doe=
s not say that will always be the case.</div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
color: rgb(0, 0, 0);">
<br>
</div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
color: rgb(0, 0, 0);">
<span><span style=3D"font-family:Calibri,Helvetica,sans-serif;font-size:12p=
t">KING JAMES HRMH</span></span><br>
<span><span style=3D"font-family:Calibri,Helvetica,sans-serif;font-size:12p=
t">Great British Empire</span></span><br>
</div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
color: rgb(0, 0, 0);">
<br>
</div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
color: rgb(0, 0, 0);">
Regards,
<div>The Australian</div>
<div>LORD HIS EXCELLENCY JAMES HRMH (& HMRH)</div>
<div>of Hougun Manor & Glencoe & British Empire</div>
<div>MR. Damian A. James Williamson</div>
<div>Wills</div>
<div><br>
</div>
<div>et al.</div>
<div><br>
</div>
<div> </div>
<div>Willtech</div>
<div>www.willtech.com.au</div>
<div>www.go-overt.com</div>
<div>and other projects</div>
<div> </div>
<div>earn.com/willtech</div>
<div>linkedin.com/in/damianwilliamson</div>
<div><br>
</div>
<div><br>
</div>
<div>m. 0487135719</div>
<div>f. +61261470192</div>
<div><br>
</div>
<div><br>
</div>
<div>This email does not constitute a general advice. Please disregard this=
email if misdelivered.</div>
----<br>
</div>
<div>
<hr tabindex=3D"-1" style=3D"display:inline-block; width:98%">
<div id=3D"divRplyFwdMsg" dir=3D"ltr"><font style=3D"font-size:11pt" face=
=3D"Calibri, sans-serif" color=3D"#000000"><b>From:</b> bitcoin-dev <bit=
coin-dev-bounces@lists.linuxfoundation.org> on behalf of shymaa arafat v=
ia bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org><br>
<b>Sent:</b> Friday, 27 August 2021 7:07 PM<br>
<b>To:</b> Billy Tetrud <billy.tetrud@gmail.com>; Bitcoin Protocol Di=
scussion <bitcoin-dev@lists.linuxfoundation.org><br>
<b>Cc:</b> lightning-dev <lightning-dev@lists.linuxfoundation.org><br=
>
<b>Subject:</b> Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit</=
font>
<div> </div>
</div>
<div>
<div dir=3D"auto">
<div dir=3D"auto"></div>
Allow me to ask:
<div dir=3D"auto"><br>
<div dir=3D"auto">
<div dir=3D"auto">-Untill you find a mitigation that consolidate all dust U=
TXOS, why don't you separate them and all probably Unspendable UTXOS in a d=
ifferent partition?</div>
<div dir=3D"auto">-I'm talking at the real UTXO storage level (to be kept i=
n secondary storage), and at the Merkleization level in any accumulator des=
ign Utreexo or what so ever(putting them in one or two subtree/forest with =
hardly changing roots according to
the categorization will reduce the proof size, even if slightly)</div>
<div dir=3D"auto">-This will also help things like Bloom filters, assume UT=
XOs,...etc when about 10% with almost zero probability are trimmed from the=
pool you are withdrawing from.</div>
<div dir=3D"auto">.</div>
<div dir=3D"auto">-The paper I mentioned earlier says in Feb 2018, there wa=
s about 2.4m UTXOS less than 1000 Satoshi, of which ~824,892 holds exactly =
1 Satoshi</div>
<div dir=3D"auto">-I don't think any of those were spent since that time, i=
n fact there could be a possibility that the numbers may have increased</di=
v>
<div dir=3D"auto">-As the last previous reply mentioned you have to conside=
r the long run effect on the UTXO set forever, this is a straight forward i=
mprovement that comes with almost no effort</div>
<div dir=3D"auto">.</div>
<div dir=3D"auto">Ps.</div>
<div dir=3D"auto">-If there is something wrong, something I missed in this =
idea please explain it to me</div>
<div dir=3D"auto">-Or do you find the improvement itself a "dust"=
that doesn't worth the effort???</div>
<div dir=3D"auto">.</div>
<div dir=3D"auto">Regards & thank you all for your time in reading &=
; replying</div>
<div dir=3D"auto">Shymaa M. Arafat</div>
<div dir=3D"auto">
<div class=3D"x_gmail_quote" dir=3D"auto">
<div dir=3D"ltr" class=3D"x_gmail_attr">On Fri, Aug 27, 2021, 00:06 Billy T=
etrud via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundati=
on.org" rel=3D"noreferrer noreferrer" target=3D"_blank">bitcoin-dev@lists.l=
inuxfoundation.org</a>> wrote:<br>
</div>
<blockquote class=3D"x_gmail_quote" style=3D"margin:0 0 0 .8ex; border-left=
:1px #ccc solid; padding-left:1ex">
<div dir=3D"ltr">
<div><br>
</div>
<div><span style=3D"color:rgb(0,0,0); font-family:arial,helvetica,sans-seri=
f">One interesting thing I thought of: the cost of maintenance of the dust =
creates a (very) small incentive to mine transactions that *use* dust outpu=
ts with a slightly lower fee that
contain dust, in order to reduce the future maintenance cost for themselve=
s. However, the rational discount would likely be vanishingly small. =
It would be interesting to add something to the consensus rules to decrease=
the vbytes for a transaction that consumes
dust outputs such that the value of removing them from the system (saving =
the future cost of maintenance) is approximately equal to the amount that t=
he fee could be made lower for such transactions. Even measuring this as a =
value over the whole (future) bitcoin
network, I'm not sure how to evaluate the magnitude of this future cost. <=
/span>
<br>
</div>
<div><span style=3D"color:rgb(0,0,0); font-family:arial,helvetica,sans-seri=
f"><br>
</span></div>
<div><span style=3D"color:rgb(0,0,0); font-family:arial,helvetica,sans-seri=
f"><br>
</span></div>
<div><span style=3D"color:rgb(0,0,0); font-family:arial,helvetica,sans-seri=
f"><br>
</span></div>
<div><span style=3D"color:rgb(0,0,0); font-family:arial,helvetica,sans-seri=
f"> </span><br>
</div>
</div>
<br>
<div class=3D"x_gmail_quote">
<div dir=3D"ltr" class=3D"x_gmail_attr">On Fri, Aug 20, 2021 at 8:12 PM Zmn=
SCPxj via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@lists.linuxfoundati=
on.org" rel=3D"noreferrer noreferrer noreferrer" target=3D"_blank">bitcoin-=
dev@lists.linuxfoundation.org</a>> wrote:<br>
</div>
<blockquote class=3D"x_gmail_quote" style=3D"margin:0px 0px 0px 0.8ex; bord=
er-left:1px solid rgb(204,204,204); padding-left:1ex">
Good morning Jeremy,<br>
<br>
> one interesting point that came up at the bitdevs in austin today that=
favors remove that i believe is new to this discussion (it was new to me):=
<br>
><br>
> the argument can be reduced to:<br>
><br>
> - dust limit is a per-node relay policy.<br>
> - it is rational for miners to mine dust outputs given their cost of m=
aintenance (storing the output potentially forever) is lower than thei=
r immediate reward in fees.<br>
> - if txn relaying nodes censor something that a miner would mine, user=
s will seek a private/direct relay to the miner and vice versa.<br>
> - if direct relay to miner becomes popular, it is both bad for privacy=
and decentralization.<br>
> - therefore the dust limit, should there be demand to create dust at p=
revailing mempool feerates, causes an incentive to increase network central=
ization (immediately)<br>
><br>
> the tradeoff is if a short term immediate incentive to promote network=
centralization is better or worse than a long term node operator overhead.=
<br>
<br>
Against the above, we should note that in the Lightning spec, when an outpu=
t *would have been* created that is less than the dust limit, the output is=
instead put into fees.<br>
<a href=3D"https://github.com/lightningnetwork/lightning-rfc/blob/master/03=
-transactions.md#trimmed-outputs" rel=3D"noreferrer noreferrer noreferrer n=
oreferrer" target=3D"_blank">https://github.com/lightningnetwork/lightning-=
rfc/blob/master/03-transactions.md#trimmed-outputs</a><br>
<br>
Thus, the existence of a dust limit encourages L2 protocols to have similar=
rules, where outputs below the dust limit are just given over as fees to m=
iners, so the existence of a dust limit might very well be incentivize-comp=
atible for miners, regardless of
centralization effects or not.<br>
<br>
<br>
Regards,<br>
ZmnSCPxj<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"noreferrer =
noreferrer noreferrer" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.=
org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer noreferrer noreferrer" target=3D"_blank">https=
://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote>
</div>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" rel=3D"noreferrer =
noreferrer noreferrer" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.=
org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer noreferrer noreferrer noreferrer" target=3D"_blank">https=
://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</body>
</html>
--_000_PS2P216MB108951BFE0724BD49D8EEA809DCB9PS2P216MB1089KORP_--