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 16:20:21 -0700 [thread overview]
Message-ID: <CA+BnGuHd5ozSB=-hd0ctCa78cmmj27nc2uX2mFq1kE+nBGtufQ@mail.gmail.com> (raw)
In-Reply-To: <CAPg+sBiaT-2sjedA1mLOQo+q7=DjJ2yRuy7E4Gb3Wn8R-DzRTQ@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3652 bytes --]
On Fri, Aug 7, 2015 at 9:28 AM, Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists•linuxfoundation.org> wrote:
> On Fri, Aug 7, 2015 at 5:55 PM, Gavin Andresen <gavinandresen@gmail•com>
> wrote:
>
>> I think there are multiple reasons to raise the maximum block size, and
>> yes, fear of Bad Things Happening as we run up against the 1MB limit is one
>> of the reasons.
>>
>> I take the opinion of smart engineers who actually do resource planning
>> and have seen what happens when networks run out of capacity very seriously.
>>
>
> This is a fundamental disagreement then. I believe that the demand is
> infinite if you don't set a fee minimum (and I don't think we should), and
> it just takes time for the market to find a way to fill whatever is
> available - the rest goes into off-chain systems anyway. You will run out
> of capacity at any size, and acting out of fear of that reality does not
> improve the system.
>
I think the case for increasing block size can be made without appealing to
fear of unknown effects of a fee market developing. I agree with you that
the most likely outcome is that fees will rise to a new equilibrium as
competition for block space increases, and some use cases will get priced
out of the market. If fees rise high enough, the effects of this can be
pretty bad though. I get the sense that you don't think high fees are that
bad / low fees are that good.
Can you let me know which of these statements related to low fees you
disagree with?
(0) Bitcoin's security will eventually have to be paid for almost entirely
via txn fees.
(1) A future in which lots of users are making on chain txns and each
paying 5 cents/tx is more sustainable than one in which a smaller number of
users are paying $3/tx, all else being equal (pretend the centralization
pressures are very low in both instances, and each scenario results in the
same amount of total tx fees).
(2) It's important that Bitcoin become widely used to protect the network
against regulators (note how political pressure from users who like Uber
have had a huge effect on preventing Uber from being banned in many
locations).
(3) There are potentially a lot of valuable use cases that can benefit from
Bitcoin's decentralization which can work at 5 cents / tx but are nonviable
at $3 / tx. Allowing fees to stay at $3 / tx and pricing out all the viable
use cases between $3 and 5 cents / tx would likely result in a significant
loss of utility for people who want these use cases to work.
(4) The Lightning Network will be a lot less appealing at $3 / tx than 5
cents / tx, because it'll require much larger anchor txn values to
sufficiently amortize the costs of the Bitcoin tx fees, and having to pay
$3 each time your counter-party misbehaves is somewhat painful.
(5) Assuming that Bitcoin is somewhat likely to end up in the "lots of
users, lower fees" situation described in (1), it's important that people
can experiment with low fee use cases now so that these use cases have time
to be discovered, be improved, and become popular before Bitcoin's security
relies exclusively on fees.
Finally, here's a type of question that devs on this list really don't like
answering but which I think is more informative than almost any other: If
you knew that hard forking to 4 MB soon would keep fees around 5 cents
(with a fee market) for the next two years, and that remaining at 1 MB
would result in fees of around $1 for the next two years, would you be in
favor of the 4 MB hard fork? (I know our knowledge of the decentralization
risks isn't very complete now, but assume you had to make a decision given
the state of your knowledge now).
[-- Attachment #2: Type: text/html, Size: 4710 bytes --]
next prev parent reply other threads:[~2015-08-11 23:20 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 [this message]
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
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+BnGuHd5ozSB=-hd0ctCa78cmmj27nc2uX2mFq1kE+nBGtufQ@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