{"type":"rich","version":"1.0","author_name":"npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgyd","author_url":"https://nostr.ae/npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgyd","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2013-12-02\n📝 Original message:Right, as I said earlier:\n\n\"The payment protocol at least would need some notion of fee, or possibly\n(better?) the ability for a recipient to specify some inputs as well as\nsome outputs.\"\n\nHaving thought about it a bit more, I think it's better to just have a fee\nfield that lets the receiver request the sender to attach the given fee.\nThe outputs would have less value associated with them, so effectively the\nseller folds the fee into the price. If the seller is charging a round\nprice like 1 mBTC, the user sees \"1 mBTC\" as the price, even if behind the\nscenes the created tx only sends 0.99999 BTC\n\nAllowing specification of inputs seems to add too much complexity in other\ncases, like when value isn't specified at all.\n\n\nOn Mon, Dec 2, 2013 at 2:54 PM, Patrick Mead \u003cpatrick at meadia.com.au\u003e wrote:\n\n\u003e First time posting to this mailing list so feel free to ignore me if\n\u003e this is a stupid idea.\n\u003e\n\u003e\n\u003e On Mon, Dec 2, 2013 at 3:49 AM, Mike Hearn \u003cmike at plan99.net\u003e wrote:\n\u003e \u003e\n\u003e \u003e We need to get away from the notion of senders attaching fees anyway.\n\u003e This is the wrong\n\u003e \u003e way around because it’s the recipient who cares about double spending\n\u003e risk, not the sender.\n\u003e \u003e\n\u003e\n\u003e\n\u003e It seems to me that a common problem currently revolves around\n\u003e accepting transactions in\n\u003e retail scenarios, such as paying for a sandwich from Subway. A\n\u003e solution could be to give the\n\u003e vendor responsibility for setting the fee, which means they can choose\n\u003e the trade-off that works\n\u003e best for them in terms of fee size vs. speed of processing.\n\u003e\n\u003e Idea:\n\u003e Add a \"fee\" parameter to the payment URI specification.\n\u003e When processing the transaction, the customer's UI should show only\n\u003e the total price, including\n\u003e both the transfer amount and the fee. The vendor only accepts the\n\u003e transaction if the customer\n\u003e uses the right amount and fee. If the fee is too small (for example,\n\u003e the user might be using an\n\u003e older wallet and has selected a fee of zero), the vendor can issue a\n\u003e refund transaction\n\u003e immediately and tell the user to try again.\n\u003e\n\u003e Pros:\n\u003e - could easily be implemented immediately\n\u003e - old wallets would still be supported by just manually entering the\n\u003e fee as users do now\n\u003e - no greater risk of double spending on either side\n\u003e - maintains the distributed nature of the system\n\u003e - relies on humans to judge the fee (who are much less likely to\n\u003e spiral infinitely upwards)\n\u003e - flexible enough to support varying sizes of transaction and varying\n\u003e degrees of security\n\u003e\n\u003e Cons\n\u003e - requires the vendor to have sufficient understanding of Bitcoin to\n\u003e make the trade-off\n\u003e - doesn't solve the problem of selecting a fee for transactions\n\u003e between individuals/laymen\n\u003e - doesn't solve fee selection for automated transactions such as\n\u003e mixing/de/refragmentation\n\u003e\n\u003e\n\u003e Thoughts?\n\u003e\n\u003e\n\u003e ------------------------------------------------------------------------------\n\u003e Rapidly troubleshoot problems before they affect your business. Most IT\n\u003e organizations don't have a clear picture of how application performance\n\u003e affects their revenue. With AppDynamics, you get 100% visibility into your\n\u003e Java,.NET, \u0026 PHP application. Start your 15-day FREE TRIAL of AppDynamics\n\u003e Pro!\n\u003e http://pubads.g.doubleclick.net/gampad/clk?id=84349351\u0026iu=/4140/ostg.clktrk\n\u003e _______________________________________________\n\u003e Bitcoin-development mailing list\n\u003e Bitcoin-development at lists.sourceforge.net\n\u003e https://lists.sourceforge.net/lists/listinfo/bitcoin-development\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20131202/9f1e85d6/attachment.html\u003e"}