Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 1A43AC000D; Thu, 7 Oct 2021 10:35:24 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 08E19840E4; Thu, 7 Oct 2021 10:35: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 705K6-6wSPy9; Thu, 7 Oct 2021 10:35:22 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.8.0 X-Greylist: whitelisted by SQLgrey-1.8.0 Received: from KOR01-PS2-obe.outbound.protection.outlook.com (mail-ps2kor01olkn0181.outbound.protection.outlook.com [104.47.109.181]) by smtp1.osuosl.org (Postfix) with ESMTPS id 2DAC4840E2; Thu, 7 Oct 2021 10:35:21 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Ost8e90fdB80abVieUdKXnLed0TFDDWKaMPDG6HnuyHqq4L6giQvNqp45KmHtxbOe72Z5OQPiGdL/fO2MHWgsIspmb255MFdVhyFMHT62mTQ/nh7kcL1fKLOVWDPCTymsbzT086i9Vy1fquIIIc4OVId8WdW0bt3MLXiNJSKraxkE4Wbl7LmkXmxIsyHHw262Yp0G/05MvoRdTPbwDoKoyacugcTYyQKWM3UQp5pGkxz6Q+Th9wmrzLpNBB5y96/uRwzG39laz1sUriNkO21xFPwdQ2lVsJwBCyuU1u6EokAlKT1Afz0FqFMkV460RZ8EiiXkQJR7Kn6ieFs5KDOEA== 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=qMfyMgJgHV/mKsamI1Pto/89M9nZ1HjcdrD+e+sZ2Do=; b=Tn35UKOqju/wO+3WNekb7Kjvs0qe6bKwjdluMdvdyPTk0WFPreRxJFEkXPLkUduOFx3WD9YSswjcL+XJqJHlyq4MK7zu0Wytwiv5gQ1oGpjdQs+RskGryUbS+0ateFDEtPHK76ElOrhIWUswsUa4gIJWmGgIDAZpoNoV8JTaOeI38MPUEMMKwR/TQwHBIREgVChWU0jK6XFjch+fogG0E8i3EHimX2iG/NOQLOu4eZLb6HgtrNeREvfbAnyLurxrXVhTPUNcgSQiycEKGuNqCkMQ/7UJTzGvB3kpiNmVEkvSB6S4Qd8NCQrcJAPK45Im0GfdJntNNQenmE8uXBXeQw== 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 PSXP216MB0103.KORP216.PROD.OUTLOOK.COM (2603:1096:300:a::20) 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 10:35:16 +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.020; Thu, 7 Oct 2021 10:35:16 +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+l5KvHK44pgAAG2dmAACOxRg== Date: Thu, 7 Oct 2021 10:35:16 +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: 2f1aa2ed-517f-b01e-4658-a6b54a44af23 x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [r6PJ40qAfqkdVlVFphd0H0f2zDCI8oFQ] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 9e082fc9-9529-4561-5d40-08d9897e270e x-ms-traffictypediagnostic: PSXP216MB0103: x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: n24TnkoyNNQaucmUQ7hbBo7YJkJytPDyHDpqggfDwDByYRD6niKCnGjlMOONlWUvXIf386kPRLOlUAXolPxSDWS/Aq0CGeTAFmhX7KQo5IbvWZosvaEzVEwJM/xAMu0k6XynavG71IVgoJBimuF9QpTdrIrIWx6N6P7UNHipnklZr23QieNMNuJr/pzQObHzEsRp8h/a/PUVG7dURVHPxtMp0iSBSacqdl/wFqBYVJIQX4YjFoM/u3/oDQoyRwfiDX2dkKh39YJYuylfczpri5GXRuQzV0OBTDowYGR59GOSX46CEKPQLuwLODQjSTyQcMYWoQX/LiN7FSmu819dIC1BbjSXdb0cOoaxUwWivXjVd92afamgO2lOWw9vTIKGlMB/Hi/ftMncwDTDkLc4CpQAiFVyHlDsiGB8MNM8kwOuqnHe9ifSiVL7XzMwr9y15tGrTMnMusuCrK4l62KzZNtQa7519gAeZCGnxa6PHFc= x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: a1XBGUK18Bdw7PYRWSmYgqWz/J1j1vcL6mRnGWm7k7KUz9qnj4aQcpucEtuiEUG8EsUHNHESF/ibxoxlkR14v6svTvXBSlcSIXziZk5dXfRV3RKVBN62L83TLrqCcjSO7X/Fwi6tJFY/FbCLbB/cdw== x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_PS2P216MB108975E795BA99C4E9ECB0089DB19PS2P216MB1089KORP_" 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: 9e082fc9-9529-4561-5d40-08d9897e270e X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Oct 2021 10:35:16.3096 (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: PSXP216MB0103 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 10:35:24 -0000 --_000_PS2P216MB108975E795BA99C4E9ECB0089DB19PS2P216MB1089KORP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Good Afternoon, Further, if it is entirely necessary to prevent the creation of utxo's that= are considered dust, and I am not by any means convinced, then it is simpl= e to provide the most circumspect solution to transfer the value of any dus= t utxo that would be created in a transaction to the fee. I do not believe = this answer is any more than robbery of the future value of the wallet as m= y wallet must be able to keep any change but if it is must then this is the= answer. 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:34 PM To: Erik Aronesty ; ZmnSCPxj ; Bitco= in Protocol Discussion Cc: lightning-dev Subject: Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit 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_PS2P216MB108975E795BA99C4E9ECB0089DB19PS2P216MB1089KORP_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Good Afternoon,

Further, if it is entirely necessary to prevent the creation of utxo's that= are considered dust, and I am not by any means convinced, then it is simpl= e to provide the most circumspect solution to transfer the value of any dus= t utxo that would be created in a transaction to the fee. I do not believe this answer is any more than ro= bbery of the future value of the wallet as my wallet must be able to keep a= ny change but if it is must then this is the answer.

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:34 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,

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_PS2P216MB108975E795BA99C4E9ECB0089DB19PS2P216MB1089KORP_--