Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id A6D828C8 for ; Fri, 7 Aug 2015 18:22:53 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f175.google.com (mail-wi0-f175.google.com [209.85.212.175]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4A9C830 for ; Fri, 7 Aug 2015 18:22:52 +0000 (UTC) Received: by wicgj17 with SMTP id gj17so71183308wic.1 for ; Fri, 07 Aug 2015 11:22:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=x5SCZj2UQyxLIFPwDSiIwDTGOeFe8G7l2ooEsAu5Vbk=; b=MpW+DgfqcYOrmHBO55AWyHglRolxJuMVPFlxwVrpDbSUVZsqrdcnbJYAmWVYckzpM4 NiOn5Za2NKH75wga/lWiDCRicWxehMr0TnOZzYkNEtrmJ0jNV7KAJX308I0BHVGtaYaB YbH9D96fGgcKXf/sYMcWeVpKAMaqXgBrVEEbDMQnrXg14HJMIKneadEYYp79h/nzg5/8 IWZCnLNz9bIFZHFNrQRvaCpdtldIQR7O3j+l1pB1RTh+A1LFv4pzIW9fP9zNSnPDUNsB xU1H5ouPWBvNxzIjoh2IiIGLtFiUoOJlYXLJu/PZcSKdvFCvp4l2vgO1YbwPFWNzA+hW 5YsQ== MIME-Version: 1.0 X-Received: by 10.194.87.69 with SMTP id v5mr16981079wjz.140.1438971770670; Fri, 07 Aug 2015 11:22:50 -0700 (PDT) Sender: anthony.j.towns@gmail.com Received: by 10.28.176.69 with HTTP; Fri, 7 Aug 2015 11:22:50 -0700 (PDT) In-Reply-To: References: Date: Sat, 8 Aug 2015 04:22:50 +1000 X-Google-Sender-Auth: NPI6skb4lVcToM0jSoRiQUTv-jk Message-ID: From: Anthony Towns To: Gavin Andresen Content-Type: multipart/alternative; boundary=089e0102dfe23b9630051cbcb990 X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,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: Fri, 07 Aug 2015 18:22:53 -0000 --089e0102dfe23b9630051cbcb990 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On 8 August 2015 at 00:57, Gavin Andresen via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > I answered: > >> > 1. If you are willing to wait an infinite amount of time, I think the >> > minimum fee will always be zero or very close to zero, so I think it's= a >> > silly question. > > That's not what I'm thinking. It is just an observation based on the fact > that blocks are found at random intervals. > Every once in a while the network will get lucky and we'll find six blocks > in ten minutes. If you are deciding what transaction fee to put on your > transaction, and you're willing to wait until that > six-blocks-in-ten-minutes once-a-week event, submit your transaction with= a > low fee. > All the higher-fee transactions waiting to be confirmed will get confirmed > in the first five blocks and, if miners don't have any floor on the fee > they'll accept (they will, but lets pretend they won't) then your > very-low-fee transaction will get confirmed. > =E2=80=8BThat depends a bit on how ra=E2=80=8Btional miners are, doesn't it= ? Once the block subsidy is retired, hashpower is only paid for by fees -- and if there's no fee paying transactions in the queue, then there's no reward for applying hashpower, so mining a block won't even pay for your costs. In that case, better to switch to hatching something else (an altcoin with less fees than bitcoin has on average but more than nothing, eg), or put your hashing hardward into a low power mode so you at least cut costs. That will only be needed for a short while though -- presumably enough transactions will come in in the next five or ten minutes for a block to be worth mining again, so maybe implementing that decision process is more costly than the money you'd save. =E2=80=8B(C=E2=80=8B onversely, when the queue is over-full because there's been no blocks found for a while, that should mean you can fill a block with higher-than-average fee transactions, so I'd expect some miners to switch hashpower from altcoins and sidechains to catch the temporary chance of higher revenue blocks. =E2=80=8BBoth tendencies would help reduce the variance in block time, comp= ared to a steady hashrate, which would probably be a good thing for the network as a whole)=E2=80=8B I think the same incentives apply with mining being paid for by assurance contracts rather than directly by transaction fees -- if you get a bunch of blocks done quickly, the existing assurance contracts are dealt with just as well as if it had taken longer; so you want to wait until new ones come in rather than spend your hashpower for no return. =E2=80=8BAll of this only applies once fees make up a significant portion o= f the payment for mining a block, though.=E2=80=8B Cheers, aj --=20 Anthony Towns --089e0102dfe23b9630051cbcb990 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On 8 August 2015 at 00:57, = Gavin Andresen via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
I answered:=C2=A0
>=C2=A01. If you are willing to wait an infinite amount of time, I think= the
> minimum fee will always be zero or very close to zero, so I think it&#= 39;s a
> silly question.
That's not what I'm th= inking. It is just an observation based on the fact that blocks are found a= t random intervals.=C2=A0
Every once in a while the network will get lu= cky and we'll find six blocks in ten minutes. If you are deciding what = transaction fee to put on your transaction, and you're willing to wait = until that six-blocks-in-ten-minutes once-a-week event, submit your transac= tion with a low fee.=C2=A0
All the higher-fee transactions waiting to be confirm= ed will get confirmed in the first five blocks and, if miners don't hav= e any floor on the fee they'll accept (they will, but lets pretend they= won't) then your very-low-fee transaction will get confirmed.

=E2=80=8BThat depends a bit on how ra=E2= =80=8Btional miners are, doesn't it? Once the block subsidy is retired,= hashpower is only paid for by fees -- and if there's no fee paying tra= nsactions in the queue, then there's no reward for applying hashpower, = so mining a block won't even pay for your costs. In that case, better t= o switch to hatching something else (an altcoin with less fees than bitcoin= has on average but more than nothing, eg), or put your hashing hardward in= to a low power mode so you at least cut costs.

That will only be needed for a short whil= e though -- presumably enough transactions will come in in the next five or= ten minutes for a block to be worth mining again, so maybe implementing th= at decision process is more costly than the money you'd save.

=E2=80=8B(C=E2=80=8B
onversely, when t= he queue is over-full because there's been no blocks found for a while,= that should mean you can fill a block with higher-than-average fee transac= tions, so I'd expect some miners to switch hashpower from altcoins and = sidechains to catch the temporary chance of higher revenue blocks.=C2=A0=E2=80=8BBoth tendencies= would help reduce the variance in block time, compared to a steady hashrat= e, which would probably be a good thing for the network as a whole)=E2=80= =8B


I think the same incentives apply with mining being paid for by= assurance contracts rather than directly by transaction fees -- if you get= a bunch of blocks done quickly, the existing assurance contracts are dealt= with just as well as if it had taken longer; so you want to wait until new= ones come in rather than spend your hashpower for no return.

=E2=80= =8BAll of this only applies once fees make up a significant portion of the = payment for mining a block, though.=E2=80=8B

Cheers,
=
aj
=

--
Anthony Towns &l= t;aj@erisian.com.au<= /a>>
--089e0102dfe23b9630051cbcb990--