Right, as I said earlier:

"The payment protocol at least would need some notion of fee, or possibly (better?) the ability for a recipient to specify some inputs as well as some outputs."

Having thought about it a bit more, I think it's better to just have a fee field that lets the receiver request the sender to attach the given fee. The outputs would have less value associated with them, so effectively the seller folds the fee into the price. If the seller is charging a round price like 1 mBTC, the user sees "1 mBTC" as the price, even if behind the scenes the created tx only sends 0.99999 BTC

Allowing specification of inputs seems to add too much complexity in other cases, like when value isn't specified at all.


On Mon, Dec 2, 2013 at 2:54 PM, Patrick Mead <patrick@meadia.com.au> wrote:
First time posting to this mailing list so feel free to ignore me if
this is a stupid idea.


On Mon, Dec 2, 2013 at 3:49 AM, Mike Hearn <mike@plan99.net> wrote:
>
> We need to get away from the notion of senders attaching fees anyway. This is the wrong
> way around because it’s the recipient who cares about double spending risk, not the sender.
>


It seems to me that a common problem currently revolves around
accepting transactions in
retail scenarios, such as paying for a sandwich from Subway. A
solution could be to give the
vendor responsibility for setting the fee, which means they can choose
the trade-off that works
best for them in terms of fee size vs. speed of processing.

Idea:
Add a "fee" parameter to the payment URI specification.
When processing the transaction, the customer's UI should show only
the total price, including
both the transfer amount and the fee. The vendor only accepts the
transaction if the customer
uses the right amount and fee. If the fee is too small (for example,
the user might be using an
older wallet and has selected a fee of zero), the vendor can issue a
refund transaction
immediately and tell the user to try again.

Pros:
- could easily be implemented immediately
- old wallets would still be supported by just manually entering the
fee as users do now
- no greater risk of double spending on either side
- maintains the distributed nature of the system
- relies on humans to judge the fee (who are much less likely to
spiral infinitely upwards)
- flexible enough to support varying sizes of transaction and varying
degrees of security

Cons
- requires the vendor to have sufficient understanding of Bitcoin to
make the trade-off
- doesn't solve the problem of selecting a fee for transactions
between individuals/laymen
- doesn't solve fee selection for automated transactions such as
mixing/de/refragmentation


Thoughts?

------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349351&iu=/4140/ostg.clktrk
_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development