<oembed><type>rich</type><version>1.0</version><author_name>npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwet</author_name><author_url>https://nostr.ae/npub1f2nvlx49er5c7sqa43src6ssyp6snd4qwvtkwm5avc2l84cs84esecrwet</author_url><provider_name>njump</provider_name><provider_url>https://nostr.ae</provider_url><html>📅 Original date posted:2018-01-23&#xA;📝 Original message:On Mon, Jan 22, 2018 at 8:00 PM, Peter Todd via bitcoin-dev&#xA;&lt;bitcoin-dev at lists.linuxfoundation.org&gt; wrote:&#xA;&gt; Most transactions don&#39;t have change?! Under what circumstance? For most&#xA;&gt; use-cases the reverse is true: almost all all transactions have change, because&#xA;&gt; it&#39;s rare for the inputs to exactly math the requested payment.&#xA;&#xA;It&#39;s quite easy to get no change with a not-dumb algorithm selecting&#xA;coins if you have a decent number of outputs well under the value&#xA;you&#39;re paying.&#xA;&#xA;The number of ways n choose m combines grows exponentially, and you&#xA;only need to get close enough over the right value so that you&#39;re&#xA;paying excess fees equal or less than the cost of the change (which&#xA;should include the current cost output itself as well as estimated&#xA;cost of the future signature to spend it).&#xA;&#xA;Achow101 and Murch have code to implement an efficient algorithm for&#xA;finding these solutions for Bitcoin core which will hopefully get in&#xA;soon.</html></oembed>