Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit

[LORD HIS EXCELLENCY JAMES HRMH <willtech@live.com.au>]

[-- Attachment #1: Type: text/plain, Size: 3966 bytes --]

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 coins throughout the course of minting, drafting to banks, paying to bank customers, 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 series of denominations, is adjusted.

In the case of Bitcoin, the denominations available are effectively the utxo set and there is no effective way to round the transactions without accepting 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 outputs and you could argue to distribute to all outputs as an overpayment. It is 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 email 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>; Bitcoin 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 utxo'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 current 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 expensive 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 fees for automatic utxo selection, however, perhaps consider this is valid for 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 down the process of block validation during mining. Every conceivable computerised 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 example, that the transaction fee is paid only for the first utxo inclusion in a transaction due to changes to the calculation of block-size. There are other easily plausible examples 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 email if misdelivered.



[-- Attachment #2: Type: text/html, Size: 7813 bytes --]