path: root/f5/6e75dd4f7de60008eb3f8ff3bffc08b91681fd

Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
	helo=mx.sourceforge.net)
	by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <drak@zikula.org>) id 1Vnnn7-0007bT-Br
	for bitcoin-development@lists.sourceforge.net;
	Tue, 03 Dec 2013 11:05:21 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of zikula.org
	designates 209.85.212.176 as permitted sender)
	client-ip=209.85.212.176; envelope-from=drak@zikula.org;
	helo=mail-wi0-f176.google.com; 
Received: from mail-wi0-f176.google.com ([209.85.212.176])
	by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1Vnnn6-0003v3-6i
	for bitcoin-development@lists.sourceforge.net;
	Tue, 03 Dec 2013 11:05:21 +0000
Received: by mail-wi0-f176.google.com with SMTP id hq4so6316569wib.15
	for <bitcoin-development@lists.sourceforge.net>;
	Tue, 03 Dec 2013 03:05:14 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20130820;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc:content-type;
	bh=+OK1p/e9HGNiwI+BZz++zFaz56YHmVMb/b6hutwRHRo=;
	b=YgwvFxk+EXTFfiL0iTD0waaiZZCn7D4KfbLSw/Rl6301osArSalE+wJWapSBwZ/zfv
	In8rdvHZ/G39aJ2vuRa+v9d7Quv5MWvmBcwHgUgxoD9N33WGFX8AI480gAR9dQZnyq+M
	gVrBybisi0yr/1UWlFJokzwUX0ObS3Hd22kj4MmLbq9Ns2xG+DQS6/qJtLfct/EOr7QZ
	I4G9ygPHF60oLPp6DvuOSPSj8yDHzKgS1JUhVf6gbDRDA1HDo2JIPNZd2XIaQOl+6y4v
	u1nSnnxkDgNHpRpkwYMnLrO6jIXQimOzPItT+sBME08ujnaPNoX+TwgQEyT7aKBC/Bcf
	PNIQ==
X-Gm-Message-State: ALoCoQkdtqZl6pXhm+wwQnOiV4lTOAjW3FmBKQNd74Y45EXjYxyjO59X8gseltS0e828CKFrrEaV
X-Received: by 10.180.103.193 with SMTP id fy1mr1980864wib.10.1386068713965;
	Tue, 03 Dec 2013 03:05:13 -0800 (PST)
MIME-Version: 1.0
Received: by 10.194.93.105 with HTTP; Tue, 3 Dec 2013 03:04:53 -0800 (PST)
In-Reply-To: <CANEZrP2iQ3P813qz9KL2R3WBTYpVq4AuL1xrfnwt5ay8Tk1oxw@mail.gmail.com>
References: <CANEZrP3tGdFh6oG5fbX9JbU6sYbbex1cq=0tQB-0A4aDrdbXrQ@mail.gmail.com>
	<l7f97u$jdg$1@ger.gmane.org>
	<5E4597E4-C1C7-4536-8CF0-82EDD7715DAB@plan99.net>
	<l7fpbn$hf6$1@ger.gmane.org>
	<39921E12-B411-4430-9D56-04F53906B109@plan99.net>
	<CAGLkj4C9fyAX1CnB0oZH3BwLRQp6WOo9kLUqDhRUSA6y3LxYvg@mail.gmail.com>
	<CANEZrP1C=Hc-3f-rqQ+wYrPn-eUj52HjN+qRQdJMWvnP+dkK=Q@mail.gmail.com>
	<CAJHLa0P_uzEQ2OG2FTXyD2Zw4RzujNBxKbKD04CSS1sLNpLUUQ@mail.gmail.com>
	<CANEZrP2hf2853w9f4__Ji9v3eRRU0u6pEzPxAmFN+iH067gtnA@mail.gmail.com>
	<CABsx9T3NQDPL6=pz5BD5DsP0qh0x3LJOCj2H3yY5tzL2_DivGA@mail.gmail.com>
	<CANEZrP1PLKemiUEgMJRGdiZXt7o=0_5fhLKYY0x3Ngb_iEm+2w@mail.gmail.com>
	<CANAnSg2kH+OeypDARUKyDTUmq26PiK2_U45wGaUOGTnkXj6jjA@mail.gmail.com>
	<CANEZrP2iQ3P813qz9KL2R3WBTYpVq4AuL1xrfnwt5ay8Tk1oxw@mail.gmail.com>
