Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of zikula.org
	designates 74.125.82.172 as permitted sender)
	client-ip=74.125.82.172; envelope-from=drak@zikula.org;
	helo=mail-we0-f172.google.com; 
MIME-Version: 1.0
In-Reply-To: <CANEZrP1PLKemiUEgMJRGdiZXt7o=0_5fhLKYY0x3Ngb_iEm+2w@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>
From: Drak <drak@zikula.org>
Date: Tue, 3 Dec 2013 10:36:50 +0000
Message-ID: <CANAnSg2kH+OeypDARUKyDTUmq26PiK2_U45wGaUOGTnkXj6jjA@mail.gmail.com>
To: Mike Hearn <mike@plan99.net>
Content-Type: multipart/alternative; boundary=f46d04428e3afbb21704ec9ee05f
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Floating fees and SPV clients
Precedence: list

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

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.

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.

I absolutely do not trust vendors to set fees. I think it has to be based
on what senders are willing to pay and what miners are willing to accept.

Drak

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

<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 class=3D"g=
mail_extra">


<br></div><div class=3D"gmail_extra">Why not try a different path of calcul=
ating the min fee like difficulty retarget. You can analyse the last 2016 b=
locks to find the average fee accepted per kb (which would include transact=
ions 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 fee=
s and miners willing to accept. =C2=A0</div>


<div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">I absolutel=
y do not trust vendors to set fees. I think it has to be based on what send=
ers are willing to pay and what miners are willing to accept.<br>
</div><div class=3D"gmail_extra"><br></div><div class=3D"gmail_extra">Drak<=
/div><div class=3D"gmail_extra"><br></div></div>

--f46d04428e3afbb21704ec9ee05f--