On Tue, Dec 03, 2013 at 12:29:03PM +0100, Mike Hearn wrote: > On Tue, Dec 3, 2013 at 12:07 PM, Gavin Andresen 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 > transaction? > > 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. -- 'peter'[:-1]@petertodd.org 000000000000000f9102d27cfd61ea9e8bb324593593ca3ce6ba53153ff251b3