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 4CEBE7AE for ; Wed, 12 Aug 2015 03:35:45 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f172.google.com (mail-io0-f172.google.com [209.85.223.172]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2F12010D for ; Wed, 12 Aug 2015 03:35:44 +0000 (UTC) Received: by iodt126 with SMTP id t126so7947553iod.2 for ; Tue, 11 Aug 2015 20:35:43 -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=SirAW88wbqm56iFaYbYh+GDYxKR4Ti7ngT/qAJ4HA3E=; b=t7SgjqHjX8BAWeUmy8PS4coeY5T0cF0hjZRWdq52v1u7Quyv3JEKdsyxuE852IafLF vlDRwRogTVfch0EL+LVDtRv051G8N3KP3v0Vs5z+ke3uNhHaFgOpRbTLfrWAWjDcPPUA c7J1kxQJNXpGTEylfexl+k/aGfW1bOYUhWN4ffSqcS/SBo4S494Xb/QgKGKFlOzJs7LI X4JCZ6SqXrHfnatbU6ioSpD7tAjuQg7Hmz/fhiuKwPGYVVJpPN4GKwkPBBScQjXkUwTb aZ9k5o/DxtNKHEdsQBzdBPQ9U23YczgQ8rkkYyckNqiR1absl0NObpx1mzCKtVxhrWg2 gR3w== MIME-Version: 1.0 X-Received: by 10.107.134.94 with SMTP id i91mr31920998iod.162.1439350543596; Tue, 11 Aug 2015 20:35:43 -0700 (PDT) Received: by 10.79.97.135 with HTTP; Tue, 11 Aug 2015 20:35:43 -0700 (PDT) In-Reply-To: References: <8181630.GdAj0CPZYc@coldstorage> Date: Tue, 11 Aug 2015 20:35:43 -0700 Message-ID: From: Elliot Olds To: Bitcoin Dev Content-Type: multipart/alternative; boundary=001a113ec89cdbc2b4051d14e921 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,LOTS_OF_MONEY, 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 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: Wed, 12 Aug 2015 03:35:45 -0000 --001a113ec89cdbc2b4051d14e921 Content-Type: text/plain; charset=UTF-8 On Tue, Aug 11, 2015 at 2:51 PM, Pieter Wuille via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On Tue, Aug 11, 2015 at 11:35 PM, Michael Naber > wrote: > >> Bitcoin would be better money than current money even if it were a bit >> more expensive to transact, simply because of its other great >> characteristics (trustlessness, limited supply, etc). However... it is not >> better than something else sharing all those same characteristics but which >> is also less expensive. The best money will win, and if Bitcoin doesn't >> increase capacity then it won't remain the best. >> > > If it is less expensive, it is harder to be reliable (because it's easier > for a sudden new use case to outbid the available space), which is less > useful for a payment mechanism. > It depends on which use case's reliability that you focus on. For any specific use case of Bitcoin, that use case will be more reliable with a larger block size (ignoring centralization effects). The effect that I think you're talking about is that with lower fees, some use cases will exist that otherwise wouldn't have been possible with higher fees / smaller blocks, and these "low fee only" use cases will not be as reliable as the use cases you'd see with high fees. But that puts you in a position or arguing that it's better that low fee use cases never exist at all, than existing at some high risk of being priced out eventually. Do we know with high confidence how high tx fees will be in the future? Should it be up to us discourage low fee use cases from being tried, because we think the risk that they'll later be priced out is too great? Shouldn't we let the people developing those use cases make that call? Maybe they don't mind the unreliability. Maybe it's worth it to them if their use case only lasts for a few months. The important point to note is that the reliability of a use case is determined by the fees that people are willing to pay for that use case, not the fees that are actually paid. If big banks are willing to pay $1 / tx for some use case right now, but they only need 200 of these txns per block, then they might be paying only 5 cents / tx because no one is forcing them to pay more. The fact that they're only paying 5 cents / tx now doesn't make them any more vulnerable to new use cases than if they were paying $1 / tx now. If a new use case started bidding up tx fees, the banks would just increase their tx fees as high as they needed to (up to $1). The reason that larger block sizes increase reliability for any given use case is that (a) You will never be priced out of blocks by a use case that is only willing to pay lower fees than you. This is true regardless of the block size. At worst they'll just force you to pay more in fees and lose some of your consumer surplus. (b) If a use case is willing to pay higher fees than you, then they're basically stepping ahead of you in line for block space and pushing you closer to the edge of not being included in blocks. The more space that exists between your use case and the marginal use cases that are just barely getting included in blocks, the less vulnerable you are to getting pushed out of blocks by new use cases. If this is tricky to understand, here's an example that will make it clear: Assume blocks can hold 2000 txns per MB. Before the new use case is discovered, demand looks like this: 500 txns will pay $1 fees 1000 txns will pay 50 cent fees 2000 txns will pay 5 cent fees 8000 txns will pay 2 cent fees 15,000 txns will pay 1 cent fees. 100,000 txns will pay 0.01 cent fees. So at a block size of 1MB, fees are 5 cents and user surplus is $925 per block ($0.95 * 500 + 0.45 * 1000). At a block size of 8 MB, fees are 1 cent and user surplus is $1,145 per block ($0.99 * 500 + 0.49 * 1000 + $0.04 * 2000 + $0.01 * 8000). Now a new use case comes into play and this is added to demand: 3000 txns will pay $5 / tx That demand changes the scenarios like such: At 1 MB fees jump to $5, user surplus is $0, and the $925 of value the previous users were getting is lost. All existing use cases are priced out, because there wasn't enough room in the blocks to accommodate them plus this new use case. At 8 MB, fees would stay at 1 cent, user surplus would be $16,115, and $0 in value would be lost (3000 users who were paying 1 cent for txns that they valued only at 1 cent would stop making txns). All use cases corresponding to the txns that were willing to pay at least 2 cents are still viable, because there was enough space in blocks to accommodate them plus the 3000 new high fee txns. Let's say you're running the service that represents the 2000 txns willing to pay 5 cents each on the demand curve specified above. Let's say you're worried about being priced out of blocks. Which situation do you want to be in, the one with 1 MB blocks or 8 MB blocks? It's pretty clear that your best chance to remain viable is with larger blocks. --001a113ec89cdbc2b4051d14e921 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Aug 11, 2015 at 2:51 PM, Pieter Wuille via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
On Tue, Aug 11, 2015 at 11:= 35 PM, Michael Naber <mickeybob@gmail.com> wrote:
Bitcoin would be better money than curre= nt money even if it were a bit more expensive to transact, simply because o= f its other great characteristics (trustlessness, limited supply, etc). How= ever... it is not better than something else sharing all those same charact= eristics but which is also less expensive. The best money will win, and if = Bitcoin doesn't increase capacity then it won't remain the best.

If it is less expensive, it = is harder to be reliable (because it's easier for a sudden new use case= to outbid the available space), which is less useful for a payment mechani= sm.

It depends = on which use case's reliability that you focus on. For any specific use= case of Bitcoin, that use case will be more reliable with a larger block s= ize (ignoring centralization effects).=C2=A0

The e= ffect that I think you're talking about is that with lower fees, some u= se cases will exist that otherwise wouldn't have been possible with hig= her fees / smaller blocks, and these "low fee only" use cases wil= l not be as reliable as the use cases you'd see with high fees. But tha= t puts you in a position or arguing that it's better that low fee use c= ases never exist at all, than existing at some high risk of being priced ou= t eventually. Do we know with high confidence how high tx fees will be in t= he future? Should it be up to us discourage low fee use cases from being tr= ied, because we think the risk that they'll later be priced out is too = great? Shouldn't we let the people developing those use cases make that= call? Maybe they don't mind the unreliability. Maybe it's worth it= to them if their use case only lasts for a few months.

The important point to note is that the reliability of a use case is = determined by the fees that people are willing to pay for that use case, no= t the fees that are actually paid. If big banks are willing to pay $1 / tx = for some use case right now, but they only need 200 of these txns per block= , then they might be paying only 5 cents / tx because no one is forcing the= m to pay more. The fact that they're only paying 5 cents / tx now doesn= 't make them any more vulnerable to new use cases than if they were pay= ing $1 / tx now. If a new use case started bidding up tx fees, the banks wo= uld just increase their tx fees as high as they needed to (up to $1).=C2=A0=

The reason that larger block sizes increase relia= bility for any given use case is that (a) You will never be priced out of b= locks by a use case that is only willing to pay lower fees than you. This i= s true regardless of the block size. At worst they'll just force you to= pay more in fees and lose some of your consumer surplus. (b) If a use case= is willing to pay higher fees than you, then they're basically steppin= g ahead of you in line for block space and pushing you closer to the edge o= f not being included in blocks. The more space that exists between your use= case and the marginal use cases that are just barely getting included in b= locks, the less vulnerable you are to getting pushed out of blocks by new u= se cases.=C2=A0

If this is tricky to understand, h= ere's an example that will make it clear:

Assu= me blocks can hold 2000 txns per MB. Before the new use case is discovered,= demand looks like this:=C2=A0

500 txns will pay $= 1 fees
1000 txns will pay 50 cent fees
2000 txns will p= ay 5 cent fees
8000 txns will pay 2 cent fees
15,000 tx= ns will pay 1 cent fees.
100,000 txns will pay 0.01 cent fees.

So at a block size of 1MB, fees are 5 cents and user= surplus is $925 per block ($0.95 * 500 + 0.45 * 1000).
At a bloc= k size of 8 MB, fees are 1 cent and user surplus is $1,145 per block ($0.99= * 500 + 0.49 * 1000 + $0.04 * 2000 + $0.01 * 8000).

Now a new use case comes into play and this is added to demand:

3000 txns will pay $5 / tx

That d= emand changes the scenarios like such:

At 1 MB fee= s jump to $5, user surplus is $0, and the $925 of value the previous users = were getting is lost. All existing use cases are priced out, because there = wasn't enough room in the blocks to accommodate them plus this new use = case.

At 8 MB, fees would stay at 1 cent, user sur= plus would be $16,115, and $0 in value would be lost (3000 users who were p= aying 1 cent for txns that they valued only at 1 cent would stop making txn= s). All use cases corresponding to the txns that were willing to pay at lea= st 2 cents are still viable, because there was enough space in blocks to ac= commodate them plus the 3000 new high fee txns.

Le= t's say you're running the service that represents the 2000 txns wi= lling to pay 5 cents each on the demand curve specified above. Let's sa= y you're worried about being priced out of blocks. Which situation do y= ou want to be in, the one with 1 MB blocks or 8 MB blocks? It's pretty = clear that your best chance to remain viable is with larger blocks.

=C2=A0
--001a113ec89cdbc2b4051d14e921--