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 D8967323 for ; Fri, 24 Jul 2015 09:24:07 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wi0-f174.google.com (mail-wi0-f174.google.com [209.85.212.174]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 46110155 for ; Fri, 24 Jul 2015 09:24:04 +0000 (UTC) Received: by wibxm9 with SMTP id xm9so20144912wib.0 for ; Fri, 24 Jul 2015 02:24:02 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=1b0bEJWsnm/LvAqcs1AphDgmNWkI/Mq4yyfy6Bp+jXk=; b=hFDU+Z6JKeIRc9WjWLyttEwhjd2DsX1WKwG9aHrep6Rvhxykj2D4Z/KxDADabP1YVd dIN2evYUYABtaqceoNIn1etimrEmvcfOIgtte0EDtFp9xqF7HspWUAzxcA/NsRmwAFf5 LqaXJFsVpSunJDGYntZOue2vSQF0gxl2y9GqQNjBGOJRkUVIduQx1L+KvHl8r224rN8S h/46AkAuMf9oqZkXULFiw7qGm6jkklhsRue2KLIf/XB1LAtr5X7pmGXIabPyGLzMgfv2 0T7C/0a9oQRYqCAxwUF7iqQJN4ycQPIdpfVie5cinebf0Ev/JvqIHgEZzNCBV8RSfK9e AJ7Q== X-Gm-Message-State: ALoCoQmstvKLO+9kDWkR7yLVaEnSXErfBui4plODw3QHL/QXjUW7qtXCvfd8KR4W9dDUd5S2WIw1 MIME-Version: 1.0 X-Received: by 10.194.120.198 with SMTP id le6mr24780462wjb.133.1437729842647; Fri, 24 Jul 2015 02:24:02 -0700 (PDT) Received: by 10.194.95.168 with HTTP; Fri, 24 Jul 2015 02:24:01 -0700 (PDT) Received: by 10.194.95.168 with HTTP; Fri, 24 Jul 2015 02:24:01 -0700 (PDT) In-Reply-To: <55B1DB84.6070001@thinlink.com> References: <55B113AF.40500@thinlink.com> <55B1DB84.6070001@thinlink.com> Date: Fri, 24 Jul 2015 11:24:01 +0200 Message-ID: From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= To: Tom Harding Content-Type: multipart/alternative; boundary=089e011600028dea8d051b9b9080 X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,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@lists.linuxfoundation.org Subject: Re: [bitcoin-dev] Bitcoin Core and hard forks 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: Fri, 24 Jul 2015 09:24:08 -0000 --089e011600028dea8d051b9b9080 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Jul 24, 2015 8:30 AM, "Tom Harding" wrote: > > On 7/23/2015 10:51 AM, Jorge Tim=C3=B3n wrote: > > We know perfectly well that the system will need to eventually be > > sustained by fees. > > Fee revenue can rise just as easily without increased BTC fee rates. > > Two avenues that are just as effective: increased exchange rate, > increased number of fee-paying transactions. Neither of these avenues > benefits from increased "fee pressure" (scarcity of block space). > Why do you expect users to "increase the number of fee-paying transactions" if their free transactions reliably get mined relatively fast? And if it's good that they pay fees, why is not good when the reason they do it is because there's limited space in the block? Is user's paying fees soon a good thing or the "catastrophe" we need to avoid by rising the block size, what is it? Or is there something else wrong with having a limit other than "fees will hurt short-term adoption"? I'm confused about your position now... Regarding "increasing the exchange rate" it would be really nice to just push a button and double bitcoin's price just before the next subsidy halving, but unfortunately that's something out of our control. --089e011600028dea8d051b9b9080 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Jul 24, 2015 8:30 AM, "Tom Harding" <tomh@thinlink.com> wrote:
>
> On 7/23/2015 10:51 AM, Jorge Tim=C3=B3n wrote:
> > We know perfectly well that the system will need to eventually be=
> > sustained by fees.
>
> Fee revenue can rise just as easily without increased BTC fee rates. >
> Two avenues that are just as effective: increased exchange rate,
> increased number of fee-paying transactions.=C2=A0 Neither of these av= enues
> benefits from increased "fee pressure" (scarcity of block sp= ace).
>

Why do you expect users to "increase the number of fee-= paying transactions" if their free transactions reliably get mined rel= atively fast?
And if it's good that they pay fees, why is not good when the reason th= ey do it is because there's limited space in the block? Is user's p= aying fees soon a good thing or the "catastrophe" we need to avoi= d by rising the block size, what is it? Or is there something else wrong wi= th having a limit other than "fees will hurt short-term adoption"= ? I'm confused about your position now...

Regarding "increasing the exchange rate" it would = be really nice to just push a button and double bitcoin's price just be= fore the next subsidy halving, but unfortunately that's something out o= f our control.

--089e011600028dea8d051b9b9080--