From: Drak <drak@zikula.org>
Date: Tue, 3 Dec 2013 11:04:53 +0000
Message-ID: <CANAnSg2nXnuyPk9JPpqW82SC1QXqh=TSr5mbZc9YWqTM6NqPJw@mail.gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: multipart/alternative; boundary=f46d04428e3a549cfd04ec9f45ac
X-Spam-Score: -0.5 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
	See http://spamassassin.org/tag/ for more details.
	0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
	See
	http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
	for more information. [URIs: plan99.net]
	-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
	sender-domain
	-0.0 SPF_PASS               SPF: sender matches SPF record
	1.0 HTML_MESSAGE           BODY: HTML included in message
X-Headers-End: 1Vnnn6-0003v3-6i
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Floating fees and SPV clients
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
	<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Tue, 03 Dec 2013 11:05:21 -0000

--f46d04428e3a549cfd04ec9f45ac
Content-Type: text/plain; charset=UTF-8

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

--f46d04428e3a549cfd04ec9f45ac
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On 3=
 December 2013 10:45, Mike Hearn <span dir=3D"ltr">&lt;<a href=3D"mailto:mi=
ke@plan99.net" target=3D"_blank">mike@plan99.net</a>&gt;</span> wrote:<br><=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex">


<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote"><div=
>On Tue, Dec 3, 2013 at 11:36 AM, Drak <span dir=3D"ltr">&lt;<a href=3D"mai=
lto:drak@zikula.org" target=3D"_blank">drak@zikula.org</a>&gt;</span> wrote=
:<br>
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra">I dont like the idea of putting=
 the min fee in the hands of the receiver. Seems like that will work agains=
t the best interests of senders in the long run.=C2=A0</div></div></blockqu=
ote>


<div>
<br></div></div><div>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=
&#39;s not the sender who cares about double spending risk. Left to their o=
wn devices, all senders would always attach no fee at all (or rather: whate=
ver the min was to get the transaction relayed to the merchant).</div>


</div></div></div></blockquote><div><br></div><div>I respectfully disagree.=
 Senders need their funds to be received. The incentive is right there. Min=
ers 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 n=
ot arrive at all. Miners increasingly ignore no or low fees. So those two a=
gents together ensure there is a fee more than not. If what you said was tr=
ue, 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 curre=
ntly required.</div>


<div>=C2=A0</div><div>Merchants will just include ridiculous fees - there a=
re some exchanges that do it already - MtGox being the famous example requi=
res a 0.001 fee 10x higher than the network rate - the CEO does it because =
he says &quot;it&#39;s better&quot;. That&#39;s not a fee going to MtGox, t=
hat is the miner fee and they have no plans to reduce it.=C2=A0</div>

<div><br></div><div>Typically vendor software may not get updated and or la=
g behind with fat fees never decreasing or decreasing way too slowly - it&#=
39;s just not fluid or dynamic enough when it rests with the vendor.</div>


<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex=
;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=
=3D"gmail_extra"><div class=3D"gmail_quote"><div>However, receivers do want=
 a fee attached, </div>


</div></div></div></blockquote><div><br></div><div>No - receivers want to b=
e paid. If they are not paid they wont dispatch the goods or service. Neith=
er party is happy in that circumstance. The incentive that the payment conf=
irms is there naturally.</div>


<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div class=
=3D"gmail_extra"><div class=3D"gmail_quote"><div>That&#39;s what fee estima=
tion does, essentially, minus the encoding into blocks. Once you start gett=
ing miners telling people what fees are directly you run into cases where t=
hey might try to lie about their behaviour or otherwise influence the avera=
ge. Querying all nodes avoids that problem.</div>


</div></div></div></blockquote><div><br></div><div>Miners cant lie about fe=
es accepted because that&#39;s part of the transaction. When Alice sends fu=
nds to Bob it includes the fee information and that is included in the bloc=
k. 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 do=
nt even need to write it into the blockchain since it can be calculated fro=
m the blockchain, it would just make it simpler.</div>


<div><br></div><div>Drak</div></div></div></div>

--f46d04428e3a549cfd04ec9f45ac--