Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1Xj7mv-0000RE-KT for bitcoin-development@lists.sourceforge.net; Tue, 28 Oct 2014 14:30:21 +0000 Received-SPF: pass (sog-mx-1.v43.ch3.sourceforge.com: domain of gmail.com designates 209.85.223.171 as permitted sender) client-ip=209.85.223.171; envelope-from=morcos@gmail.com; helo=mail-ie0-f171.google.com; Received: from mail-ie0-f171.google.com ([209.85.223.171]) by sog-mx-1.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1Xj7mt-0003ng-Qu for bitcoin-development@lists.sourceforge.net; Tue, 28 Oct 2014 14:30:21 +0000 Received: by mail-ie0-f171.google.com with SMTP id x19so768222ier.2 for ; Tue, 28 Oct 2014 07:30:14 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.107.135.146 with SMTP id r18mr3072232ioi.62.1414506614268; Tue, 28 Oct 2014 07:30:14 -0700 (PDT) Received: by 10.50.223.146 with HTTP; Tue, 28 Oct 2014 07:30:14 -0700 (PDT) In-Reply-To: References: Date: Tue, 28 Oct 2014 10:30:14 -0400 Message-ID: From: Alex Morcos To: Gavin Andresen Content-Type: multipart/alternative; boundary=001a113f966246a8e105067c7c0f X-Spam-Score: -0.6 (/) 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 (morcos[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.0 HTML_MESSAGE BODY: HTML included in message -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 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: 1Xj7mt-0003ng-Qu Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] Reworking the policy estimation code (fee estimates) 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, 28 Oct 2014 14:30:21 -0000 --001a113f966246a8e105067c7c0f Content-Type: text/plain; charset=UTF-8 Oh in just a couple of blocks, it'll give you a somewhat reasonable estimate for asking about every confirmation count other than 1, but it could take several hours for it to have enough data points to give you a good estimate for getting confirmed in one block (because the prevalent feerate is not always confirmed in 1 block >80% of the time) Essentially what it does is just combine buckets until it has enough data points, so after the first block it might be treating all of the txs as belonging to the same feerate bucket, but since the answer it returns is the "median"* fee rate for that bucket, its a reasonable answer right off the get go. Do you think it would make sense to make that 90% number an argument to rpc call? For instance there could be a default (I would use 80%) but then you could specify if you required a different certainty. It wouldn't require any code changes and might make it easier for people to build more complicated logic on top of it. *It can't actually track the median, but it identifies which of the smaller actual buckets the median would have fallen into and returns the average feerate for that median bucket. On Tue, Oct 28, 2014 at 9:59 AM, Gavin Andresen wrote: > I think Alex's approach is better; I don't think we can know how much > better until we have a functioning fee market. > > We don't have a functioning fee market now, because fees are hard-coded. > So we get "pay the hard-coded fee and you'll get confirmed in one or two or > three blocks, depending on which miners mine the next three blocks and what > time of day it is." > > git HEAD code says you need a fee of 10,0000 satoshis/kb to be pretty sure > you'll get confirmed in the next block. That looks about right with Alex's > real-world data (if we take "90% chance" as 'pretty sure you'll get > confirmed'): > > Fee rate 100000 Avg blocks to confirm 1.09 NumBlocks:% confirmed 1: 0.901 > 2: 1.0 3: 1.0 > > My only concern with Alex's code is that it takes much longer to get > 'primed' -- Alex, if I started with no data about fees, how long would it > take to be able to get enough data for a reasonable estimate of "what is > the least I can pay and still be 90% sure I get confirmed in 20 blocks" ? > Hours? Days? Weeks? > > -- > -- > Gavin Andresen > --001a113f966246a8e105067c7c0f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Oh in just a couple of blocks, it'll give you a somewh= at reasonable estimate for asking about every confirmation count other than= 1, but it could take several hours for it to have enough data points to gi= ve you a good estimate for getting confirmed in one block (because the prev= alent feerate is not always confirmed in 1 block >80% of the time) =C2= =A0 Essentially what it does is just combine buckets until it has enough da= ta points, so after the first block it might be treating all of the txs as = belonging to the same feerate bucket, but since the answer it returns is th= e "median"* fee rate for that bucket, its a reasonable answer rig= ht off the get go.=C2=A0

Do you think it would make sens= e to make that 90% number an argument to rpc call?=C2=A0 For instance there= could be a default (I would use 80%) but then you could specify if you req= uired a different certainty.=C2=A0 It wouldn't require any code changes= and might make it easier for people to build more complicated logic on top= of it.

*It can't actually track the median, but= it identifies which of the smaller actual buckets the median would have fa= llen into and returns the average feerate for that median bucket.





On Tue, Oct 28, 2014 at = 9:59 AM, Gavin Andresen <gavinandresen@gmail.com> wrot= e:
I think Alex's approach is better; I don't think we can know = how much better until we have a functioning fee market.

We don't have a funct= ioning fee market now, because fees are hard-coded. So we get "pay the= hard-coded fee and you'll get confirmed in one or two or three blocks,= depending on which miners mine the next three blocks and what time of day = it is."

git HEAD code says you need a fee of 10,0000 satoshis/kb to be prett= y sure you'll get confirmed in the next block. That looks about right w= ith Alex's real-world data (if we take "90% chance" as 'p= retty sure you'll get confirmed'):

Fee rate 100000 Avg blocks to confirm 1.09 NumBlocks:% confirmed 1: 0.901 = 2: 1.0 =C2=A0 3: 1.0

My only concern w= ith Alex's code is that it takes much longer to get 'primed' --= Alex, if I started with no data about fees, how long would it take to be a= ble to get enough data for a reasonable estimate of "what is the least= I can pay and still be 90% sure I get confirmed in 20 blocks" ? Hours= ? Days? Weeks?

--
--
Gavin Andresen

--001a113f966246a8e105067c7c0f--