path: root/53/4a41dfcddcfddf979925867441f27618936d99

Return-Path: <willtech@live.com.au>
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 <willtech@live.com.au>
To: Erik Aronesty <erik@q32.com>, ZmnSCPxj <ZmnSCPxj@protonmail.com>, Bitcoin
 Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
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: <PS2P216MB108975E795BA99C4E9ECB0089DB19@PS2P216MB1089.KORP216.PROD.OUTLOOK.COM>
References: <CAD5xwhjFBjvkMKev_6HFRuRGcZUi7WjO5d963GNXWN4n-06Pqg@mail.gmail.com>
 <20210808215101.wuaidu5ww63ajx6h@ganymede>
 <MkPutJpff5rqUxXFQrEyHZl6Iz0DfrJU_-BQD-y0El65GQFnj7igVfmWU79fPCtiFztUYl4ofzrqeaN0HFMB45YPErY9rYY7_h1XkuTMfvc=@wuille.net>
 <CAJowKgKt=yYdNOYYNsWh7FJ2EH7rz0bd2EjUjmyA=cA6k5cvUQ@mail.gmail.com>
 <BtaljKLqpe75GB6pHEPQMF6_L-hBaE0ZCBGaXrUfnHRYeEbCqFWZ12DaMRm5jEADceL3uPfCiL-WU9MOZJ_m54Zi3Pzu0vSFN3nQvuSKvBM=@protonmail.com>
 <PS2P216MB10896EAD8C2FE35F2A897C4B9DB19@PS2P216MB1089.KORP216.PROD.OUTLOOK.COM>
 <PS2P216MB1089B819664D10559BF04F679DB19@PS2P216MB1089.KORP216.PROD.OUTLOOK.COM>
In-Reply-To: <PS2P216MB1089B819664D10559BF04F679DB19@PS2P216MB1089.KORP216.PROD.OUTLOOK.COM>
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 <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: 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 <willtech@live.com.au>
Sent: Thursday, 7 October 2021 7:34 PM
To: Erik Aronesty <erik@q32.com>; ZmnSCPxj <ZmnSCPxj@protonmail.com>; Bitco=
in Protocol Discussion <bitcoin-dev@lists.linuxfoundation.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 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 <willtech@live.com.au>
Sent: Thursday, 7 October 2021 7:17 PM
To: Erik Aronesty <erik@q32.com>; ZmnSCPxj <ZmnSCPxj@protonmail.com>; Bitco=
in Protocol Discussion <bitcoin-dev@lists.linuxfoundation.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 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

<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);">
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.<br>
</div>
<div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
 color: rgb(0, 0, 0);">
<br>
</div>
<div id=3D"Signature">
<div>
<div></div>
<div></div>
<div></div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
KING JAMES HRMH
<div>Great British Empire</div>
<div><br>
</div>
<div>Regards,</div>
<div>The Australian</div>
<div>LORD HIS EXCELLENCY JAMES HRMH (&amp; HMRH)</div>
<div>of Hougun Manor &amp; Glencoe &amp; British Empire</div>
<div>MR. Damian A. James Williamson</div>
<div>Wills</div>
<div><br>
</div>
<div>et al.</div>
<div><br>
</div>
<div>&nbsp;</div>
<div>Willtech</div>
<div>www.willtech.com.au</div>
<div>www.go-overt.com</div>
<div>duigco.org DUIGCO API</div>
<div>and other projects</div>
<div>&nbsp;</div>
<div><br>
</div>
<div>m. 0487135719</div>
<div>f. +61261470192</div>
<div><br>
</div>
<div><br>
</div>
This email does not constitute a general advice. Please disregard this emai=
l if misdelivered.</div>
</div>
</div>
</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> LORD HIS EXCELLENCY=
 JAMES HRMH &lt;willtech@live.com.au&gt;<br>
