From: Michael Naber <mickeybob@gmail•com>
To: Pieter Wuille <pieter.wuille@gmail•com>
Cc: Bitcoin Dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Fees and the block-finding process
Date: Tue, 11 Aug 2015 16:18:49 -0500 [thread overview]
Message-ID: <CALgxB7unOhWjoCcvGoCqzMnzwTL8XdJWt18kdiDSEeJ_cuiHqg@mail.gmail.com> (raw)
In-Reply-To: <CAPg+sBjGVk1jHraLZTroRneL6L1HxZ-bTGaLNwakcDSDDHqauA@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3553 bytes --]
The only reason why Bitcoin has grown the way it has, and in fact the only
reason why we're all even here on this mailing list talking about this, is
because Bitcoin is growing, since it's "better money than other money". One
of the key characteristics toward that is Bitcoin being inexpensive to
transact. If that characteristic is no longer true, then Bitcoin isn't
going to grow, and in fact Bitcoin itself will be replaced by better money
that is less expensive to transfer.
So the importance of this issue cannot be overstated -- it's compete or die
for Bitcoin -- because people want to transact with global consensus at
high volume, and because technology exists to service that want, then it's
going to be met. This is basic rules of demand and supply. I don't
necessarily disagree with your position on only wanting to support
uncontroversial commits, but I think it's important to get consensus on the
criticality of the block size issue: do you agree, disagree, or not take a
side, and why?
On Tue, Aug 11, 2015 at 2:51 PM, Pieter Wuille <pieter.wuille@gmail•com>
wrote:
> On Tue, Aug 11, 2015 at 9:37 PM, Michael Naber via bitcoin-dev <
> bitcoin-dev@lists•linuxfoundation.org> wrote:
>
>> Hitting the limit in and of itself is not necessarily a bad thing. The
>> question at hand is whether we should constrain that limit below what
>> technology is capable of delivering. I'm arguing that not only we should
>> not, but that we could not even if we wanted to, since competition will
>> deliver capacity for global consensus whether it's in Bitcoin or in some
>> other product / fork.
>>
>
> The question is not what the technology can deliver. The question is what
> price we're willing to pay for that. It is not a boolean "at this size,
> things break, and below it, they work". A small constant factor increase
> will unlikely break anything in the short term, but it will come with
> higher centralization pressure of various forms. There is discussion about
> whether these centralization pressures are significant, but citing that
> it's artificially constrained under the limit is IMHO a misrepresentation.
> It is constrained to aim for a certain balance between utility and risk,
> and neither extreme is interesting, while possibly still "working".
>
> Consensus rules are what keeps the system together. You can't simply
> switch to new rules on your own, because the rest of the system will end up
> ignoring you. These rules are there for a reason. You and I may agree about
> whether the 21M limit is necessary, and disagree about whether we need a
> block size limit, but we should be extremely careful with change. My
> position as Bitcoin Core developer is that we should merge consensus
> changes only when they are uncontroversial. Even when you believe a more
> invasive change is worth it, others may disagree, and the risk from
> disagreement is likely larger than the effect of a small block size
> increase by itself: the risk that suddenly every transaction can be spent
> twice (once on each side of the fork), the very thing that the block chain
> was designed to prevent.
>
> My personal opinion is that we should aim to do a block size increase for
> the right reasons. I don't think fear of rising fees or unreliability
> should be an issue: if fees are being paid, it means someone is willing to
> pay them. If people are doing transactions despite being unreliable, there
> must be a use for them. That may mean that some use cases don't fit
> anymore, but that is already the case.
>
> --
> Pieter
>
>
[-- Attachment #2: Type: text/html, Size: 4456 bytes --]
next prev parent reply other threads:[~2015-08-11 21:18 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 [this message]
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=CALgxB7unOhWjoCcvGoCqzMnzwTL8XdJWt18kdiDSEeJ_cuiHqg@mail.gmail.com \
--to=mickeybob@gmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=pieter.wuille@gmail$(echo .)com \
/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