LORD HIS EXCELLENCY JAMES HRMH [ARCHIVE] on Nostr: 📅 Original date posted:2021-10-07 📝 Original message:Good Afternoon, Returning ...
📅 Original date posted:2021-10-07
📝 Original message: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/c2aee87a/attachment-0001.html>;
📝 Original message: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/c2aee87a/attachment-0001.html>;