public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Peter Todd <pete@petertodd.org>
To: Mike Hearn <mike@plan99.net>
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Floating fees and SPV clients
Date: Tue, 3 Dec 2013 06:37:25 -0500	[thread overview]
Message-ID: <20131203113725.GC12623@tilt> (raw)
In-Reply-To: <CANEZrP0P9NTJXs22K8-4hnLkxV7Uo+tjvWKJ8msgxiFgJW6xvg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1871 bytes --]

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@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
> 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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 490 bytes --]

  reply	other threads:[~2013-12-03 11:37 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-01 11:51 [Bitcoin-development] Floating fees and SPV clients Mike Hearn
2013-12-01 12:15 ` Andreas Schildbach
2013-12-01 13:41   ` Mike Hearn
2013-12-01 16:50     ` Andreas Schildbach
2013-12-01 17:19       ` Mike Hearn
2013-12-01 17:40         ` Andreas Schildbach
2013-12-01 17:52           ` Mike Hearn
2013-12-01 18:12         ` Peter Todd
2013-12-01 18:18           ` Mike Hearn
2013-12-01 18:37             ` Peter Todd
2013-12-02 13:54         ` Patrick Mead
2013-12-02 14:33           ` Mike Hearn
2013-12-02 14:37             ` Jeff Garzik
2013-12-02 14:44               ` Mike Hearn
2013-12-02 14:47                 ` Jeff Garzik
2013-12-03  1:40                 ` Gavin Andresen
2013-12-03 10:06                   ` Mike Hearn
2013-12-03 10:36                     ` Drak
2013-12-03 10:45                       ` Mike Hearn
2013-12-03 11:04                         ` Drak
2013-12-03 11:07                     ` Gavin Andresen
2013-12-03 11:29                       ` Mike Hearn
2013-12-03 11:37                         ` Peter Todd [this message]
2013-12-03 11:41                         ` Gavin Andresen
2013-12-03 11:46                           ` Mike Hearn
2013-12-03 11:54                             ` Gavin Andresen
2013-12-03 12:05                             ` Drak
2013-12-03 11:57                         ` Taylor Gerring
2013-12-03 12:07                           ` Peter Todd
2013-12-03 13:20                             ` Jamie McNaught
2013-12-03 13:20                           ` Mike Hearn
2013-12-03 13:48                             ` Taylor Gerring
2013-12-03 13:54                               ` Mike Hearn
2013-12-03 14:42                             ` Quinn Harris
2013-12-04  1:45                       ` Jeremy Spilman
2013-12-04 10:40                         ` Mike Hearn
2013-12-04 10:57                           ` Peter Todd
2013-12-04 11:09                             ` Mike Hearn
2013-12-04 13:06                               ` Peter Todd
2013-12-04 13:48                                 ` Mike Hearn
2013-12-04 21:51                                   ` Peter Todd
2013-12-03 11:03                   ` Peter Todd
2013-12-03 11:09                     ` Drak
2013-12-03 11:33                       ` Peter Todd
2013-12-04  5:50                   ` kjj
2013-12-03 11:31 ` Peter Todd

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20131203113725.GC12623@tilt \
    --to=pete@petertodd.org \
    --cc=bitcoin-development@lists.sourceforge.net \
    --cc=mike@plan99.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox