Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id B258F267 for ; Tue, 11 Aug 2015 22:07:14 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ig0-f171.google.com (mail-ig0-f171.google.com [209.85.213.171]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6982EEE for ; Tue, 11 Aug 2015 22:07:13 +0000 (UTC) Received: by igui7 with SMTP id i7so50085950igu.1 for ; Tue, 11 Aug 2015 15:07:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=1aNnq6SLbo1JwLd1OeBL1NFLhKPwOIDvdvaRofStF20=; b=kXbRCK9q+uQB6oar73S1Y+ugmps9upEAlKvE+YA84nRH1iAQikyqXLNJOPjLCgL7g8 02k89+YDNiViKb2GAjx0V4BUKLySDfphDe6o8g61dW9Agx/JrLwSyIFW3YuKavGOZCUx XStSDR/WDMKxDVdmxPsPnntYpIv4T3K5q5XQcISfSTVoaLxBJr+33mgHQa5I0ltTunAn qOIGPzSd7Sd9agRf1Jc/CYzP+pcKhpvy8dTDAPd7hE9LzbpM1ybPJfLHb4XjPlv/w+uJ mMWZkPx/ANtG/WyrsdhPtvkyOVT4HpFzUBuAwbYE4ox1ANDrKla3OY/A8CILrt7EFfd8 GLgg== X-Received: by 10.50.73.170 with SMTP id m10mr21386275igv.60.1439330832827; Tue, 11 Aug 2015 15:07:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.122.144 with HTTP; Tue, 11 Aug 2015 15:06:52 -0700 (PDT) In-Reply-To: References: <8181630.GdAj0CPZYc@coldstorage> From: Angel Leon Date: Tue, 11 Aug 2015 18:06:52 -0400 Message-ID: To: Adam Back Content-Type: multipart/alternative; boundary=089e01183996014f25051d105390 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 22:07:14 -0000 --089e01183996014f25051d105390 Content-Type: text/plain; charset=UTF-8 > So if they dont care about decentralisation, they'll be happy using cheaper off-chain systems, right? You betcha! Just talk to a regular people and try to sell them on the different scenarios. They will start using something cheaper/faster the minute it comes along from the banking industry, just to give you a real world example, this week I've been dreading the idea of having to go to the bank to make a couple of cash deposits. If I could open my bank's web page right now and do a very simple interbank transaction (without having to convince the to let me link their accounts to mine, with the process that takes like 2 days when they deposit 2 different cent amounts...) just here within the retarded US banking system... which has clearly realized the threat from cryptocurrencies as evidenced on many banker conferences this year. They will come up with ways to allow us to do person to person transfers, but this will surely be limited to transactions within the country, international remittances still have a great chance of being disrupted by Bitcoin, if and only if, it will be cheap, otherwise the western unions and xooms of the world will still rule. Please get out of our your academic cocoon for a bit, talk to real people, try to convince them to use Bitcoin, and think how hard it will be to make the sell if on top you tell them... "it costs more... but it's decentralized!" LOL http://twitter.com/gubatron On Tue, Aug 11, 2015 at 5: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 > > > > > --089e01183996014f25051d105390 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
> So if they dont care a= bout decentralisation, they'll be happy using=C2=A0cheaper off-chain systems, right?

You bet= cha! Just talk to a regular people and try to sell them on the different sc= enarios.

They will start using something cheaper/faster the minute i= t comes along from the banking industry, just to give you a real world exam= ple, this week I've been dreading the idea of having to go to the bank = to make a couple of cash deposits. If I could open my bank's web page r= ight now and do a very simple interbank transaction (without having to conv= ince the to let me link their accounts to mine, with the process that takes= like 2 days when they deposit 2 different cent amounts...) just here withi= n the retarded US banking system... which has clearly realized the threat f= rom cryptocurrencies as evidenced on many banker conferences this year.
=
They will come up with ways to allow us to do person to person transfer= s, but this will surely be limited to transactions within the country, inte= rnational remittances still have a great chance of being disrupted by Bitco= in, if and only if, it will be cheap, otherwise the western unions and xoom= s of the world will still rule.

Please get out of our your academic = cocoon for a bit, talk to real people, try to convince them to use Bitcoin,= and think how hard it will be to make the sell if on top you tell them... = "it costs more... but it's decentralized!" LOL


On Tue, Aug 11, 2015 at 5:34 PM, Adam Back <= span dir=3D"ltr"><adam@cypherspace.org> wrote:
So if they dont care about decentralisation, they'll be happy usi= ng
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
>
>

--089e01183996014f25051d105390--