From: Elliot Olds <elliot.olds@gmail•com>
To: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Fees and the block-finding process
Date: Tue, 11 Aug 2015 20:35:43 -0700 [thread overview]
Message-ID: <CA+BnGuF_pNrmvqVzdficuGWO7RF8ROa2W4YDkYXCL6ODWE4k=Q@mail.gmail.com> (raw)
In-Reply-To: <CAPg+sBgtVwgf4BBv6SDR_L1oaED9Cx3onC1FZbT+PX1rD2fSEA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4978 bytes --]
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 <mickeybob@gmail•com>
> 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.
[-- Attachment #2: Type: text/html, Size: 6150 bytes --]
next prev parent reply other threads:[~2015-08-12 3:35 UTC|newest]
Thread overview: 94+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-07 14:57 Gavin Andresen
2015-08-07 15:16 ` Pieter Wuille
2015-08-07 15:55 ` Gavin Andresen
2015-08-07 16:28 ` Pieter Wuille
2015-08-07 17:47 ` Ryan Butler
2015-08-07 18:25 ` Mark Friedenbach
2015-08-07 18:57 ` Ryan Butler
2015-08-07 19:07 ` Ryan Butler
2015-08-07 19:15 ` Mark Friedenbach
2015-08-07 20:17 ` Ryan Butler
2015-08-07 20:33 ` Dave Hudson
2015-08-07 18:17 ` jl2012
2015-08-07 18:35 ` Bryan Bishop
2015-08-07 18:36 ` Simon Liu
2015-08-11 23:20 ` Elliot Olds
2015-08-07 17:33 ` Jorge Timón
2015-08-07 22:12 ` Thomas Zander
2015-08-07 23:06 ` Adam Back
2015-08-08 22:45 ` Dave Scotese
2015-08-08 23:05 ` Alex Morcos
2015-08-09 5:52 ` Hector Chu
2015-08-09 10:32 ` Thomas Zander
2015-08-09 10:42 ` Thomas Zander
2015-08-09 20:43 ` Dave Scotese
2015-08-11 17:03 ` Jorge Timón
2015-08-10 11:55 ` Jorge Timón
2015-08-10 12:33 ` Btc Drak
2015-08-10 13:03 ` Jorge Timón
2015-08-10 22:13 ` Thomas Zander
2015-08-11 17:47 ` Jorge Timón
2015-08-11 18:46 ` Michael Naber
2015-08-11 18:48 ` Mark Friedenbach
2015-08-11 18:55 ` Michael Naber
2015-08-11 19:45 ` Jorge Timón
2015-08-11 21:31 ` Michael Naber
2015-08-11 18:51 ` Bryan Bishop
2015-08-11 18:59 ` Michael Naber
2015-08-11 19:27 ` Jorge Timón
2015-08-11 19:37 ` Michael Naber
2015-08-11 19:51 ` Pieter Wuille
2015-08-11 21:18 ` Michael Naber
2015-08-11 21:23 ` Adam Back
2015-08-11 21:30 ` Angel Leon
2015-08-11 21:32 ` Pieter Wuille
2015-08-11 21:34 ` Adam Back
2015-08-11 21:39 ` Michael Naber
2015-08-12 6:10 ` Venzen Khaosan
2015-08-11 22:06 ` Angel Leon
2015-08-11 21:35 ` Michael Naber
2015-08-11 21:51 ` Pieter Wuille
2015-08-12 3:35 ` Elliot Olds [this message]
2015-08-12 4:47 ` Venzen Khaosan
2015-08-14 21:47 ` Elliot Olds
2015-08-12 0:56 ` Tom Harding
2015-08-12 1:18 ` Eric Voskuil
2015-08-12 8:10 ` Thomas Zander
2015-08-12 9:00 ` Jorge Timón
2015-08-12 9:25 ` Thomas Zander
2015-08-11 19:53 ` Jorge Timón
2015-08-11 20:56 ` Michael Naber
2015-08-12 7:54 ` Thomas Zander
2015-08-12 8:01 ` Thomas Zander
[not found] ` <1679272.aDpruqxXDP@coldstorage>
2015-08-12 8:51 ` Jorge Timón
2015-08-12 9:23 ` Thomas Zander
2015-08-12 9:45 ` Jorge Timón
2015-08-12 16:24 ` Thomas Zander
2015-08-17 14:49 ` BitMinter operator
2015-08-17 15:01 ` Peter Todd
2015-08-10 14:12 ` Gavin Andresen
2015-08-10 14:24 ` Alex Morcos
2015-08-10 22:12 ` Thomas Zander
2015-08-10 14:34 ` Pieter Wuille
2015-08-10 22:04 ` Thomas Zander
2015-08-20 14:40 ` Will Madden
2015-08-10 14:55 ` Jorge Timón
2015-08-10 22:09 ` Thomas Zander
2015-08-10 22:52 ` Pieter Wuille
2015-08-10 23:11 ` Pieter Wuille
2015-08-11 5:34 ` Thomas Zander
2015-08-11 6:03 ` Mark Friedenbach
2015-08-11 6:31 ` Thomas Zander
2015-08-11 7:08 ` Mark Friedenbach
2015-08-11 8:38 ` Thomas Zander
2015-08-11 9:14 ` Angel Leon
2015-08-11 19:00 ` Mark Friedenbach
2015-08-11 19:26 ` Michael Naber
2015-08-11 20:12 ` Adam Back
2015-08-12 0:32 ` odinn
2015-08-11 11:10 ` Thomas Zander
2015-08-12 0:18 ` odinn
2015-08-07 21:30 ` Jim Phillips
2015-08-07 18:22 ` Anthony Towns
2015-08-07 18:36 ` Peter R
2015-08-12 1:56 Corey Haddad
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CA+BnGuF_pNrmvqVzdficuGWO7RF8ROa2W4YDkYXCL6ODWE4k=Q@mail.gmail.com' \
--to=elliot.olds@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox