[Bitcoin-development] Floating fees and SPV clients
pete at petertodd.org
Tue Dec 3 11:37:25 UTC 2013
On Tue, Dec 03, 2013 at 12:29:03PM +0100, Mike Hearn wrote:
> On Tue, Dec 3, 2013 at 12:07 PM, Gavin Andresen <gavinandresen at gmail.com>wrote:
> > Making it fee-per-kilobyte is a bad idea, in my opinion; users don't care
> > how many kilobytes their transactions are, and they will just be confused
> > if they're paying for a 10mBTC burger and are asked to pay 10.00011 or
> > 9.9994 because the merchant has no idea how many kilobytes the paying
> > transaction will be.
> Wouldn't the idea be that the user always sees 10mBTC no matter what, but
> the receiver may receive less if the user decides to pay with a huge
> It may be acceptable that receivers don't always receive exactly what they
> requested, at least for person-to-business transactions. For
> person-to-person transactions of course any fee at all is confusing because
> you intuitively expect that if you send 1 mBTC, then 1 mBTC will arrive the
> other end. I wonder if we'll end up in a world where buying things from
> shops involves paying fees, and (more occasional?) person-to-person
> transactions tend to be free and people just understand that the money
> isn't going to be spendable for a while. Or alternatively that wallets let
> you override the safeguards on spending unconfirmed coins when the user is
> sure that they trust the sender.
Person-to-person payments are an *excellent* argument for keeping fees
visible to end-users; people will pay other people commonly in Bitcoin
and they will be very confused if those transactions act weirdly
differently than payments to merchants.
NAK on unconfirmed overrides - if something goes wrong even by accident
it just makes fixing the problem much harder and less intuitive.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 490 bytes
Desc: Digital signature
More information about the bitcoin-dev