From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id BBCEE88B for ; Mon, 10 Aug 2015 22:52:24 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ig0-f173.google.com (mail-ig0-f173.google.com [209.85.213.173]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4615223F for ; Mon, 10 Aug 2015 22:52:24 +0000 (UTC) Received: by igbpg9 with SMTP id pg9so79791682igb.0 for ; Mon, 10 Aug 2015 15:52:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=yHrMcFo91lxpAB5u0SQVycN7rQnXLIRpUnrnflbiusU=; b=VIFY2Z1GrGPU4dlIJm4+jcfUj2MDU9wi2XmvfYgYmPaDQTV+Z7Tsjbq8ymosN1/I0L FWXHf+Mi1l4LlvdcR2K2HsMFKXgiaj9NSiH7XYNi5uXHveaZfrS1tJ+1r24S5Plx3s8G afHJzg/YJeSXdLgx/fnnh5uPerMexcjxM1cas0TFKnJhih6oDBGxroDlgFRbiay/pLdf t4fNID3Eajx03rBEEQZD/mRDvxddOfcaivtWR775rWpApHoIbgmS83PKFrrYY1KS46DG qCLCfa/o3Bu2K44e61H1B0pycrnyf3xQdpugmfFqymBewJyEoAqwz9X9gFG65e4yeL1S SdoA== MIME-Version: 1.0 X-Received: by 10.50.134.226 with SMTP id pn2mr14997791igb.21.1439247143656; Mon, 10 Aug 2015 15:52:23 -0700 (PDT) Received: by 10.36.77.201 with HTTP; Mon, 10 Aug 2015 15:52:23 -0700 (PDT) Received: by 10.36.77.201 with HTTP; Mon, 10 Aug 2015 15:52:23 -0700 (PDT) In-Reply-To: <1472719.PaoH0O6gJe@coldstorage> References: <1472719.PaoH0O6gJe@coldstorage> Date: Tue, 11 Aug 2015 00:52:23 +0200 Message-ID: From: Pieter Wuille To: Thomas Zander Content-Type: multipart/alternative; boundary=047d7b2e148dbde492051cfcd6f4 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Cc: Bitcoin Dev Subject: Re: [bitcoin-dev] Fees and the block-finding process X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Aug 2015 22:52:24 -0000 --047d7b2e148dbde492051cfcd6f4 Content-Type: text/plain; charset=UTF-8 On Aug 11, 2015 12:18 AM, "Thomas Zander via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: > Have you ever been to a concert that was far away from public transport? They > typically set up bus shuttles, or taxis to get people back into town > afterwards. > The result there is always you end up waiting forever and it actually may be > easier to just walk instead of wait. > The amount you pay is irrelevant if everyone is paying it. There still is more > demand than there is capacity. That's an incorrect analogy. You choose the rate you pay, and get higher priority when you pay more. Taxi drivers can't pick out higher-paying customers in advance. A better comparison is Uber, which charges more in places with high demand, and you can accept or refuse in advance. And yes, it remains reliable if you're among those with the highest willingness to pay. > So, no, its not unreliable for cheap free transactions. > Its unreliable for all types of transactions. If 2500 transactions fit in the block chain per day (assuming constant size) and there are less than 2500 per hour that pay at least 0.001 BTC in fee, then any transaction which pays more than 0.001 BTC will have a very high chance of getting in a small multiple of one hour, since miners prioritize by feerate. If there are in addition to that 5000 transactions per hour which pay less, then yes, they need to compete for the remaiming space and their confirmation will be unreliable. The whole point is that whether confirmation at a particular price point is reliable depends on how much demand there is at that price point. And increasing the block size out of fear of what might happen is failing to recognize that it can always happen that there is a sudden change in demand that outcompetes the rest. The point is not that evolution towards a specific higher feerate needs to happen, but an evolution to an ecosystem that accepts that there is never a guarantee for reliability, unless you're willing to pay more than everyone else - whatever that number is. -- Pieter --047d7b2e148dbde492051cfcd6f4 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Aug 11, 2015 12:18 AM, "Thomas Zander via bitcoin-dev" <bitcoin-dev@lists.lin= uxfoundation.org> wrote:

> Have you ever been to a concert that was far away from = public transport? They
> typically set up bus shuttles, or taxis to get people back into town > afterwards.
> The result there is always you end up waiting forever and it actually = may be
> easier to just walk instead of wait.
> The amount you pay is irrelevant if everyone is paying it. There still= is more
> demand than there is capacity.

That's an incorrect analogy. You choose the rate you pay= , and get higher priority when you pay more. Taxi drivers can't pick ou= t higher-paying customers in advance.

A better comparison is Uber, which charges more in places wi= th high demand, and you can accept or refuse in advance. And yes, it remain= s reliable if you're among those with the highest willingness to pay.

> So, no, its not unreliable for cheap free transactions.=
> Its unreliable for all types of transactions.

If 2500 transactions fit in the block chain per day (assumin= g constant size) and there are less than 2500 per hour that pay at least 0.= 001 BTC in fee, then any transaction which pays more than 0.001 BTC will ha= ve a very high chance of getting in a small multiple of one hour, since min= ers prioritize by feerate.

If there are in addition to that 5000 transactions per hour = which pay less, then yes, they need to compete for the remaiming space and = their confirmation will be unreliable.

The whole point is that whether confirmation at a particular= price point is reliable depends on how much demand there is at that price = point. And increasing the block size out of fear of what might happen is fa= iling to recognize that it can always happen that there is a sudden change = in demand that outcompetes the rest.

The point is not that evolution towards a specific higher fe= erate needs to happen, but an evolution to an ecosystem that accepts that t= here is never a guarantee for reliability, unless you're willing to pay= more than everyone else - whatever that number is.

--
Pieter

--047d7b2e148dbde492051cfcd6f4--