From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 To: Billy Tetrud , Bitcoin Protocol Discussion , shymaa arafat 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: References: <20210810061441.6rg3quotiycomcp6@ganymede> <20210812220339.GA3416@erisian.com.au> <50s2eg2qZ_BSHhI1mT_mHP7fkDQ8EXnakOb9NmDfZlx_hN44l37UmopfAr2V4ws4yhx0YihNYBIOelJ01vhITI8K4G1UgmobTwf9FyJq_Yo=@protonmail.com> In-Reply-To: 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 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 on behalf= of shymaa arafat via bitcoin-dev Sent: Friday, 27 August 2021 7:07 PM To: Billy Tetrud ; Bitcoin Protocol Discussion Cc: lightning-dev 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 > 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 > 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 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 --_000_PS2P216MB108951BFE0724BD49D8EEA809DCB9PS2P216MB1089KORP_ Content-Type: text/html; 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 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.

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= email if misdelivered.
----
From: bitcoin-dev <bit= coin-dev-bounces@lists.linuxfoundation.org> on behalf of shymaa arafat v= ia bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Sent: Friday, 27 August 2021 7:07 PM
To: Billy Tetrud <billy.tetrud@gmail.com>; Bitcoin Protocol Di= scussion <bitcoin-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 U= TXOS, why don't you separate them and all probably Unspendable UTXOS in a d= ifferent partition?
-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)
-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.
.
-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
-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
-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
.
Ps.
-If there is something wrong, something I missed in this = idea please explain it to me
-Or do you find the improvement itself a "dust"= that doesn't worth the effort???
.
Regards & thank you all for your time in reading &= ; replying
Shymaa M. Arafat
On Fri, Aug 27, 2021, 00:06 Billy T= etrud via bitcoin-dev <bitcoin-dev@lists.l= inuxfoundation.org> wrote:

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>



 

On Fri, Aug 20, 2021 at 8:12 PM Zmn= SCPxj via bitcoin-dev <bitcoin-= dev@lists.linuxfoundation.org> wrote:
Good morning Jeremy,

> 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):=
>
> 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 m= aintenance (storing the output potentially forever) is lower than thei= r immediate reward in fees.
> - 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.
> - if direct relay to miner becomes popular, it is both bad for privacy= and decentralization.
> - 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)
>
> the tradeoff is if a short term immediate incentive to promote network= centralization 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-transactions.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
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
--_000_PS2P216MB108951BFE0724BD49D8EEA809DCB9PS2P216MB1089KORP_--