public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Mike Hearn <mike@plan99•net>
To: Patrick Mead <patrick@meadia•com.au>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Floating fees and SPV clients
Date: Mon, 2 Dec 2013 15:33:46 +0100	[thread overview]
Message-ID: <CANEZrP1C=Hc-3f-rqQ+wYrPn-eUj52HjN+qRQdJMWvnP+dkK=Q@mail.gmail.com> (raw)
In-Reply-To: <CAGLkj4C9fyAX1CnB0oZH3BwLRQp6WOo9kLUqDhRUSA6y3LxYvg@mail.gmail.com>

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

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
>

[-- Attachment #2: Type: text/html, Size: 4858 bytes --]

  reply	other threads:[~2013-12-02 14:33 UTC|newest]

Thread overview: 46+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-01 11:51 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 [this message]
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
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='CANEZrP1C=Hc-3f-rqQ+wYrPn-eUj52HjN+qRQdJMWvnP+dkK=Q@mail.gmail.com' \
    --to=mike@plan99$(echo .)net \
    --cc=bitcoin-development@lists$(echo .)sourceforge.net \
    --cc=patrick@meadia$(echo .)com.au \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
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