From: Drak <drak@zikula•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 11:04:53 +0000 [thread overview]
Message-ID: <CANAnSg2nXnuyPk9JPpqW82SC1QXqh=TSr5mbZc9YWqTM6NqPJw@mail.gmail.com> (raw)
In-Reply-To: <CANEZrP2iQ3P813qz9KL2R3WBTYpVq4AuL1xrfnwt5ay8Tk1oxw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2731 bytes --]
On 3 December 2013 10:45, Mike Hearn <mike@plan99•net> wrote:
> 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).
>
I respectfully disagree. Senders need their funds to be received. The
incentive is right there. Miners want mining fees. So if you want to pay
for something, you need to make sure payment arrives. Senders know that if
they exclude the fee it might not arrive at all. Miners increasingly ignore
no or low fees. So those two agents together ensure there is a fee more
than not. If what you said was true, we would hardly see fees being paid at
all, but on the contrary we see lots of fees, and much higher than the
minimum 0.0001/kb rate that is currently required.
Merchants will just include ridiculous fees - there are some exchanges that
do it already - MtGox being the famous example requires a 0.001 fee 10x
higher than the network rate - the CEO does it because he says "it's
better". That's not a fee going to MtGox, that is the miner fee and they
have no plans to reduce it.
Typically vendor software may not get updated and or lag behind with fat
fees never decreasing or decreasing way too slowly - it's just not fluid or
dynamic enough when it rests with the vendor.
However, receivers do want a fee attached,
>
No - receivers want to be paid. If they are not paid they wont dispatch the
goods or service. Neither party is happy in that circumstance. The
incentive that the payment confirms is there naturally.
> 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.
>
Miners cant lie about fees accepted because that's part of the transaction.
When Alice sends funds to Bob it includes the fee information and that is
included in the block. There is no way to fake it. The average fee paid is
provable - so there is no need to query nodes at all, you simply look at
the blockchain. You dont even need to write it into the blockchain since it
can be calculated from the blockchain, it would just make it simpler.
Drak
[-- Attachment #2: Type: text/html, Size: 4029 bytes --]
next prev parent reply other threads:[~2013-12-03 11:05 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
2013-12-03 11:04 ` Drak [this message]
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='CANAnSg2nXnuyPk9JPpqW82SC1QXqh=TSr5mbZc9YWqTM6NqPJw@mail.gmail.com' \
--to=drak@zikula$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=mike@plan99$(echo .)net \
/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