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.


_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Reply via email to