From mboxrd@z Thu Jan 1 00:00:00 1970 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 ) 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 ; 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: References: <5E4597E4-C1C7-4536-8CF0-82EDD7715DAB@plan99.net> <39921E12-B411-4430-9D56-04F53906B109@plan99.net> From: Drak Date: Tue, 3 Dec 2013 11:04:53 +0000 Message-ID: To: Mike Hearn 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 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 wrote: > On Tue, Dec 3, 2013 at 11:36 AM, Drak 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
On 3= December 2013 10:45, Mike Hearn <mike@plan99.net> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
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 agains= t the best interests of senders in the long run.=C2=A0

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 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).

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.
=C2=A0
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 "it's better". That's not a fee going to MtGox, t= hat is the miner fee and they have no plans to reduce it.=C2=A0

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.

However, receivers do want= a fee attached,

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.
=C2=A0
That'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.

Miners cant lie about fe= es accepted because that'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.

Drak
--f46d04428e3a549cfd04ec9f45ac--