path: root/34/06302fdb826aef810e0a533420cea134c6d620

Return-Path: <willtech@live.com.au>
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 <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+l5KvHK44pgAAG2dk=
Date: Thu, 7 Oct 2021 08:34:17 +0000
Message-ID: <PS2P216MB1089B819664D10559BF04F679DB19@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>
In-Reply-To: <PS2P216MB10896EAD8C2FE35F2A897C4B9DB19@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: 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 <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 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 <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_PS2P216MB1089B819664D10559BF04F679DB19PS2P216MB1089KORP_
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);">
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;=
 color: rgb(0, 0, 0);">
<br>
</div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
 color: 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;=
 color: rgb(0, 0, 0);">
<br>
</div>
<div style=3D"font-family: Calibri, Helvetica, sans-serif; font-size: 12pt;=
 color: 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;=
 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)">
</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"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"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>
</body>
</html>

--_000_PS2P216MB1089B819664D10559BF04F679DB19PS2P216MB1089KORP_--