From: Mike Hearn <mike@plan99•net>
To: Drak <drak@zikula•org>
Cc: Bitcoin Dev <bitcoin-development@lists•sourceforge.net>
Subject: Re: [Bitcoin-development] Floating fees and SPV clients
Date: Tue, 3 Dec 2013 11:45:33 +0100 [thread overview]
Message-ID: <CANEZrP2iQ3P813qz9KL2R3WBTYpVq4AuL1xrfnwt5ay8Tk1oxw@mail.gmail.com> (raw)
In-Reply-To: <CANAnSg2kH+OeypDARUKyDTUmq26PiK2_U45wGaUOGTnkXj6jjA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2138 bytes --]
On Tue, Dec 3, 2013 at 11:36 AM, Drak <drak@zikula•org> wrote:
> I dont like the idea of putting the min fee in the hands of the receiver.
> Seems like that will work against the best interests of senders in the long
> run.
>
Senders have no interest in ever attaching any kind of fee, which is one
reason we explored child-pays-for-parent for a while. It's not the sender
who cares about double spending risk. Left to their own devices, all
senders would always attach no fee at all (or rather: whatever the min was
to get the transaction relayed to the merchant).
However, receivers do want a fee attached, and ideally we would do this
without redundant transactions. Hence, receivers asking senders to attach a
fee and effectively folding it into the price that is paid. That is, if you
go into a restaurant and the menu says "Burger: 10mBTC" then when you come
to pay, what you see on your phone screen is 10mBTC. The fact that actually
the shop with receiver 9.9mBTC and the tx fee is 0.1mBTC is hidden in the
user interface - creating a situation like many others, where receivers eat
a transaction cost. For instance in Europe sales taxes are included in the
price, not attached separately later.
There's no need to trust the vendor. If a vendor asks for a ridiculously
high tx fee, it will just surface as uncompetitively priced goods/services.
Buyers will go elsewhere.
> Why not try a different path of calculating the min fee like difficulty
> retarget. You can analyse the last 2016 blocks to find the average fee
> accepted per kb (which would include transactions that were included
> without fees) and then write that into the block as a soft recommendation
> that wallets could use in the UI. This way the price can vary up and down
> according to what people were willing to spend on fees and miners willing
> to accept.
>
That's what fee estimation does, essentially, minus the encoding into
blocks. Once you start getting miners telling people what fees are directly
you run into cases where they might try to lie about their behaviour or
otherwise influence the average. Querying all nodes avoids that problem.
[-- Attachment #2: Type: text/html, Size: 2764 bytes --]
next prev parent reply other threads:[~2013-12-03 10:45 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
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 [this message]
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=CANEZrP2iQ3P813qz9KL2R3WBTYpVq4AuL1xrfnwt5ay8Tk1oxw@mail.gmail.com \
--to=mike@plan99$(echo .)net \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=drak@zikula$(echo .)org \
/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