<oembed><type>rich</type><version>1.0</version><author_name>npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgyd</author_name><author_url>https://nostr.ae/npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgyd</author_url><provider_name>njump</provider_name><provider_url>https://nostr.ae</provider_url><html>📅 Original date posted:2013-12-03&#xA;📝 Original message:On Tue, Dec 3, 2013 at 11:36 AM, Drak &lt;drak at zikula.org&gt; wrote:&#xA;&#xA;&gt; I dont like the idea of putting the min fee in the hands of the receiver.&#xA;&gt; Seems like that will work against the best interests of senders in the long&#xA;&gt; run.&#xA;&gt;&#xA;&#xA;Senders have no interest in ever attaching any kind of fee, which is one&#xA;reason we explored child-pays-for-parent for a while. It&#39;s not the sender&#xA;who cares about double spending risk. Left to their own devices, all&#xA;senders would always attach no fee at all (or rather: whatever the min was&#xA;to get the transaction relayed to the merchant).&#xA;&#xA;However, receivers do want a fee attached, and ideally we would do this&#xA;without redundant transactions. Hence, receivers asking senders to attach a&#xA;fee and effectively folding it into the price that is paid. That is, if you&#xA;go into a restaurant and the menu says &#34;Burger: 10mBTC&#34; then when you come&#xA;to pay, what you see on your phone screen is 10mBTC. The fact that actually&#xA;the shop with receiver 9.9mBTC and the tx fee is 0.1mBTC is hidden in the&#xA;user interface - creating a situation like many others, where receivers eat&#xA;a transaction cost. For instance in Europe sales taxes are included in the&#xA;price, not attached separately later.&#xA;&#xA;There&#39;s no need to trust the vendor. If a vendor asks for a ridiculously&#xA;high tx fee, it will just surface as uncompetitively priced goods/services.&#xA;Buyers will go elsewhere.&#xA;&#xA;&#xA;&gt; Why not try a different path of calculating the min fee like difficulty&#xA;&gt; retarget. You can analyse the last 2016 blocks to find the average fee&#xA;&gt; accepted per kb (which would include transactions that were included&#xA;&gt; without fees) and then write that into the block as a soft recommendation&#xA;&gt; that wallets could use in the UI. This way the price can vary up and down&#xA;&gt; according to what people were willing to spend on fees and miners willing&#xA;&gt; to accept.&#xA;&gt;&#xA;&#xA;That&#39;s what fee estimation does, essentially, minus the encoding into&#xA;blocks. Once you start getting miners telling people what fees are directly&#xA;you run into cases where they might try to lie about their behaviour or&#xA;otherwise influence the average. Querying all nodes avoids that problem.&#xA;-------------- next part --------------&#xA;An HTML attachment was scrubbed...&#xA;URL: &lt;http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131203/ea2876a4/attachment.html&gt;</html></oembed>