From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VnnU3-0000p0-VS for bitcoin-development@lists.sourceforge.net; Tue, 03 Dec 2013 10:45:40 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.214.178 as permitted sender) client-ip=209.85.214.178; envelope-from=mh.in.england@gmail.com; helo=mail-ob0-f178.google.com; Received: from mail-ob0-f178.google.com ([209.85.214.178]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1VnnU2-0003KL-SV for bitcoin-development@lists.sourceforge.net; Tue, 03 Dec 2013 10:45:39 +0000 Received: by mail-ob0-f178.google.com with SMTP id uz6so14171261obc.37 for ; Tue, 03 Dec 2013 02:45:33 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.182.48.130 with SMTP id l2mr5863149obn.44.1386067533439; Tue, 03 Dec 2013 02:45:33 -0800 (PST) Sender: mh.in.england@gmail.com Received: by 10.76.3.134 with HTTP; Tue, 3 Dec 2013 02:45:33 -0800 (PST) In-Reply-To: References: <5E4597E4-C1C7-4536-8CF0-82EDD7715DAB@plan99.net> <39921E12-B411-4430-9D56-04F53906B109@plan99.net> Date: Tue, 3 Dec 2013 11:45:33 +0100 X-Google-Sender-Auth: l56u5kyxus0Are4PKwcS0BWX_T8 Message-ID: From: Mike Hearn To: Drak Content-Type: multipart/alternative; boundary=089e0160b3dcf72c4704ec9efe9d X-Spam-Score: -0.5 (/) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (mh.in.england[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 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: zikula.org] 1.0 HTML_MESSAGE BODY: HTML included in message 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature X-Headers-End: 1VnnU2-0003KL-SV 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 10:45:40 -0000 --089e0160b3dcf72c4704ec9efe9d Content-Type: text/plain; charset=UTF-8 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). 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. --089e0160b3dcf72c4704ec9efe9d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, 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 own dev= ices, all senders would always attach no fee at all (or rather: whatever th= e 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 se= nders to attach a fee and effectively folding it into the price that is pai= d. That is, if you go into a restaurant and the menu says "Burger: 10m= BTC" then when you come to pay, what you see on your phone screen is 1= 0mBTC. 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 man= y others, where receivers eat a transaction cost. For instance in Europe sa= les taxes are included in the price, not attached separately later.

There's no need to trust the vendor. If a vendor as= ks for a ridiculously high tx fee, it will just surface as uncompetitively = priced goods/services. Buyers will go elsewhere.
=C2=A0
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 t= ransactions that were included without fees) and then write that into the b= lock as a soft recommendation that wallets could use in the UI. This way th= e 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.
--089e0160b3dcf72c4704ec9efe9d--