Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [140.211.166.138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 9B360C000D; Thu, 7 Oct 2021 08:34:24 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 7D3CE83E64; Thu, 7 Oct 2021 08:34:24 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=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 smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id biZp2lsj1yyH; Thu, 7 Oct 2021 08:34:22 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from KOR01-SL2-obe.outbound.protection.outlook.com (mail-sl2kor01olkn0161.outbound.protection.outlook.com [104.47.108.161]) by smtp1.osuosl.org (Postfix) with ESMTPS id 358AA83D9D; Thu, 7 Oct 2021 08:34:22 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=XeHVlN7NvMN4uxdT6k9cRVXwDHWFjJOD2xOj/QNQex29d8Qsp3c4ZgHeDVLu6xCof85BVMySBIz6NLaL1zUTtrETyclgA/d32oXMFSA5aNfTpFmYTwgyAJPXCfG8O5oFFIMNrngPxY+x2L3aZBV5TWHJ1eqThv/lOT1pKNXF9nUf2heW43jnZdvHncKdJRrwhf12TEmoJSOi9qRERa7T17dVBJYpLgGFNmy4tkndUzWnyDTJNM9m33unXjLag57Wki+QKwyBSU9/tW89L6B0pGNdyvAUzRVdJHXuEow+WKdYznYEOg0sOsTUfCMejdtdI+VAuoWdcMmCKzUaz+Ls7Q== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=JNkyQFchdvNK0h1nFj9RgcNz7qNgkwsHSLmmdGW9aHo=; b=kaPGXyI0BBE2nrqQrf0K/IrGVJM0MIRW1BpDggSyRXwhBr1yZWj4W15I7Tax63bKlg5c35mi7gw+kdhq4g6n5cr5UZGDcEsiefkqQPqVYTT1ruCRHKjbhfvM++VOtV60WUGBs8ruIrxSXS/aP0yopGz2jDyq5Sth265C41q36JZ3PqB6iil9CFopgVSrLns+uoMAO2H166KguTYqgqnKv1F9WZiFbwucCmC1ba8aXNTVSjC+JPxeZxEhc7TKadrh1Wy40S5kf5yeMfe1mm496aWOHTzOJJ++wqpkh8DGMfzV/95oVCsklQr1c1lo2HmN6HCRlXlKMnW0oFOXMmE15A== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none Received: from PS2P216MB1089.KORP216.PROD.OUTLOOK.COM (2603:1096:301:52::11) by PS2P216MB1010.KORP216.PROD.OUTLOOK.COM (2603:1096:301:53::6) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4587.18; Thu, 7 Oct 2021 08:34:17 +0000 Received: from PS2P216MB1089.KORP216.PROD.OUTLOOK.COM ([fe80::ccbf:fb52:3f6b:fbda]) by PS2P216MB1089.KORP216.PROD.OUTLOOK.COM ([fe80::ccbf:fb52:3f6b:fbda%8]) with mapi id 15.20.4587.019; Thu, 7 Oct 2021 08:34:17 +0000 From: LORD HIS EXCELLENCY JAMES HRMH To: Erik Aronesty , ZmnSCPxj , Bitcoin Protocol Discussion Thread-Topic: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit Thread-Index: AQHXuzcgB3XZYzD9l0SU8Sb0t5+l5KvHK44pgAAG2dk= Date: Thu, 7 Oct 2021 08:34:17 +0000 Message-ID: References: <20210808215101.wuaidu5ww63ajx6h@ganymede> In-Reply-To: Accept-Language: en-AU, en-US Content-Language: en-AU X-MS-Has-Attach: X-MS-TNEF-Correlator: suggested_attachment_session_id: 82ebfd6f-c875-db58-8788-1bf72f836122 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [Uk0fLGmtbpDGBZhM5KmQgd02T8NVo1E3] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: baf16224-9e8e-471b-350e-08d9896d4078 x-ms-traffictypediagnostic: PS2P216MB1010: x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: T7orZgpNelFhyZnC3JFgfCMovTMtDtZpcRRrBbarKPiiMiSbul3T6mNhPH083+J5FIHhQ3RHGrGKiiBZGIF1yzgFzsDcauETi0dWveTuRS2SbKClPfSC4EXZkwdhxkDWITvg+ApHaU7/oofx/J39K5gJYiSZ4t9GrgD9oz6Psx/4fuQVS7IVXiHdriALHHNW70inrjRzSJeoJpFP8sCaY9EkGBWc7h7kd/h0Hs/+nr3ya6l0XB7NamBAQgH0k29tIFIK1v0NOqB8A+6H7qwl6JE5JOXACVW9R6UBnLcFybABC8VRayf/ZGt6RENn0EetxSEMA7UZ9VLuhMM5OcZD/LabWQc2Y3nTbE9slYMf6CNhqIS/9ybKVKufyzNdsJXdGu014nOBiFxXvE+ObQJ4r8cirjJlo5qrqDEtDF2bxvFmSoBMH38BTXGQoBtS9BuFiToS072pBjgncZxbOxHhIu+STXv6q4UvpP5LtFlqM74= x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: HoJgfs1lqAEjnu/hGvs9fkW1cidgBkRW8Lv7EeDbivlshGV0RbVz2tWt5xGt00bbkTNjZJpxHCCrv7kPOoERZAPgPVSV8OZ9jkKOVWQTRcuZlXDwdytUwXbL7Ev2jw52oGz+qB+brd2KgAAQGxdceQ== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_PS2P216MB1089B819664D10559BF04F679DB19PS2P216MB1089KORP_" MIME-Version: 1.0 X-OriginatorOrg: sct-15-20-3174-20-msonline-outlook-af45a.templateTenant X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: PS2P216MB1089.KORP216.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: baf16224-9e8e-471b-350e-08d9896d4078 X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Oct 2021 08:34:17.4760 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted 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: PS2P216MB1010 X-Mailman-Approved-At: Sat, 09 Oct 2021 12:36:19 +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: Thu, 07 Oct 2021 08:34:24 -0000 --_000_PS2P216MB1089B819664D10559BF04F679DB19PS2P216MB1089KORP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Good Afternoon, The underlying consideration is the same concerning the handling of 1c and = 2c coins in an economy. Although you may argue the cost of counting those c= oins throughout the course of minting, drafting to banks, paying to bank cu= stomers, including in change, and at every handling counting, is less than = the value of those coins, hpwever, the solution in traditional currency is = to round the value of the transaction either per line of goods or per total= before calculating the Grand Total, in which case the payment either from = a non-utxo set of accumulation in a traditional account or, from a known se= ries of denominations, is adjusted. In the case of Bitcoin, the denominations available are effectively the utx= o set and there is no effective way to round the transactions without accep= ting overpayments as valid, and with what consideration, in which case the = protocol may avoid creating dust in change by sending the additional rounde= d amount that would otherwise be dust to the recipient. I suppose that this gets difficult where the transaction has multiple outpu= ts and you could argue to distribute to all outputs as an overpayment. It i= s the same effectively as rounding to 10c. 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 duigco.org DUIGCO API and other projects m. 0487135719 f. +61261470192 This email does not constitute a general advice. Please disregard this emai= l if misdelivered. ________________________________ From: LORD HIS EXCELLENCY JAMES HRMH Sent: Thursday, 7 October 2021 7:17 PM To: Erik Aronesty ; ZmnSCPxj ; Bitco= in Protocol Discussion Cc: lightning-dev Subject: Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit Good Afternoon, Returning to this subject, there should be no restriction to the value of u= txo's that keep in one's own wallet as change can be created in any value. = With obvious intent, the wallet should avoid creating utxo's below the curr= ent dust limit at the time the transaction is created but it cannot guarant= ee it. The wallet should avoid including utxo's that by weight sat/KB are more exp= ensive to include that their value at the time a transaction is created, ie= . do not include utxo's in a transaction that lower the input value after f= ees for automatic utxo selection, however, perhaps consider this is valid f= or manual utxo selection since it is in every example 'my money' and I can = spend some of it if I decide. There is no discipline in complaining that the dust set of utxo's slows dow= n the process of block validation during mining. Every conceivable computer= ised business bears the expense of the cost of a database transaction. The = actual answer to this genuine business concern of database speed is to buil= d a faster database. It is correct knowledge to know that the Bitcoin protocol cannot speculate = as to the future but we can. The case exists where it is conceivable for ex= ample, that the transaction fee is paid only for the first utxo inclusion i= n a transaction due to changes to the calculation of block-size. There are = other easily plausible examples where the inclusion of what is today consid= ered dust may not be ill-considered. 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 duigco.org DUIGCO API and other projects m. 0487135719 f. +61261470192 This email does not constitute a general advice. Please disregard this emai= l if misdelivered. --_000_PS2P216MB1089B819664D10559BF04F679DB19PS2P216MB1089KORP_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Good Afternoon,

The underlying consideration is the same concerning the handling of 1c and = 2c coins in an economy. Although you may argue the cost of counting those c= oins throughout the course of minting, drafting to banks, paying to bank cu= stomers, including in change, and at every handling counting, is less than the value of those coins, hpwever= , the solution in traditional currency is to round the value of the transac= tion either per line of goods or per total before calculating the Grand Tot= al, in which case the payment either from a non-utxo set of accumulation in a traditional account or, from a kn= own series of denominations, is adjusted.

In the case of Bitcoin, the denominations available are effectively the utx= o set and there is no effective way to round the transactions without accep= ting overpayments as valid, and with what consideration, in which case the = protocol may avoid creating dust in change by sending the additional rounded amount that would otherwise be= dust to the recipient.

I suppose that this gets difficult where the transaction has multiple outpu= ts and you could argue to distribute to all outputs as an overpayment. It i= s the same effectively as rounding to 10c.

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
duigco.org DUIGCO API
and other projects
 

m. 0487135719
f. +61261470192


This email does not constitute a general advice. Please disregard this emai= l if misdelivered.


From: LORD HIS EXCELLENCY= JAMES HRMH <willtech@live.com.au>
Sent: Thursday, 7 October 2021 7:17 PM
To: Erik Aronesty <erik@q32.com>; ZmnSCPxj <ZmnSCPxj@proton= mail.com>; Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfounda= tion.org>
Cc: lightning-dev <lightning-dev@lists.linuxfoundation.org> Subject: Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit
 
Good Afternoon,

Returning to this subject, there should be no restriction to the value of u= txo's that keep in one's own wallet as change can be created in any value. With obvious intent, the wallet should avoid creating utxo's below the c= urrent dust limit at the time the transaction is created but it cannot guarantee it.

The wallet should avoid including utxo's that by weight sat/KB are more exp= ensive to include that their value at the time a transaction is created, ie. do not include utxo's in a transaction that lower the input value af= ter fees for automatic utxo selection, however, perhaps consider this is va= lid for manual utxo selection since it is in every example 'my money' an= d I can spend some of it if I decide.

There is no discipline in complaining that the dust set of utxo's slows dow= n the process of block validation during mining. Every conceivable computer= ised business bears the expense of the cost of a database transaction. The actual answer to this genuine business concern of database speed is = to build a faster database.

It is correct knowledge to know that the Bitcoin protocol cannot speculate = as to the future but we can. The case exists where it is conceivable for ex= ample, that the transaction fee is paid only for the first utxo inclusion i= n a transaction due to changes to the calculation of block-size. There are other easily plausible example= s where the inclusion of what is today considered dust may not be ill-considered.

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
duigco.org DUIGCO API
and other projects
 

m. 0487135719
f. +61261470192


This email does not constitute a general advice. Please disregard this emai= l if misdelivered.


--_000_PS2P216MB1089B819664D10559BF04F679DB19PS2P216MB1089KORP_--