The merchant wants to include a fee to
ensure the transaction is confirmed which is dependent on the fee
per kilobyte, but they don't want to pay unexpectedly high fees.
So what about including a min_fee_per_kilobyte and a max_fee in
PaymentDetails describing what fees the merchant will pay. The
sender would be expected to respect the min_fee_per_kilobyte but
if the result exceeds max_fee the sender would be agreeing to pay
the extra fee (exterior fees). The sender might also agree to pay
fees in excess of min_fee_per_kilobyte.
The sender would deduct the interior or merchant fees from the
first output.
The UI could show the payment "price" which would match the sum of
original outputs. It would show the merchant fees (interior) and
sender fees (exterior) if there are any. The UI should always
show fees so users learn to expect them for all transactions.
This should allow the merchant to pay fees in most cases while not
having to pay excessive fees if the sender wants to use some large
transaction. If max_fee is 0 the sender would be expected to pay
all fees.
On 12/03/2013 10:20 AM, Mike Hearn wrote:
------------------------------------------------------------------------------
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