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 BC06888B for ; Tue, 11 Aug 2015 21:39:36 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f170.google.com (mail-wi0-f170.google.com [209.85.212.170]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3AAF77D for ; Tue, 11 Aug 2015 21:39:35 +0000 (UTC) Received: by wijp15 with SMTP id p15so193686436wij.0 for ; Tue, 11 Aug 2015 14:39:34 -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=OeNkRhdd12PkbvjwRQtMqf+/SlGHiGTKRj8SMCIyUTs=; b=A6o54NQqpo+f0NPEhWupt9YbhYTWyOb16JT3biR6FYIvL3f/vIhEtPdn+WKAkoWN3v 0kcxqffNB8zE9XkJgUBzn4xSni+fx6YFzWRtgA/X0G75Zc5SuW2kzE/8pGqvv8WEUp1i LUqGMtizoPtFv4I0RpmgU5oIcsUjh2nmCezJXqcGnAU1fk3HCwm0O3cvYTXGgk7doFFK 7TeK7DU+Zue1EzxGp7/1ABJls2JU+NhCVYJ+dRVnBAyvHyvm0izN5ArpToYcllmnU3+i iHW6sXii6Ru7RL81rDWiQnLkelRXqiJpmApPyBsCnUwWjPCg/HV2ZAvmhGc14BQycWWb OX+A== MIME-Version: 1.0 X-Received: by 10.194.83.70 with SMTP id o6mr60019960wjy.44.1439329174035; Tue, 11 Aug 2015 14:39:34 -0700 (PDT) Received: by 10.27.78.207 with HTTP; Tue, 11 Aug 2015 14:39:33 -0700 (PDT) In-Reply-To: References: <8181630.GdAj0CPZYc@coldstorage> Date: Tue, 11 Aug 2015 16:39:33 -0500 Message-ID: From: Michael Naber To: Adam Back Content-Type: multipart/alternative; boundary=047d7bb04ade222572051d0ff016 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,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 Cc: Bitcoin Dev 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: Tue, 11 Aug 2015 21:39:36 -0000 --047d7bb04ade222572051d0ff016 Content-Type: text/plain; charset=UTF-8 Sure, most people probably would be happy with cheaper off-chain systems. There already are and will probably continue to be more transactions happening off-chain partly for this very reason. That's not the issue we're trying to address though: The main chain is the lynch-pin to the whole system. We've got to do a good job meeting demand that people have for wanting to utilize the main-chain, or else we'll risk being replaced by some other main-chain solution that does it better. On Tue, Aug 11, 2015 at 4:34 PM, Adam Back wrote: > So if they dont care about decentralisation, they'll be happy using > cheaper off-chain systems, right? > > Adam > > On 11 August 2015 at 22:30, Angel Leon wrote: > > tell that to people in poor countries, or even in first world countries. > The > > competitive thing here is a deal breaker for a lot of people who have no > > clue/don't care for decentralization, they just want to send money from > A to > > B, like email. > > > > http://twitter.com/gubatron > > > > On Tue, Aug 11, 2015 at 5:23 PM, Adam Back via bitcoin-dev > > wrote: > >> > >> 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 > >> 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 > >> >> 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 > >> > > >> _______________________________________________ > >> bitcoin-dev mailing list > >> bitcoin-dev@lists.linuxfoundation.org > >> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > > > --047d7bb04ade222572051d0ff016 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Sure, most people probably would be happy with cheaper off= -chain systems. There already are and will probably continue to be more tra= nsactions happening off-chain partly for this very reason. That's not t= he issue we're trying to address though: The main chain is the lynch-pi= n to the whole system. We've got to do a good job meeting demand that p= eople have for wanting to utilize the main-chain, or else we'll risk be= ing replaced by some other main-chain solution that does it better.

On Tue, Aug 11, 201= 5 at 4:34 PM, Adam Back <adam@cypherspace.org> wrote:
=
So if they dont care about decentralisation,= they'll be happy using
cheaper off-chain systems, right?

Adam

On 11 August 2015 at 22:30, Angel Leon <gubatron@gmail.com> wrote:
> tell that to people in poor countries, or even in first world countrie= s. The
> competitive thing here is a deal breaker for a lot of people who have = no
> clue/don't care for decentralization, they just want to send money= from A to
> B, like email.
>
> http://twitter.com/gubatron
>
> On Tue, Aug 11, 2015 at 5:23 PM, Adam Back via bitcoin-dev
> <bitcoin-d= ev@lists.linuxfoundation.org> wrote:
>>
>> I dont think Bitcoin being cheaper is the main characteristic of >> Bitcoin.=C2=A0 I think the interesting thing is trustlessness - be= ing able
>> to transact without relying on third parties.
>>
>> Adam
>>
>>
>> On 11 August 2015 at 22:18, Michael Naber via bitcoin-dev
>> <bitco= in-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 talki= ng 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 inexp= ensive to
>> > transact. If that characteristic is no longer true, then Bitc= oin isn't
>> > going
>> > to grow, and in fact Bitcoin itself will be replaced by bette= r money
>> > that is
>> > less expensive to transfer.
>> >
>> > So the importance of this issue cannot be overstated -- it= 9;s compete or
>> > die
>> > for Bitcoin -- because people want to transact with global co= nsensus at
>> > high
>> > volume, and because technology exists to service that want, t= hen it's
>> > going
>> > to be met. This is basic rules of demand and supply. I don= 9;t necessarily
>> > disagree with your position on only wanting to support uncont= roversial
>> > commits, but I think it's important to get consensus on t= he criticality
>> > of
>> > the block size issue: do you agree, disagree, or not take a s= ide, 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 bitcoi= n-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, sinc= e 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 bool= ean "at this size,
>> >> things break, and below it, they work". A small cons= tant factor
>> >> increase
>> >> will unlikely break anything in the short term, but it wi= ll come with
>> >> higher
>> >> centralization pressure of various forms. There is discus= sion about
>> >> whether
>> >> these centralization pressures are significant, but citin= g that it's
>> >> artificially constrained under the limit is IMHO a misrep= resentation.
>> >> It is
>> >> constrained to aim for a certain balance between utility = and risk, and
>> >> neither extreme is interesting, while possibly still &quo= t;working".
>> >>
>> >> Consensus rules are what keeps the system together. You c= an'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 wh= ether we need
>> >> a
>> >> block size limit, but we should be extremely careful with= change. My
>> >> position as Bitcoin Core developer is that we should merg= e consensus
>> >> changes
>> >> only when they are uncontroversial. Even when you believe= a more
>> >> invasive
>> >> change is worth it, others may disagree, and the risk fro= m disagreement
>> >> is
>> >> likely larger than the effect of a small block size incre= ase 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 des= igned to
>> >> prevent.
>> >>
>> >> My personal opinion is that we should aim to do a block s= ize 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 unre= liable, there
>> >> must
>> >> be a use for them. That may mean that some use cases don&= #39;t fit anymore,
>> >> but
>> >> that is already the case.
>> >>
>> >> --
>> >> Pieter
>> >>
>> >
>> >
>> > _______________________________________________
>> > bitcoin-dev mailing list
>> > bitc= oin-dev@lists.linuxfoundation.org
>> > https://lists.linuxfound= ation.org/mailman/listinfo/bitcoin-dev
>> >
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-d= ev@lists.linuxfoundation.org
>> https://lists.linuxfoundation= .org/mailman/listinfo/bitcoin-dev
>
>

--047d7bb04ade222572051d0ff016--