<oembed><type>rich</type><version>1.0</version><author_name>npub1lekc3nrsuh2zmqda70jx8mspqyd5mftar9zvd5lwxl9fszagstfq7q4t7s</author_name><author_url>https://nostr.ae/npub1lekc3nrsuh2zmqda70jx8mspqyd5mftar9zvd5lwxl9fszagstfq7q4t7s</author_url><provider_name>njump</provider_name><provider_url>https://nostr.ae</provider_url><html>📅 Original date posted:2013-12-02&#xA;📝 Original message:First time posting to this mailing list so feel free to ignore me if&#xA;this is a stupid idea.&#xA;&#xA;&#xA;On Mon, Dec 2, 2013 at 3:49 AM, Mike Hearn &lt;mike at plan99.net&gt; wrote:&#xA;&gt;&#xA;&gt; We need to get away from the notion of senders attaching fees anyway. This is the wrong&#xA;&gt; way around because it’s the recipient who cares about double spending risk, not the sender.&#xA;&gt;&#xA;&#xA;&#xA;It seems to me that a common problem currently revolves around&#xA;accepting transactions in&#xA;retail scenarios, such as paying for a sandwich from Subway. A&#xA;solution could be to give the&#xA;vendor responsibility for setting the fee, which means they can choose&#xA;the trade-off that works&#xA;best for them in terms of fee size vs. speed of processing.&#xA;&#xA;Idea:&#xA;Add a &#34;fee&#34; parameter to the payment URI specification.&#xA;When processing the transaction, the customer&#39;s UI should show only&#xA;the total price, including&#xA;both the transfer amount and the fee. The vendor only accepts the&#xA;transaction if the customer&#xA;uses the right amount and fee. If the fee is too small (for example,&#xA;the user might be using an&#xA;older wallet and has selected a fee of zero), the vendor can issue a&#xA;refund transaction&#xA;immediately and tell the user to try again.&#xA;&#xA;Pros:&#xA;- could easily be implemented immediately&#xA;- old wallets would still be supported by just manually entering the&#xA;fee as users do now&#xA;- no greater risk of double spending on either side&#xA;- maintains the distributed nature of the system&#xA;- relies on humans to judge the fee (who are much less likely to&#xA;spiral infinitely upwards)&#xA;- flexible enough to support varying sizes of transaction and varying&#xA;degrees of security&#xA;&#xA;Cons&#xA;- requires the vendor to have sufficient understanding of Bitcoin to&#xA;make the trade-off&#xA;- doesn&#39;t solve the problem of selecting a fee for transactions&#xA;between individuals/laymen&#xA;- doesn&#39;t solve fee selection for automated transactions such as&#xA;mixing/de/refragmentation&#xA;&#xA;&#xA;Thoughts?</html></oembed>