<b>Sent:</b> Thursday, 7 October 2021 7:34 PM<br>
<b>To:</b> Erik Aronesty &lt;erik@q32.com&gt;; ZmnSCPxj &lt;ZmnSCPxj@proton=
mail.com&gt;; Bitcoin Protocol Discussion &lt;bitcoin-dev@lists.linuxfounda=
tion.org&gt;<br>
<b>Cc:</b> lightning-dev &lt;lightning-dev@lists.linuxfoundation.org&gt;<br=
>
<b>Subject:</b> Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit</=
font>
<div>&nbsp;</div>
</div>
<div dir=3D"ltr">
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
Good Afternoon,</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
<br>
</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
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.<br>
</div>
<div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
<br>
</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
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.
<br>
</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
<br>
</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
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.<br>
</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
<br>
</div>
<div id=3D"x_Signature">
<div>
<div></div>
<div></div>
<div></div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
<div>KING JAMES HRMH
<div>Great British Empire</div>
<div><br>
</div>
<div>Regards,</div>
<div>The Australian</div>
<div>LORD HIS EXCELLENCY JAMES HRMH (&amp; HMRH)</div>
<div>of Hougun Manor &amp; Glencoe &amp; British Empire</div>
<div>MR. Damian A. James Williamson</div>
<div>Wills</div>
<div><br>
</div>
<div>et al.</div>
<div><br>
</div>
<div>&nbsp;</div>
<div>Willtech</div>
<div>www.willtech.com.au</div>
<div>www.go-overt.com</div>
<div>duigco.org DUIGCO API</div>
<div>and other projects</div>
<div>&nbsp;</div>
<div><br>
</div>
<div>m. 0487135719</div>
<div>f. +61261470192</div>
<div><br>
</div>
<div><br>
</div>
This email does not constitute a general advice. Please disregard this emai=
l if misdelivered.<br>
</div>
<div><br>
</div>
</div>
</div>
</div>
</div>
<div>
<div id=3D"x_appendonsend"></div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
<br>
</div>
<hr tabindex=3D"-1" style=3D"display:inline-block; width:98%">
<div id=3D"x_divRplyFwdMsg" dir=3D"ltr"><font style=3D"font-size:11pt" face=
=3D"Calibri, sans-serif" color=3D"#000000"><b>From:</b> LORD HIS EXCELLENCY=
 JAMES HRMH &lt;willtech@live.com.au&gt;<br>
<b>Sent:</b> Thursday, 7 October 2021 7:17 PM<br>
<b>To:</b> Erik Aronesty &lt;erik@q32.com&gt;; ZmnSCPxj &lt;ZmnSCPxj@proton=
mail.com&gt;; Bitcoin Protocol Discussion &lt;bitcoin-dev@lists.linuxfounda=
tion.org&gt;<br>
<b>Cc:</b> lightning-dev &lt;lightning-dev@lists.linuxfoundation.org&gt;<br=
>
<b>Subject:</b> Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit</=
font>
<div>&nbsp;</div>
</div>
<div dir=3D"ltr">
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
Good Afternoon,</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
<br>
</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
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.
<u>With obvious intent, the wallet should avoid creating utxo's below the c=
urrent dust limit at the time the transaction is created
<b>but it cannot guarantee it</b>.</u></div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
<br>
</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
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,
<u>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<b> it is in every example 'my money' an=
d I can spend some of it if I decide.</b><br>
</u></div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
<br>
</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
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.
<u>The actual answer to this genuine business concern of database speed is =
to <b>
build a faster database.</b></u></div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
<br>
</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
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. <u>There are other easily plausible example=
s where the inclusion of what is today considered
<b>dust may not be ill-considered.</b></u></div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
<br>
</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
KING JAMES HRMH
<div>Great British Empire</div>
<div><br>
</div>
<div>Regards,</div>
<div>The Australian</div>
<div>LORD HIS EXCELLENCY JAMES HRMH (&amp; HMRH)</div>
<div>of Hougun Manor &amp; Glencoe &amp; British Empire</div>
<div>MR. Damian A. James Williamson</div>
<div>Wills</div>
<div><br>
</div>
<div>et al.</div>
<div><br>
</div>
<div>&nbsp;</div>
<div>Willtech</div>
<div>www.willtech.com.au</div>
<div>www.go-overt.com</div>
<div>duigco.org DUIGCO API</div>
<div>and other projects</div>
<div>&nbsp;</div>
<div><br>
</div>
<div>m. 0487135719</div>
<div>f. +61261470192</div>
<div><br>
</div>
<div><br>
</div>
This email does not constitute a general advice. Please disregard this emai=
l if misdelivered.<br>
</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
<br>
</div>
<div style=3D"font-family:Calibri,Helvetica,sans-serif; font-size:12pt; col=
or:rgb(0,0,0)">
<br>
</div>
</div>
</div>
</div>
</div>
</body>
</html>

--_000_PS2P216MB108975E795BA99C4E9ECB0089DB19PS2P216MB1089KORP_--