LORD HIS EXCELLENCY JAMES HRMH [ARCHIVE] on Nostr: 📅 Original date posted:2021-10-07 📝 Original message:Good Afternoon, Further, ...
📅 Original date posted:2021-10-07
📝 Original message: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 simple to provide the most circumspect solution to transfer the value of any dust 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 my 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 email if misdelivered.
________________________________
From: LORD HIS EXCELLENCY JAMES HRMH <willtech at live.com.au>
Sent: Thursday, 7 October 2021 7:34 PM
To: Erik Aronesty <erik at q32.com>; ZmnSCPxj <ZmnSCPxj at protonmail.com>; Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org>
Cc: lightning-dev <lightning-dev at 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 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 at live.com.au>
Sent: Thursday, 7 October 2021 7:17 PM
To: Erik Aronesty <erik at q32.com>; ZmnSCPxj <ZmnSCPxj at protonmail.com>; Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org>
Cc: lightning-dev <lightning-dev at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211007/ad09e939/attachment.html>;
📝 Original message: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 simple to provide the most circumspect solution to transfer the value of any dust 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 my 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 email if misdelivered.
________________________________
From: LORD HIS EXCELLENCY JAMES HRMH <willtech at live.com.au>
Sent: Thursday, 7 October 2021 7:34 PM
To: Erik Aronesty <erik at q32.com>; ZmnSCPxj <ZmnSCPxj at protonmail.com>; Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org>
Cc: lightning-dev <lightning-dev at 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 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 at live.com.au>
Sent: Thursday, 7 October 2021 7:17 PM
To: Erik Aronesty <erik at q32.com>; ZmnSCPxj <ZmnSCPxj at protonmail.com>; Bitcoin Protocol Discussion <bitcoin-dev at lists.linuxfoundation.org>
Cc: lightning-dev <lightning-dev at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20211007/ad09e939/attachment.html>;