public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Adam Back <adam@cypherspace.org>
To: Michael Naber <mickeybob@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 22:23:18 +0100	[thread overview]
Message-ID: <CALqxMTFfUdMuNsNnx-B+SPq7HvQyA+NkvFHGVYPiFHn-ZipVJw@mail.gmail.com> (raw)
In-Reply-To: <CALgxB7unOhWjoCcvGoCqzMnzwTL8XdJWt18kdiDSEeJ_cuiHqg@mail.gmail.com>

I dont think Bitcoin being cheaper is the main characteristic of
Bitcoin.  I think the interesting thing is trustlessness - being able
to transact without relying on third parties.

Adam


On 11 August 2015 at 22:18, Michael Naber via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> 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
>>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>


  reply	other threads:[~2015-08-11 21:23 UTC|newest]

Thread overview: 94+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-08-07 14:57 [bitcoin-dev] Fees and the block-finding process 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 [this message]
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=CALqxMTFfUdMuNsNnx-B+SPq7HvQyA+NkvFHGVYPiFHn-ZipVJw@mail.gmail.com \
    --to=adam@cypherspace.org \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=mickeybob@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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